On Tue, 2004-03-30 at 14:52, Andreas Rottmann wrote: > Owen Taylor <otaylor redhat com> 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
Attachment:
signature.asc
Description: This is a digitally signed message part