[cairo] Rethinking cairo's build system

[Albert Chin]

On Fri, Jun 16, 2006 at 03:51:30PM -0700, Carl Worth wrote:
> 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

You don't necessarily need to run automake on a project-wide scale. If
just one or a few of your Makefile.in's are out-of-date, they will be
updated automatically by 'make' on an as-needed basis.

Yes, configure does take awhile to run. However, portability is not
free.

> 2) Whenever configure is run, every source file is rebuilt

Using autoconf/libtool doesn't mean you must use automake. You can
manually maintain your Makefile.in's if this would alleviate this
problem. However, as 'make' is dealing only with Makefile's, then it
should be relatively simple to determine what file configure is
touching that causes the rebuild.

I built cairo-1.0.4, then reran ./configure and 'make'. No source
files were rebuilt. So, I'm not seeing this problem.

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

I'm sure the respective Makefile.am's can be updated to fix this.

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

If you built with --enable-static --disable-shared, the programs must
be relinked if the library changed. Make isn't smart enough to
differentiate between a shared library dependency and a static one,
though I'm sure a more bloated Makefile.in, autogenerated from
Makefile.am, might help solve this (i.e. seprate dependency rules for
shared/static builds).

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

How about splitting 'make check' into 'make check-backendx' and
then have 'make check' call 'make check-backendx' for all backends.
Then you can manually 'make check-backendx' for those you're
interested in.

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

Yes, this would be nice. I'd recommend you suggest this to the folks
on the automake mailing list.

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

I haven't built any auto* projects on win32 so cannot comment about
this.

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

No doubt, the majority of Cairo development and usage is done on
Linux-based systems. However, for those of us in a world populated by
Solaris, HP-UX, IRIX, AIX, and Tru64 UNIX, the portability gained from
the autotools is much appreciated. In particular, libtool. Creating a
shared library on modern systems like Solaris, IRIX, and Tru64 UNIX
isn't too difficult. Not necessarily so with HP-UX and AIX.

I've read adversarial comments about libtool. Please keep in mind that
libtool is about _portably_ creating shared libraries. Some platforms
do suffer from a "least common denominator" approach. However, libtool
could certainly do more to make life easier for Linux users (e.g.
supporting the --as-needed linker option). I'd suggest posting your
quarrels to the libtool mailing list. Worst case, they get added to
the TODO list for future planning. Libtool has been seeing active
development for the past year so their is hope.

-- 
albert chin (china at thewrittenword.com)