Re: gir stability

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:

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]