I. Overview of the main build system families

1. The Make model

From historical reasons mostly, the make-like tools have gained mainstream diffusion. The idea of these tools was to provide a minimal language in which dependencies between files are expressed, and a minimum scheduler using these dependencies for launching compilation commands.

This design is wrong for at least two reasons:

• extending the tool means extending a programming language
• backward compatibility is broken too easily
• the model relies too heavily on the filesystem (interaction with other tools)
• the language in which make was written (C) leaves plenty of room for programming mistakes

2. Extending Make means creating tool chains

The main concepts for extending software, such as: function overloading, inheritance, composition do not exist in such simple languages. Since the language fixes were too difficult to implement (the space/tab problem still exists in gmake), the mainstream solution was the development of makefile generators, or tools that generate code that make can read. But the makefile generators in their turn were not created with portability or configuration in mind, and other tools were created to generate code for these code generators.

The best known tool chain is the assembly of Autoconf,Automake,Libtool,Make. In this case each tool in the toolchain generates code using macro languages (m4) which makes the system difficult to debug and to maintain. More recently the same mistake was made in QMake with a new programming language. In CMake the developers have at least tried to include the configuration system, yet users still need to create wrappers for it (kde unsercmake, etc). In OMake the developers have even included a shell.

For launching commands in parallel or for caching the compilation results, tool chains abstracting make from the files system have had to be written too (distcc, ccache).

3. The Ant family

Ant-like tools contain XML-based configuration scripts, and extensions written in Java, therefore reusing the power of the Java libraries. They were written in the hope that machines could create new production rules, and that people could control the compiler tool chains right from their favorite IDEs (Eclipse..). This is not satisfactory for at least three important reasons:

• The XML file format is too verbose already, but expressing conditions in XML is even worse. The Waf build system provides an XML interface too, but the developers do not code in XML.
• When a problem arises it is necessary to look at the source code, but maintaining XML-scripts when something goes wrong requires a lot of work.
• Extensions must be compiled, making it difficult to customize the system for missing usecases.

If JSON were used, things would not have been much different, although extensions could have been written in Javascript.

4. On native build systems

Native build systems such as Scons and Waf use the Python programming language to allow library code reuse and extensible APIs. The dynamic typing nature of Python makes it easy to write new rules, however bugs might hide and not pop up until much later. Note: Another new native build system in the context of Java applications has popped up (Grails).

5. Domain specific programming languages - bad idea

Designing a language is easy, but designing a language that can be extended is extremely difficult. A build system is a tool, not a language. We have seen the same mistake countless times: for example in the field of constraint programming, tons of domain-specific languages have been written, yet the most successful tools use existing languages or languages very similar to existing ones choco:java, facile:ocaml, etc. Creating a custom programming language in the hope it will make the system more flexible is chasing two different animals at the same time.

In the context of build systems, there are at least 3 concepts to keep in mind:

• do not create domain-specific languages
• do not make chains of tools like code generators
• scripting languages are important for customization

II. Waf vs Scons

Similarities:

• Python language
• BSD license
• configuration scripts written in python
• support for parallel builds (like "make -j2")
• support for caching object files (like ccache)
• use dependencies based on files signatures (md5, timestamps, ..)
• build specific targets from the command-line
• support for many tools like c++, java, latex, etc

Differences:

• general
• speed: Waf is much faster than SCons. In daily use (partial rebuilds), starting with even medium-sized projects, you can reasonably expect it to be an order of magnitude faster than SCons, and also at least twice faster than makefiles generated by the autotools. In several common scenarios, the speedup compared to SCons or the autotools increases to a factor between 10 and 20 times (see these numbers for more details).
• separation between data and code in Waf (no functions in environments)
• Waf can uninstall without cleaning the build tree
• more packaging features in scons (msi and rpm)
• optional xml script front-end in Waf
• unit testing module in Waf
• build directory set up easily in Waf
• DESTDIR and PREFIX are supported by default in Waf
• support for linking local libraries in Waf (uselib system)
• command-line interface
• default targets in Waf: configure, dist, distcheck, distclean, uninstall, clean, ..
• separation between configuration and build in Waf (persistence)
• custom command-lines in Waf
• default colors in waf
• building specific targets and the dependencies in Waf (--target=mylib)
• support for building targets recursively from the launch directory in Waf
• support for continual integration in Waf (rebuild when one file changes)
• progressbar output
• C/C++ specific features
• preprocessor for C/C++ in Waf (proof of concept in Scons)
• support for building hybrid programs in Waf (caml/c/c++/qt)
• strong control over the scheduler in Waf (parallelize cpp compilation but link targets one by one)
• batch builds (compile several c/c++ files at once)
• distribution
• Waf fits in a single 100KB redistributable script, Scons must be installed or a whole directory must be packaged and shipped with the project
• Python 1.5 2.2 for Scons, Python 2.3 for Waf
• architecture
• lightweight filesystem representation in Waf (flyweight)
• task ordering: directed acyclic graph in scons vs probabilistic in waf
• less inheritance in Waf (strategy pattern)