[cairo] Rethinking cairo's build system

[Vladimir Vukicevic]

On 6/16/06, Carl Worth <cworth at cworth.org> wrote:
> 1) Running automake and configure take too long
>
> 2) Whenever configure is run, every source file is rebuilt

True, but how often do you re-run configure?  The amount of tests it
does can probably be trimmed down as well.  For #2, it's certainly
possible to have configure only update config.h if something actually
changed from the old config.h.  Note that I'm not a big fan of
autoconf/automake at all, but they do seem to work and get the job
done.

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

This can be fixed by reworking the test directory.

> 4) Building the docs takes too long, (or perhaps it just needs to be
>    moved to "make doc" instead of "make)

Yup, make doc would fix that.

> 5) Building the docs touches tons of files, requiring a "git
>    update-index --refresh" before "git diff" output is clean again.

This won't be solved by an upgrade to make; it's the fault of gtk-doc,
I believe.  You could switch to an alternate documentation format, or
just do what we (mozilla) are doing, and throw all your docs on a
wiki.  The number of API reference pages would be small enough that
they could be pulled down in HTML format and packaged together pretty
easily.

> 6) Building the docs modifies (!) a bunch of files under version
>    control. This is worse than annoying.

Yep, same problem as 5 though, no?

> 7) The "make check" target should generate the html report
>    unconditionally, rather than requiring a separate "make html".

Also fixable; adding the html target was the easiest way to make
things "go", since I didn't want to fight with automake.

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

I would suggest linking all the tests into one test binary that can
run them all -- this would mean one relink instead of N, and would
also give you better control over which tests to run on what targets
etc.

> 11) The build system isn't deemed adequate by many win32 developers,
>     many of whom end up hand-coding something.

There are only two solutions to this; one is to provide Visual Studio
project files (preferred), the other is to provide NMAKE-compatible
makefiles.  I have the latter done, I just need to commit them --
cairo is just built with the standard win32 font and surface backends.
 PDF/PS/ft/etc. are not built, due to the freetype dependency (if they
have freetype installed, they can probably run autoconf from cygwin).

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

There are a bunch of alternative build systems that all solve many of
make's faults -- cmake, SCons, jam.  The all have their own problems,
though, not the least of which is that they're not present on pretty
much any system.  One of the first barriers that someone will hit when
they want to play with it is that they'll be required to download
another tool for actually building it, and this could easily throw off
lots of people.

   - Vlad