[Python-Dev] .clinic.c vs .c.clinic (original) (raw)
Georg Brandl g.brandl at gmx.net
Sun Jan 19 12:32:24 CET 2014
- Previous message: [Python-Dev] .clinic.c vs .c.clinic
- Next message: [Python-Dev] .clinic.c vs .c.clinic
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Am 19.01.2014 11:19, schrieb Larry Hastings:
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower <Steve.Dower at microsoft.com> wrote:
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. That sounds like a rather good argument for .clinic.h over .clinic.c :)
My assessment of the thread is that .clinic.h will give us the best overall tool compatibility. Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h". But there's one onion in the ointment: what should "foo.h" generate? The day may yet arrive when we have Argument Clinic code in foo.{ch}. Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory?
Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
At least that is consistent, allows easy exclusion in tools, and gets rid of the additional "clinic" in the filename.
Georg
- Previous message: [Python-Dev] .clinic.c vs .c.clinic
- Next message: [Python-Dev] .clinic.c vs .c.clinic
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]