[cairo] Alternatives to autotools-based build systems
behdad at behdad.org
Tue Apr 29 12:39:27 PDT 2008
On Tue, 2008-04-29 at 12:01 -0700, Alan W. Irwin wrote:
> The recent troubles with libtool mentioned on list remind me of when we used
> autotools to build PLplot; it wasn't too bad, but on the other hand, every
> month or so there was yet another build-system irritation we had to solve.
> Thus, our developers were happy to replace autotools with CMake for our
> build system. CMake syntax is easy to learn yet extremely powerful so our
> developers were able to participate in the change rather than leaving it to
> just a couple of individuals. As a bonus it works well on essentially all
> Unix and Windows variants. For example, PLplot has had good build reports
> for Linux, Mac OS X, Cygwin, MinGW/MSYS, and windows with proprietary
> The cmake command is equivalent to autotools "configure", and after you run
> cmake, then you follow with the usual "make" and "make install". The use of
> the massive and slow libtool script during the build is replaced by
> configured Makefiles with the compile and link options built in. For this
> reason and others, CMake build-system latency is substantially reduced
> compared to autotools which is a nice bonus for developers. A CMake-based
> build system can coexist peacefully with an autotools-based build system so
> while we developed the new CMake-based build system we kept our old
> autotools build system alive to serve as a basis of comparison. However, we
> eventually dropped our autotools-based build system completely because
> nobody was willing to continue to deal with its irritations.
> Since creating our CMake-based build system, PLplot development
> has flourished (including a new cairo-based device driver), and in
> retrospect I believe it was the intimidation of the required autotools
> build-system changes that was holding our developers back before.
> 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.
All that sounds nice and good, except that autotools is the one I
understand and have full control when using. Our autotools setup is not
scary for anyone who has checked it out. To add a new cairo backend is
as simple as adding 3 lines to configure.in:
CAIRO_BACKEND_ENABLE(quartz_font, Quartz font, quartz-font, QUARTZ_FONT, auto, [
Looks like it's fashionable to bash libtool these days, but I've not yet
seen anyone tell me how other systems handle all the weird and corner
cases that libtool handles.
Another major issue with most alternatives is that you need to have them
installed on your system at build time. I have found that quite
irritating in the past. There's a reason autotools uses sh. A very
good one IMO.
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.
> Alan W. Irwin
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> Linux-powered Science
> cairo mailing list
> cairo at cairographics.org
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
More information about the cairo