[cairo] cairomm 1.6.0 fails with cairo 1.6.4 + quartz on Mac OS X
jonathon at quotidian.org
Fri Apr 25 08:37:55 PDT 2008
On Fri, Apr 25, 2008 at 10:24 AM, Carl Worth <cworth at cworth.org> wrote:
> On Fri, 25 Apr 2008 17:06:42 +0200, Murray Cumming wrote:
> > On Thu, 2008-04-24 at 12:41 -0400, Benjamin Reed wrote:
> > > I'm not sure how to untangle this stuff, is it impossible to support
> > > both X and quartz in the same cairo installation?
> > I guess so. If it works for cairo then it should work for cairomm.
> Hi Murray,
> Long ago (before cairo 1.0) we had a single "cairo.h" file that gave
> you all the backends enabled in your cairo build.
> Then we discovered that many systems, (X, Microsoft Windows, and
> Apple), all have namespace-hating header files that collide badly,
> (with things like Window, Cursor, etc.).
> So for cairo, we know provide separate cairo-xlib.h, cairo-win32.h,
> and cairo-quartz.h and applications can pull those in only as needed.
> I don't know exactly what's happening here, but if cairomm is pulling
> in several of those system-specific header files automatically, then
> that's a problem.
Yes, we do essentially the same thing in cairomm (we have separate
xlib_surface.h and quartz_surface.h headers). The problem in this
case is that we currently have some code in
Cairo::Context::get_target() that checks which kind of surface it is
and creates the appropriate wrapper type for that surface (e.g. an
XlibSurface, a QuartzSurface, ImageSurface, etc.). So that's
obviously pulling in all of the platform surface types. (Note that
this is in the source file, not a header, so it's not a problem for
users, only for building cairomm itself). But it appears that we may
need to find a smarter way to do this...
More information about the cairo