Visual Studio will try to compile them if they end with .c, though this can be disabled on a per-file basis in the project file. Files ending in .h won't be compiled, though changes should be detected and cause the .c files that include them to be recompiled.
.inl is also sometimes used as an extension for this purpose. I don't recall whether VS will add file associations for this type. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Larry Hastings<mailto:la...@hastings.org> Sent: 1/18/2014 10:58 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] .clinic.c vs .c.clinic On 01/18/2014 01:02 AM, Serhiy Storchaka wrote: 1. I very very often use global search in sources. It's my way of navigation and it's my way of investigations. I don't want to get false results in generated files. And it is much easy to specify mask '*.[ch]' or '*.c,*.h' (depending on tool) than specify a mask and negative mask. The latter is even not always possible, I can write cumbersome expression for the find command, but Midnight Commander doesn't support negative masks at all (and perhaps your favorite IDE doesn't support them too). Apparently you do this at the command-line. In that case, you can make an 'alias' to hide the cumbersome expression. Perhaps you've already made one that ignores the ".hg" directory tree? If the generated file didn't end in a standard extension, editors won't automatically recognize them and won't code-color them. You tell me "everyone can easily reconfigure their editors" but it seems you writing an alias is unreasonable. 2. I'm not use any IDE, but if you use, it can be important for you. If IDE shows sources tree, unlikely you want to see generated *.clinic.c files in them. This will increase the list of sources almost twice. My experience is that IDEs either show all files in the "project" (which should include the generated files anyway) or they show all files in the directory. So this concern assumes behavior that isn't true. 3. Pathname expansion works better with unique endings, You can open all Modules/_io/*.c files, but unlikely you so interested in *.clinic.c files which are matched by former pattern. How often do people edit *.c in a directory? And then, how often do people edit *.c in a directory and wouldn't want to see the Argument Clinic generated code? 4. .c suffix at the end lies. This is not compilable C source file. This file should be included in other C source file. This will confuse accidental user and other tools. Including Argument Clinic itself, this is why it inserts the "preserve" directive at the start of generated file. But other tools have no such sign. This is nonsense. The contents of the file is 100% C. If you added the proper include files (by hand, not recommended) it would compile standalone. A lot of your suggestions assume no one would ever want to examine the generated code. But people will still want to look in there: * to set breakpoints * to make sure existing Argument Clinic generated code does what you wanted * when experimenting with Argument Clinic inputs So I don't see the need to make the generated files totally invisible. Later in the thread someone suggests that ".h" would be a better ending; I'm willing to consider that. (As in ".clinic.h".) After all, you do include it, and there's some precedent for C code in H files (the already-cited stringlib). Also, now I'm starting to worry that adding ".clinic.c" files to an IDE would mean the IDE would try to compile them. Can somebody who uses an IDE to compile Python code experiment with ".clinic.c" files and report back--is it possible to add them to your "project" in such a way that the compiler will notice when they changed but won't try to compile them standalone? I'm thinking specifically of MSVS, as that's explicitly supported by CPython, but I'm interested in results from other IDEs if people use them with CPython trunk. Serhiy: I appreciate your contributions, both to Python in general and to Argument Clinic specifically. And you're only doing this because you care. Still, I feel like you've never been shown a bikeshed you didn't have an opinion on. /arry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
