Hi, On Sun, Jun 1, 2008 at 11:53 AM, Yevgen Muntyan <[EMAIL PROTECTED]> wrote: > Too bad gobject-introspection depends on python-2.5. Is > it going to be a dependency only for gobject-introspection > itself, or is it going to be a dependency for projects > which use gobject-introspection, i.e. will a user need > python-2.5 to build a foobar package which happens to provide > or use introspection data? >
Depends on where a project "hooks in" which is sort of an interesting question in itself. AIUI the "pipeline" to use say GTK via g-i is: 1) Scan GTK Source, output gir to common gir-repository module 2) Merge any custom annotations shared among all language bindings and kept in gir-repository (adding accessors, marking memory management rules, etc.) 3) Merge any per-language-binding custom annotations (e.g. hacks to keep back compat with old binding versions, or whatever) 4) Generate binary typelib 5) At runtime, language binding depends on binary typelib What this implies right now, due to 3), is that we have separate binary typelibs for each language binding which results in the language bindings needing to run a Python merge-thingy themselves, I think. However, that's clearly not ideal... we would really want common binary typelibs used by everyone. So I guess step 3) needs fixing. Which would leave language bindings depending only on the binary typelib and the C lib used to read it, and not depending on Python at all during their build. In fact if the typelibs are arch-independent they could in theory just be distributed prebuilt with gir-repository. Not sure if they are. The question I can't figure out right now is how to do merging or custom stuff on the binary level. The way the binary typelib format works, merging is practically impossible. Because if you say iterate over all functions in a class, that is just walking through a fixed-size mmap'd array. To be able to merge a new function from another, separate binary typelib would be a major project it seems like, or worse, throw away the efficiency win of the shared mmap() approach. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list