Something worth mentioning at this point is that *proper* preprocessor
integration has unelaborated and perhaps unconsidered subtleties.
You should be wary of things like cpp caring about lexical structure
(not expanding macros inside text that looks like a C strings,
deleting text you don't want because it looks like a C comment,
as in glob('''foo/*'''), and so on.
There are also consequences for the main language parser since one
wants to propagate source coordinates to be a good toolchain citizen.
Pyrexc/Cython are already not such good citizens. They could but
do not put file and line number directives in the generated C.
Yes, perhaps in Pyrex's/Cython's case every other output C line would
need to be a #line and one may want to turn it off to look at generated
code. Yet, it seems to me the default should be to generate these
for naive or "regular" users who upon seeing an uninitialized variable
warning or what have you at line "foo.pyx:55" not at some line in the
generated code. Those who want #file/#line off (to debug the code
generator or declutter the generated code) are likely more empowered
to easily disable #file/#line generation than those confused by source
coordinates and wanting "unused variable" and "unitialized variable"
type warnings. :)
Even more significantly than things like data flow gcc warnings, this
would let me set a breakpoint in GDB like "breakpoint foo.pyx:55".
Yes, gdb doesn't yet understand Cython, and I'd have to use "inf loc"
or something to look at the local variables, but it would be nice to
even just make it easier to stop at the right Cython function (rather
than mangling or mucking about in source code).
Source coordinate propagation is a good thing. I actually have a
little profiling toolkit that would be able to tell me which line
numbers of pyx were my performance problems, if only the coordinates
were propagated.
If you really want to ditch include/IF/DEF/DEFINED/etc. and use some more
general tool, that tool could/should generate #file or #line directives.
Then on the input side of the equation, Cython should parse those in and
propagate them (this INPUT side of things is on the original Pyrex TODO list,
but strangely the OUTPUT which is needed to make 'gdb' or 'addr2line' and
such easy to use wasn't on the list -- there are some e-mail refs, though,
so this may have all come up before). { Cython actually has discretion to
require the input directives be spelled some way besides "#file" if you don't
want to support cpp. The # spelling seems pretty reasonable to me. Cython
just has to actually parse that kind of comment rather than ignore it. }
Just some issues to keep in mind for anyone that wants to work on this...
cb
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
