Re: Cooperating on .defs API specifications

[Owen Taylor]

On Tue, 2004-03-30 at 14:52, Andreas Rottmann wrote:
> 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.

If the .defs files are supposed to describe the GTK+ (etc.) interfaces,
it really seems strange for me to have them maintained independently
of GTK+.

> > 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...

Duplicated information is out-of-date information, in general :-)

Regards,
                                                Owen

signature.asc
Description: This is a digitally signed message part