[cairo] Another win32 build attempt

[Carl Worth]

On Fri, 05 Aug 2005 19:43:18 +0200, Hans Breuer wrote:
> With a simple rule in cairo/src/CMakeLists.txt. [The only file which
> apparently *must* be in the source directory.]
> Look for CONFIGURE_FILE. It takes all the previously defined variables
> and does the appropriate replacements. My current CMakeLists.txt is
> attached.

Ah, slick. So it supports configure-like substitution. That's nice.

> > I'm still unsure about if and how to provide multiple build systems within
> > the cairo source tree. I feel a one vs. infinity[*] pull here,
>
> IMO this rule doesn't apply very well here, or is having one (instead
> of no) build system an exception instead of a necessity?

The "zero" aspect of the formulation I linked to definitely doesn't
apply to build systems, (unless we all give up and go surfing
instead). But there is the fact that if we have more than one build
system in the tree, what justification could I use to turn down a
third, etc.

And there's definitely some additional support/maintenance cost with
having multiple build systems in the tree. That's what I'm leery of.

> Which may finally cause an infinite number of different cairo source
> distribitutions. If I ever start my own it'll probably include my
> wmf based cairo backend as well. BTW: how does your 0,1,infinity
> rule apply there? [1]

Ah, that ones easy. The correct answer there is we should have an
infinite number of source distributions. The one case is for
proprietary software. And for zero we're back to surfing.

> > Meanwhile, I notice that your patch also has an unrelated change for the
> > win32 backend. It would really help to have things like that presented in
> > separate patches/messages so they don't get lost.
> > 
> Something along the line of :
> https://bugs.freedesktop.org/show_bug.cgi?id=3926
> https://bugs.freedesktop.org/show_bug.cgi?id=3927

Ah, yes. That's an excellent place for those. I apologize I wasn't
aware that those were already there.

I do have a couple questions regarding the current patch, (much of it
likely that I'm not familiar with cmake).

> IF(APPLE)

Is this test some cmake builtin?

> INCLUDE( ${CMAKE_BINARY_DIR}/FindFT2.cmake OPTIONAL )
> INCLUDE( ${CMAKE_BINARY_DIR}/FindFontconfig.cmake OPTIONAL )
> IF(FT2_FOUND AND FONTCONFIG_FOUND)

This test is obviously pulling in a "custom" FindFT2.cmake rule. Is
that something that ships with cmake?

> IF(GLITZ_FOUND)
> IF(XCB_FOUND)

How about these rules? I don't see similar INCLUDE directives for
them, nor do I see anything in the patch[1] that would define these
rules. Where do they come from? And is pkg-config used in locating
these?

Also, if XCB is available say, (such that XCB_FOUND would evaluate to
true), is it easy to build cairo without the XCB backend? That is,
with cmake would we have an easy way to get the equivalent of:

	./configure --disable-xcb

In fact, not just the equivalent, but can we have that exact
interface? If I were to adopt a replacement for automake I'd still
like to have the same configure-based interface for it.

> INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/../../libpixman/src ${CMAKE_SOURCE_DIR})

Yuck. I definitely don't like the build system to make requirements
about the existence and location of source versions of modules it
depends on. Bur presumably this could be made to work in a manner
similar to XCB_FOUND and GLITZ_FOUND?

-Carl

[1] http://hans.breuer.org/gtk/cairo-2005-04-10-hb.diff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050805/333407dc/attachment.pgp