[cairo] Alternatives to autotools-based build systems

[Travis Griggs]

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


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.

--
Travis Griggs
Objologist
"Every institution finally perishes by an excess of its own first  
principle." - Lord Acton