[cairo] cairomm 1.6.0 fails with cairo 1.6.4 + quartz on Mac OS X

Jonathon Jongsma 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.
>
>  -Carl

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

-- 
jonner


More information about the cairo mailing list