[cairo] Re: Re: Munging header files for export (and other) attributes

[Carl Worth]

On Wed, 07 Sep 2005 23:02:19 +0100, Mike Hearn wrote:
> On Tue, 06 Sep 2005 16:47:25 -0700, Carl Worth wrote:
> > Is the desire here to allow applications to be compiled against version
> > 1.y of cairo but then run against version 1.x with x < y ?
> 
> Yes.

Ok. I'm glad to know I'm understanding the issue then.

> Yes! This problem routinely takes people who distribute binaries on Linux
> by surprise. That's not just proprietary vendors but also projects like
> Gaim, Inkscape and AbiWord. Improving binary portability on Linux helps
> many people, and it doesn't really cost anything.

Well, it does cost exactly the work that we're discussing here. And
there are other costs in the implications of some of the changes
(discussed more below).

[Pardon me for re-ordering your message slightly here.]

> a) Somebody, somewhere has to provide tarballs of old sets of headers.
>    Probably of every library version.

At cairographics.org we're currently hosting the entire set of cairo
releases back to the beginning of time. Yes, that's only one tar
file so far, but I certainly expect to have them around forever.

> b) The people compiling the software have to know they need to use
> them.

And in your solution the people compiling the software have to know
they need to set the CAIRO_TARGET flag. So I don't really see a
substantive difference here.

>    This problem is unique to Linux/open source and does *not* affect
>    Win32/MacOSX platform APIs so invariably developers don't expect it
>    then get taken by surprise when their users start reporting strange
>    errors about symbols they never heard of

I don't understand the distinction being made here. The issue at hand
should affect API compatibility for any C library, regardless of
platform, right?

> c) You need to ensure the right sets of headers are being used at compile
>    time. Apbuild makes this easy, but still ....

I'm not personally familiar with Apbuild.

> > I would think that the easiest way to guarantee that an application
> > could be run against cairo 1.x would be to build against 1.x.
>
> Well, that's easy for the library authors but harder for the library users:

This still strikes me as the easiest solution. If I were to distribute
an application built against cairo 1.2 (say) I would advertise it as
requiring cairo 1.2 or newer. And if I wanted to allow the application
to work with cairo 1.0 I would instead build against cairo 1.0.

Even if we had CAIRO_TARGET to protect new-symbol-introducing changes,
(which as I said I think we can avoid without any problem), what
guarantee do I have that my application doesn't directly use new
symbols introduced between cairo 1.0 and cairo 1.2? The only way I
know to get that guarantee is to build against cairo 1.0.

Or do you want CAIRO_TARGET to protect new public symbols as well? If
that's the case, then I really don't like this approach as it hides
the new features until the user does extra work to get at them. The
whole point of moving from cairo 1.0 to cairo 1.2 is to get at the new
features that 1.2 provides, so I don't see it as a good thing to make
that harder.

> > And we could make it a policy issue to never do that.
> 
> That'd be nice. The glib/gobject/GTK+ stack has these issues in
> quite a few places so it's not unheard of. Over the last month I've
> been scrubbing the headers to remove them. Effectively, anything the
> headers can do that might tighten the dependencies of the compiled program
> is an issue (for instance, making functions inline that refer to
> new symbols).
> 
> So yes, another way to solve the issue is simply to outlaw those kind of
> changes :)

That much I'm fine with. I guess what this provides is for someone to
develop an application against 1.x, but then if "accidentally" compiled
against 1.y, it will still run with 1.x.

That does seem like a useful guarantee, and it's something we should
provide in cairo. No header file munging needed, we'll just consider
those kinds of changes ABI breaks, and we won't make them.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050907/53092678/attachment.pgp