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

[Mike Hearn]

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.
 
> If so, is there actually a compelling need for this?

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.
 
> 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:

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

b) The people compiling the software have to know they need to use them.
   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

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

> That said, I don't actually anticipate the specific case here ever
> actually occurring in practice, (a macro later turning into a function).
> 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 :)

thanks -mike