Re: Cooperating on .defs API specifications

[Andreas Rottmann]

Owen Taylor <address@hidden> writes:

> I think we'd actually open to include .defs with the modules themselves;
> the downside being, of course, that you don't get updated defs until
> the module releases a new version.
>
> The other downside is that it is easy for the GTK+ version to get
> out of date if people aren't careful about putting back their changes
> to the canonical version ... 
>
I think would be not a good idea, for the reasons you already
mentioned. The thing is: the GTK+ people, (or other module authors),
don't actually use the .defs, only the wrapper people do. IMHO, it
makes much more sense to have them in their own package, maintained by
the people who need them.

> I'm  actually pretty interested in exploring the question including
> full method introspection in the binary libraries as discussed recently;
> if we could generate that from header file / magic comment parsing
> and not have .defs files at all, I think that would be great.
>
Why not have .defs files, and generate the binary info from them? The
.defs files are already there, and they contain more information than
the headers do (well, comment parsing might change that, but you could
create comments from the .defs files :)). Just an idea...

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth