Evaluating Alternate Build Systems

Even though I am on record as expressing devotion to the Autotools suite, I am not averse to evaluating alternatives. Mostly, I’m interested in a competent build system that can take care of the difficult and tedious stuff pertaining to a build such as dependencies and configuration. I acknowledge that Autotools embody a fair amount of complexity and arcana. The two top contenders to plausibly compete for Autotools’ title appear to be SCons and CMake.


Components

A good baseline for evaluating the capabilities of an alternative is to find a limitation of your current solution and then figure out if the alternative can do that AND everything that the current solution can do. For example, on one of my software projects, I really appreciate that the current Autotools-based solution can:

  • automatically keep track of dependencies
  • manage multiple build targets
  • create multiple build configurations in separate directories, working from the same source tree

But now I need some very fine tweaking of certain build settings, such as being able to static link a particular version of libstdc++ to a binary. I don’t know if any of the common build systems support this without some very serious hacking.

Here is a blog post from someone who has struggled with the very same issues and was able to solve the problem with a hand-crafted Makefile: G Plus Plus Minus One. I have managed to achieve the correct results from the command line. But trying to hack Makefile.am to do the same always ends up with a roundabout veto by the Autotools (i.e., the tools fall back on their preferred method of linking).

Of course, it would be really sweet if I could modify my existing autotools setup to do what I need. I am still diligently researching this possibility. I certainly do not wish to re-tool the whole build system into a hand-crafted, manually maintained Makefile.