Re: gir stability

[Colin Walters <walters verbum org>]

On Tue, 2012-01-31 at 14:40 -0500, Ryan Lortie wrote:
> It seems like we've been avoiding talking about this particular issue
> for a while, but I think it's time we got a bit more serious about it.

I have some random thoughts here:

http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00057.html

To avoid a click, the important parts are these acronyms I pulled out of
thin air:

LABI - the C library's ABI
IABI - Introspection ABI for given library, what appears in the typelib
BABI - Binding ABI, how it processes the IABI to present
language-specific API

What you're talking about then is an "IABI" break.  It's also possible
for a binding to change its interpretation of the IABI and thus break
BABI.  Ideally don't do that much, but there are some looming issues -
for example, how gjs (or really, doesn't) handles 64 bit values.

So...what I think in practice is that unless we have tooling to detect
IABI breaks, we'll keep doing them unintentionally, and piss off our
ISVs.  It'd probably be pretty easy to write a tool to diff .gir files
and ensure they share IABI; the harder question is what process stores
previously built .gir files to diff against?

Maybe we could go with a committed-to-git .iabi file which was like
gtk.symbols except it also hashed the argument types etc.  Or hm, maybe
we could repurpose gtk.symbols to also list the key introspection data.

gtk_widget_show/Gtk.Widget.Show/method/void/
gtk_widget_draw/Gtk.Widget.Draw/method/void/cairo_t
gtk_widget_queue_draw_area/method/gint/gint/gint/gint	

?