[cairo] Alternatives to autotools-based build systems

[Behdad Esfahbod]

On Tue, 2008-04-29 at 13:34 -0700, Carl Worth wrote:

> Looking back at the list, there are a few items that are still
> unaddressed and that do still annoy me from time-to-time. These
> include
> 
> 1) Running automake and configure take too long

configure takes 15s here, without caching.  With caching, as it is run
by autogen.sh, it takes 10s.  A large part of that seems to be that our
check for compiler warning flags doesn't do caching.  Fixing that.


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

No.  Try:

$ make
$ ./config.status --recheck
$ make

observe that the second make builds nothing.


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

Moving docs to source files fixes this even with gtk-doc.  FWIW, I do
prefer staying with gtk-doc, as that's the system I'm more familiar
with.  I always have problem editing the cairo wiki because I'm mostly
used to moinmoin and mediawiki syntaxes.


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

This one's not as easy as I liked it to be.

There are hopes in the current system though.  The gold linker
drastically speeds up linking.  And a faster libtool implementation
definitely helps.


> 11) The build system isn't deemed adequate by many win32 developers,
>     many of whom end up hand-coding something.
> 
> For #11, we've currently got Makefile.win32 files in the tree, so
> we're at least helping a little bit there, (but I imagine there's
> still manual effort for these people). And many win32 developers seem
> to prefer to have some sort of "project file" solution for their IDE,
> (which ends up not being practical to ship with cairo itself), so
> perhaps even switching to cmake wouldn't help them.

Exactly.  Though it can be improved.  Some of the fast changing parts of
our Makefile.am's (list of source files) can be moved into a separate
file that is then included by both Makefile.am and Makefile.win32.  I'm
yet to see someone who cares about win32 to come up with a patch for it
though.


> For #8, I believe Behdad has had a plan for revamping the test suite
> for faster linking for a long time. If someone wants to help do this,
> I'm sure he'd be glad to describe it. (In the meantime, the addition
> of "make recheck" and "make TESTS='subset of tests here' check" has
> largely solved this annoyance for me).

Yes, "make recheck" has helped a lot.  One idea that helps here is to
adjust the test suite to support multiple tests per source file.  That
has lots of merits.  Then you can stuff all your matrix tests into one
source files.  That can easily reduce the number of test source files
that need relinking down by a factor of 5.

Linking all tests into one driver binary helps a lot if you do "make
check", but penalizes the case where you run a subset of tests only.
So, that's not necessarily a win.


> For #1, using dolt, (which, hey!, X.org did switch to already and did
> work out some bugs), might definitely improve compilation speed.

I also have some ideas about that.  I probably will work them out with
the libtool upstream instead of trying to reinvent libtool.  There are
other alternatives too.  For example, for your typical modern linux
system, one can write an API-compatible libtool replacement that is
pretty much zero overhead.  Then your distribution can ship that and you
get the speedup automagically, without breaking build on obscure
systems, something that only libtool knows how to handle.  David Schleef
gave this idea a try years ago, to replace automake.  He was about to
rewrite automake's logic in less than 100 lines of GNU make.

There are other interesting alternatives popping every other day.
There's Quagmire by Tom Tromey.  This one actually looks promising to me
as I'm in the camp who believes Tom Tromey is the exact right guy to do
this.


Anyway, I wish I had infinite time...

> -Carl
> 
> [*] http://live.gnome.org/RoadMap
> 
> 	Decide on a new Distributed Version Control System (This is
> 	not about switching, just deciding and understanding
> 	implications)
> 
> That's for the future GNOME 2.24, (within 6 months or so).

It's so much harder in GNOME.  Even the SVN conversion was quite hard.
You have a huge repo with 10 years of history and so many weird
surgeries done, it's just not easy.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759