[cairo] Another win32 build attempt

[Hans Breuer]

On 05.08.2005 20:19, Carl Worth wrote:
> On Fri, 05 Aug 2005 19:43:18 +0200, Hans Breuer wrote:
  >>>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.
> 
Many, but they would be technical not theoretical. For gtk+, The GIMP, dia
there is an additional build system maintained in cvs for years.
 From time to time people request to include specific VC 'workspace' files.
But they would add nothing but being dependent on an exact version of VC
and also only editable by the GUI. The hand-written makefile.msc do
work from version 5.0 up to the latest .NET (IIRC 7.1).

Now for CMake: it is supposed to be work on UNIX variants, Linux, OSX  etc.
It is not gcc-centric but tries to also support 'native' compilers.
On win32 it even can generate the "workspace" files used to build with
the different Visual C versions.

> And there's definitely some additional support/maintenance cost with
> having multiple build systems in the tree. That's what I'm leery of.
> 
As noted above there is a second 'build system' for gtk+ maintained for
years. There also was some hand-written mingw attempt, but it got
removed as it began to rot too much.

> 
>>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.
> 
Having independent and probably incompatible cairo versions does
not look like a good goal to me.

> 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?
> 
I think so. [But I'm not an expert of CMake either.]

> 
>>INCLUDE( ${CMAKE_BINARY_DIR}/FindFT2.cmake OPTIONAL )
>>INCLUDE( ${CMAKE_BINARY_DIR}/FindFontconfig.cmake OPTIONAL )
>>IF(FT2_FOUND AND FONTCONFIG_FOUND)
> 
This is from a recent attempt to also build PDF/PS backends on win32.
> 
> This test is obviously pulling in a "custom" FindFT2.cmake rule. Is
> that something that ships with cmake?
> 
Obviously CMake does not deliver support for every library out there.
But it is supposed to be easy to write your own. A current full patch
for building cairo with the help of CMake would probably include
these.

> 
>>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?
> 
Although I have access to different machines with different OS I havent
put the effort into the CMake based build system to support all of them.
So the above is just the skeleton to also use CMake on Linux with XCB,
GLITZ etc.

> 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
> 
This is certainly possible but I would need to look it up in the
documentation.

> 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.
> 
When one wants to provide ./configure an is able to write shell scripts
it should be possible to wrap cmake from configure. But usually
CMakeSetup (w|s)ould be used. See: http://www.cmake.org/HTML/RunningCMake.html

> 
>>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?
> 
This again could be solved by writing a FindPixman.cmake file,
but if I'm the only to use it simply can also have such requirements.

As already noted in my original mails on the subject I just had started
to use CMake and am still exploring it's facilities. But the main
advantage for me was that I have gotten something to work within hours
instead fiddling around with the non working for years (aka. autotools ;))

	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert