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

Benjamin Otte otte at redhat.com
Thu Dec 2 06:34:56 PST 2010

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.

I'm also wary of the outgrowth you quickly get in the build system,
where people add random flags here and there to make things work on some
platform and that in the end nobody understands or dares touching
anymore. Because let's face it, we're not experts on linking and library
lookup mechanisms. And I'm pretty sure none of us wants to be.


More information about the cairo mailing list