Re: Official .defs files

[Rob Browning <rlb cs utexas edu>]

> Certainly it should be considered.  I just don't think it should
> be a show stopper.  The defs file already involves merging information
> which can't be known by simple extraction.  Conditional compiling
> enums certainly fit this bill.
> 
> (There are things which should be avoided like...
> 
> enum {
>    ENUM1,
> #ifdef SOMETHING
>    ENUM2,
> #endif
>    ENUM3
> }
> 
> Because it causes unnecessary binary problems and will be a total
> pain in the ass to extract.)

But again, if the point is to develop a standard that will work across
many C-APIs, even internal APIs for projects that just want to use
this tool to wrap their own API for internal consumption (by Guile for
example) and where this kind of conditional enumeration is just fine,
then you don't have control over whether or not the C APIs do this
sort of thing, and this (ignoring the compilation time issue) isn't
hard to accomodate at compile time AFAICT.

However, if the .defs files are only intended for wrapping GNOME/GTK
stuff, and/or for APIs which are willing to follow some rules (in
which the above construct would be no-no), then you're right.

It just seems like a somewhat fragile assumption to me.

FWIW

-- 
Rob Browning <rlb cs utexas edu> PGP=E80E0D04F521A094 532B97F5D64E3930