[Pyrex] External declarations and GCC-XML?

[Matthias Baas]

At 16:59 23.07.2003 +1200, Greg Ewing wrote:
>Because you don't want to lose the definitions of #defines that are
>being used to define a constant or a function-like macro. You want to
>turn #defines for constants into an enum declaration, and #defines
>for inline functions into a plain function declaration.
>
>On the other hand, #defines that are being used to control #ifdefs
>elsewhere in the header you probably do want to process the same
>way as the C preprocessor would.
>
>The main problem is how to tell the difference between these
>different usages of #define. That's a large part of the
>missing information.

Personally, I really wouldn't mind if Pyrex would not try to infer the 
meaning of a macro and would just use the preprocessed file (as I am 
usually programming in C++ instead of C I don't use #define anyway except 
to protect a header file from being included twice or maybe to select 
platform or compiler specific stuff via an #ifdef).

And I doubt that a tool can derive the correct meaning of a collection of 
macros just by looking at the macro definitions. Rather, I believe you have 
to tweak the definitions manually anyway, so you can just enter the entire 
definition by hand. For example, how would you be able to create an 
enumeration? A macro that defines a numeric value might or might not be 
related to another such macro (and belonging to the same enum). I see no 
way to detect this automatically, maybe you can make a guess by analyzing 
prefixes and such things, but you can never be sure and need user interaction.
I would suggest to split this functionality into a separate tool (or 
module), a Pyrex preprocessor that optionally scans source files for 
macros, tries to categorize and interpret them and outputs a *.pxd file 
which can then be inspected by the user. The actual Pyrex "core" could then 
rely on preprocessed files and stick to the C/C++ specification.

- Matthias -