[cairo] Alternatives to autotools-based build systems
tgriggs at cincom.com
Tue Apr 29 12:41:50 PDT 2008
On Apr 29, 2008, at 12:01 PM, 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,
> month or so there was yet another build-system irritation we had to
> Thus, our developers were happy to replace autotools with CMake for
> 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
> 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-
> 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
> 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
> projects were considering replacements for CVS several years ago.
I'll add an uninformed/naive +1 to this. I honestly think there are
actually about 10 people on the planet who understand automake/
autoconf/m4/etc in their entirety and could put together a clean one
from scratch. Everyone else is just copy/modifying. And everytime
something doesn't build correctly, I'm left feeling about the same as
when I have to look at C++ compiler error output from heavy STL stuff.
"Every institution finally perishes by an excess of its own first
principle." - Lord Acton
More information about the cairo