Re: GObject-Introspection

[Johan Dahlin <jdahlin async com br>]

Havoc Pennington wrote:
> 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?

This will at most, be a build time dependency.

> 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

Just to make this clearm, this is mostly short-term. Once we have a couple 
of users and enough stability we will start pushing it upstream.

> 2) Merge any custom annotations shared among all language bindings and
> kept in gir-repository (adding accessors, marking memory management
> rules, etc.)

While important, this is also temporary. And should eventually move
upstream as well.

> 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

Most languages will also depend on the C library to access the typelib.
I believe writing bindings for a C based library is far easier than
rewriting the whole library for each language. I would not be surprised 
though if we see at least some LB doing just that.

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

An alternative here is make a clean break, eg only use this in new
language bindings and make the typelib/GIR define the API.

For Python I plan to;
* Convert PyGTK .defs to .xml, still keep them locally
* Find out the changes between the .gir in gir-repository/upstream and
  apply fixes/patches on top of them
* Write a new module, eg pybank which interacts with the typelibs only

That means that the old cruft we collected in PyGTK will only
be cruft there and not upstream. For future modules we'll use the
more 'dynamic' bindings as available in pybank.

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

I haven't been paying too much attention to the typelib recently, as my 
bandwidth is just enough for me to keep working on the scanner/GIT format 
for now. I hope someone motivated can jump in here and start updating and 
extending the typelib.

One thing I thought about was using a proper binary tree in the typelib,
where it would be possible to define your new set of nodes you can
add at any level. I'm not sure about the performance implications for that 
though. (Similar to Quicktime/MPEG4 ISO format)

Johan