[cairo] [cairo-gl] RFC: Dispatching mechanism for non-standard GL functions

[Behdad Esfahbod]

On 12/02/10 09:27, Benjamin Otte wrote:
> On Thu, 2010-12-02 at 08:52 -0500, Behdad Esfahbod wrote:
>> We *are* doing it wrong by generating one .so for all backends.  runtime
>> linking is one way to fix it.  Having separate .so's for separate backends is
>> another.  That's for example what pango does.  But for that to work you have
>> to expose the internal backend API and either support it or make sure you make
>> it hard for people to use it.
>>
> Yeah, I agree on that part. It would be a lot nicer if we would split
> our one big so into multiple small ones. I don't think that's API
> compatible though, or is it?

We can make it.  We make smaller .so's and update our .pc files to use them
from now on, but also add a libcairo.so that links to them all, such that
older applications linking to libcairo.so keep working.  Apps compiled against
the new scheme won't link to the older one anymore, but guess that's not a
huge deal.


> Also, I don't see why we'd need to expose any more API than we do
> currently, linking doesn't care about header files. We'd however
> possibly need to export a bunch of symbols. But I don't think anyone
> considers private symbols (i.e. ones not available in headers) seriously
> for API stability.

Don't be so optimistic about people not using private symbols.  You should see
what applications like firefox or OpenOffice do when they have to workaround a
library bug...


> So, keeping the headers as-is and just creating a bunch of libraries
> that we install, sounds like a plan at least. It'd also allow me to ship
> xcb and gl backends for Cairo in Fedora without causing too many
> stability concerns for the "important" backends. SO I'm all for it.

Right.  Exactly.  So, we'd have:

libcairointernal.so (all internal API, _cairo prefixed).
libcairocore.so (all always-builtin stuff: image backend, user font backend).

The rest all link to libcairointernal.so and libcairocore.so:

libcairo-xlib.so (may require libcairo-xcb.so?)
libcairo-xcb.so
libcairo-ps.so
libcairo-pdf.so
libcairo-svg.so
libcairo-ft.so

libcairo.so (compatibility, catch all, links to all)

But what exactly to do with tee, and other various small public and private
surfaces?

Before we proceed, one should do a quick number to see how many extra
libraries gtk will be linking to with this scheme.  It's prolly 8 more.  Not
sure if that's significant.

behdad


> Benjamin