Re: custom functions in introspection typelibs

["Havoc Pennington" <hp pobox com>]

Hi,

On Sat, Sep 27, 2008 at 6:41 PM, Colin Walters <walters verbum org> wrote:
> Using jhbuild doesn't imply bleeding edge (trunk/HEAD).

But using jhbuild with needed upstream fixes to support bindings
*does* imply bleeding edge ;-)

Bleeding edge is only half the problem, the other half is that jhbuild
takes forever, uses tons of disk, and requires years of experience to
diagnose if it ever fails to complete.

> Well, I would really like it if building GNOME wasn't so hard (this is
> http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/ ).
> It's something we need to fix rather than letting OS vendors handle it
> because it is a *serious barrier* to entry for contributors.

While I agree, I don't think we should block on this being solved
(especially because a good bit of the community isn't even hacking on
gnome, they're writing apps, or using the libraries in various
embedded-type contexts).

> A lot of your workarounds
> will go away when using FFI.  Another large chunk go away when you
> have the ability to inject a custom binding layer.

If they go away, then gir-repository ends up empty and we delete it.
gir-repository will automatically be only as large as needed.

> A gir-repository binary package would be very painful to ship by
> vendors; to do it cleanly you'd need to have a binary package for each
> library, or accept one mega gir-repository.rpm that Requires: the
> entire world.

Today, the same is true of every binding. Remember that gir-repository
is just sharing some stuff that previously each binding rolled on its
own.

I'm not *against* a custom binding layer, and I don't think it's
mutually-exclusive with gir-repository, but on the other hand right
now all the custom functions I have in C would equally apply to any
other binding (except for those arising from lack of ffi struct
access). I think ideally a custom binding layer is only convenience
API written in the binding language, and does not include these custom
C functions.

I guess it's not really a big deal for me to just suck gir-repository
into the binding, either, and forget about gir-repository. The idea
would be to fork any typelib that the binding needs a workaround in.
At the moment, that would be all typelibs since none of them are
upstream.

If that's the desired model, we have to solve some other things: the
typelibs become per-binding so need to be in some kind of
binding-specific search path, for example. We have
g_irepository_prepend_search_path() to support that, I guess.

I guess: gir-repository is useless unless it saves the bindings from
maintaining the header-scanning themselves. If we'll need to scan
headers and rebuild the gir in the bindings anyway, we should just
delete gir-repository and go with an approach where all typelibs are
binding-specific.

I do think it's a win to have one central place where all the binding
workarounds are collected, so we can see what needs to go upstream in
one spot, and so every binding author doesn't have to reinvent
annotations. If any binding author other than me wants to share a
gir-repository I would prefer to do that, I don't see why marking
parameters as "out" or adding a wrapper for GTK_WIDGET_FLAGS() can't
be shared among bindings. This stuff just is not specific to any one
binding.

Havoc