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

[Kristian Høgsberg]

2010/12/2 Benjamin Otte <otte at redhat.com>:
> On Thu, 2010-12-02 at 08:48 -0500, Kristian Høgsberg wrote:
>> If we can drop the hyperbole, I'd be interested in any real arguments
>> against this you may have.
>>
> Usually what this comes down to is making it more complicated to be
> portable, because we all know that dlopen() doesn't exist on Windows,
> behaves differently on Mac OS X and fails completely for static linking
> (if we still support that). And then we'd probably get the library name
> wrong in a few platforms, too.
> So what we end up with usually is a lot of issues that other tools take
> care of currently. (Mostly libtool I guess?) And I've learned the hard
> way that it's best to avoid portability problems. For example, Pixman
> still doesn't manage to do atomics or threads.
>
> If a specific backend is built on top of some stupid decisions (like
> GL's linking madness), I'd prefer if we could constrain that to that
> backend. Just because somebody porting to a broken platform could then
> at least use the other backends without lots of work.

Yup, and that's all I proposed.  Use dlopen() in the gl backend to
find the right gl library.  I understand the problem Behdad wants to
fix, which is also worthwhile, but the gl vs gles2 case is two mutally
exclusive backends which is even worse than having to libcairo.so link
to everything up front, in my opinion.

Kristian