On Fri, Jul 18, 2008 at 9:33 AM, Gustavo J. A. M. Carneiro < [EMAIL PROTECTED]> wrote:
> > > Sure, but you are assuming a scenario where g-i already has complete and > accurate metadata about the library APIs. Assuming that scenario is not > very reallistic, I think. I believe the goal is to fix those header files. Long term, as I understand it (just digging in a bit to g-i myself now) what will be great about g-i is that it will ensure that people coding in C create bindable interfaces, rather than the most convenient interface for C. We slip on this right now because .h -> .def is an asynchonous, manual process. Put simply, if you create a new method with no metadata, it won't break the build. With g-i, it *will* break the build because it's integrated into the library build process. > At the end of the day, it will be people doing > language bindings doing the heavy lifting and figuring out, possibly > from the .c files (memory management semantics often are not clearly > documented), and folding back that information into the metadata. Again I think the point is we want to move this burden to the library authors (supported by the authors of all language bindings), rather than redundantly duplicating it in each binding.
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
