Re: GObject-Introspection

["Havoc Pennington" <hp pobox com>]

Hi,

On Sun, Jun 1, 2008 at 11:53 AM, Yevgen Muntyan <muntyan tamu edu> 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