[cairo] Rethinking cairo's build system
Carl Worth
cworth at cworth.org
Fri Jun 16 15:51:30 PDT 2006
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
-------------- 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/20060616/7f4cf8ad/attachment.pgp
More information about the cairo
mailing list