[cairo] Rethinking cairo's build system

[Asko Kauppi]

I've shared your concerns in way too many projects (especially  
Autotools is Very Evil..); the best alternative I've come across is  
probably SCons (www.scons.org). Requires Python but otherwise, runs  
very cleverly, is fast, and has enough cross platform support.

You may also want to check Hamster, a Lua based build system that I  
made based on SCons (but using Lua, not Python as the description  
language). By their power of expression they are about the same.

About cmake, I've heard but not taken a look myself..

Jam I would beware to keep distance of.. It's syntax sucks, and that  
is just Reason #1. :)
- Asko


Carl Worth kirjoitti 17.6.2006 kello 1.51:

> So there are a number of issues that have been annoying me about
> cairo's build system lately. Many of these are due to the fact that
> I've been taking advantage of git-bisect a bunch lately, (and with
> great results!) and doing that magnifies bugs in the build system that
> cause it to take longer than it should.
>
> So here is a laundry list of some of the annoyances:
>
> 1) Running automake and configure take too long
>
> 2) Whenever configure is run, every source file is rebuilt
>
> 3) An empty-target "make" command builds some utility programs in the
>    test directory. These are problematic since they have more
>    dependencies than cairo itself, (even circular dependencies). These
>    need to be delayed until "make check".
>
> 4) Building the docs takes too long, (or perhaps it just needs to be
>    moved to "make doc" instead of "make)
>
> 5) Building the docs touches tons of files, requiring a "git
>    update-index --refresh" before "git diff" output is clean again.
>
> 6) Building the docs modifies (!) a bunch of files under version
>    control. This is worse than annoying.
>
> 7) The "make check" target should generate the html report
>    unconditionally, rather than requiring a separate "make html".
>
> 8) Running "make check" takes an annoying amount of time because every
>    individual test is re-linked whenever there is any change in the
>    library. ("make check" also takes too long because many of the
>    tests are much larger than they really need to be).
>
> 9) For "make check" we can test all backends (by default) or a single
>    backend (with CAIRO_TEST_TARGET), but it would be nice to be able
>    to test any subset of backends.
>
> 10) With the test suite we can run all tests (with "make check") or
>     any single test (by executing it directly), but it would be great
>     to be able to run a subset of tests. In particular, I would like
>     something like "make recheck" that would run only the tests that
>     failed on the last run.
>
> 11) The build system isn't deemed adequate by many win32 developers,
>     many of whom end up hand-coding something.
>
> And there are a number of other things, (many general complaints could
> be made about things libtool and its pernicious .la files that do
> nothing but harm on Linux based systems for example).
>
> So there's a real smattering of issues above. Some of them might have
> simple, isolated fixes (and if so, pleas contribute them!). While
> others will requiring larger changes (upstream gtk-doc changes? moving
> documentation to another system?).
>
> One of the larger changes I think we'll definitely do is to just write
> our own little program for running the test suite rather than using
> what's generated by the TESTS variable through automake. This seems
> like the easiest plan for hitting #7 and #10 above.
>
> And if we do that, then it looks like there are a large number of the
> above that could be addressed by moving away from our current
> autotools setup, (which is likely a requirement for getting #11). I'm
> not sure that we want to do that, but I'm certainly open to doing it
> if it will help us address several of the issues above while not
> causing new problems.
>
> One thing I've been wanting to look at closer for quite some time is
> cmake (http://www.cmake.org). Hans Breuer tried cmake out for building
> cairo with MSVC a little over a year ago and was very pleased with
> it. I've also recently heard that Scribus is using cmake with good
> success.
>
> Anyway, that's just a note to let people start thinking about this or
> experimenting with things. I don't plan to actually try anything in
> this area until after 1.2 is done.
>
> -Carl
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo