[cairo] Alternatives to autotools-based build systems

[Carl Worth]

On Tue, 29 Apr 2008 15:39:27 -0400, Behdad Esfahbod wrote:
> On Tue, 2008-04-29 at 12:01 -0700, Alan W. Irwin wrote:
> All that sounds nice and good, except that autotools is the one I
> understand and have full control when using.
...
> I don't mean cairo won't switch to an alternative build system one day,
> but it won't be soon.  The git move was a great example of a practice to
> follow:  switch whenever one of xorg or gnome switches.

Hey now. To set the record straight, Xorg switched to git after
watching cairo do it. :-)

	[cairo] Plans (and motivation) for moving cairo from CVS to git
	http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
	2006-02-07

	Xlib moved to git
	http://lists.freedesktop.org/archives/xorg/2006-February/013075.html
	2006-02-18

Watching a large project make the switch first does ensure bugs in the
system get worked out, and gives us some assurance that we won't be
the only ones stuck maintaining the system. But I also wouldn't want
to have a hard block on something like that before we make
improvements. Imagine how bad it would be if we had waited for
GNOME[*] before we moved to a distributed VCS.

But I think Behdad said the more important point first: autotools is
what he understands and he's the one that maintains the build system.

I'm quite happy to have people propose alternate build systems,
(particularly if they can eliminate some of the pain we sometimes
have). But the time to switch will be when someone who understands the
new system is trusted by the cairo project to maintain it going
forward.

> > I haven't explored autotools build system alternatives other than CMake, but
> > my understanding is there are a lot of them that are maturing right now so
> > the basic point I want to make is autotools was good enough in its day, but
> > it is now time for most software projects to give a serious look at the
> > much-better alternatives. There is nothing urgent about this step, but to my
> > mind it should be on your agenda in a way very similar to how most software
> > projects were considering replacements for CVS several years ago.

Thanks for the heads up, Alan. I think you've expressed that well, and
accurately.

And I agree it's worth having on the agenda. Here's a message I wrote
in 2006 complaining about several things in cairo's build system, (and
even floating the idea of cmake):

	[cairo] Rethinking cairo's build system
	http://lists.cairographics.org/archives/cairo/2006-June/007173.html

Now, I think it was my threat of switching away from autotools that
pushed Behdad into solving most of those problems. He took my list of
complaints as a TODO list and quickly addressed almost all of
them. That's why I'm still happy to let him maintain the build system
and choose whatever tools he finds best for that.

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

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

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

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

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.

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

For #6, we've been talking about moving cairo's documentation from
gtk-doc to something like MarkDown, (though I think I'd really like to
see a version of MarkDown that wouldn't think the underscores of
CAIRO_STATUS_SUCCESS mean that we intend to render CAIROSTATUSSUCCESS
with the letters "STATUS" in italics).

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

-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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080429/255b4488/attachment.pgp