Re: custom functions in introspection typelibs

["Havoc Pennington" <hp pobox com>]

Hi,

Thanks for the inject feature, I think that will solve the problem, or
at least some twist on it will ... I'll dig into it. Will also follow
up in a sec on ffi.

I do want to defend gir-repository though - I think it's extremely
necessary to make bindings practical and successful, and get the sense
you aren't convinced.

On Sat, Sep 27, 2008 at 5:05 PM, Colin Walters <walters verbum org> wrote:
> I'm fine with having gir-repository contain workarounds

gir-repository *is* a workaround in this sense! The whole point of it
is to allow us to share working typelibs across bindings without
waiting for them to trickle through upstream then distributions.

If some people don't want to use gir-repository then that's fine. They
can either wait for all the fixes and .gir files to be
upstream-released, or they can put all the fixes and .gir in their own
bindings, or they can jhbuild the whole stack from ground up. But to
me all three of those options are pretty bad.

If I'm going to put all this stuff in my own bindings, I may as well
put it in a separate module in case someone else wants to use it,
which would be the same thing as gir-repository. That's what all the
bindings already have, is their own workarounds.

I guess there's some idea that allowing workarounds prevents fixing
the upstream libs, but I think that just isn't true here. In
particular because in this case moving stuff upstream is a simple
matter of cut-and-pasting the workaround. While before with a
binding-specific approach, it wasn't.

> Again - having gir-repository workarounds *does not help* with that
> 2-years timeframe because no OS vendors are shipping
> gobject-introspection or gir-repository

It's not a big deal for a binding to require latest
gobject-introspection and gir-repository (or even suck gir-repository
into the binding).  Users can easily install gir-repository without it
fighting with the system copy. It's not a big additional burden to
install gobject-introspection, if someone is already installing a
binding.

However, it *is* a big deal to replace the system copy of the entire
GNOME library stack.

Not just for users - though that's bad - but also for developers. If
I'm hacking on a binding (or app), it greatly decreases my efficiency
if I'm forking libraries left and right, or having to jhbuild all
hundred-something things in jhbuild instead of 3 modules. I certainly
don't jhbuild all of gnome. I don't know why I should have to. In fact
I don't want to, I think it's right to develop most apps against
widely-deployed versions, not bleeding-edge versions. Most apps aren't
part of the GNOME release cycle.

Few are going to contribute to my binding or app if they have to do
the whole jhbuild in order to work on it. That barrier is too high.

Without gir-repository, a working binding has to wait for the length
of time between GTK and GNOME releases, PLUS the length of time
between linux distribution releases, PLUS the length of time for users
to upgrade to those releases, and then at long last an API can be
used. Until then, nobody could use the binding, because critical
things are missing from the upstreams.

We could say "OK, this is a one-time event" - but it is not a one-time
event. What are the chances that *every* binding issue is discovered
and fixed in the next GTK release? How about in the entire GNOME
stack? I'm guessing a few will get missed. Then we're another 2 years
down the road just waiting for some missing get_type for some random
enumeration. No reason to do that.

Anyway: it's the whole premise of gir-repository, and why that module
exists, so I think we should maintain gir-repository with this
premise.

When everything-is-upstream really happens, gir-repository will
naturally end up empty. If (more likely) everything-is-upstream almost
but not quite happens, then gir-repository will be almost but not
quite empty.

The minute gir-repository isn't needed, it automatically self-empties
and disappears.

Havoc