For the non programmers, the word ‘make’ in the following paragraphs refers to a tool used to control the compilation of a software product.

At work we are in transition to using scons as our build driver. I guess enough people were frustrated with Make that they were able to change things over. Here is the problem.

You can never get away from make.

Any build system that uses code from some where else is, eventually going to have to deal with make. Your standard GNU package is a tarball that you unpack and then run:

./configure

make

make install

Or some variation on this. At work, the build team wanted to standardize on the version of autotools that they use. Makes sense, you should not check generated files into a repository if it makes more sense to regenerate them…but does it? Well, you need to be able to modify the Makefile.in and Configure.in files, so yes, every developer needs to run Automake/Libtoolize/Autoconf/etc with the same options and the same version of the tools. I’m not certain that autotools really make sense for a Linux only project, which was why we didn’t use them at Penguin and why we have to use them for the packages we have here.

People don’t like make because they either don’t like rules based programming or they don’t like debugging make files. Fair enough…but deal with it. Instead of trying to rewrite the tool, extend it. I am not talking about your average developers, just the ones that decided they can do it better using X, where X is some other language or some other library.

Personally, I’ve never found a replacement of make that didn’t end up sporting some of make’s warts. If your goal is to do incremental compilation, then the Ant approach, depending on the compiler to identify which file to build, won’t work for most languages. This is a case where you need to recognize in a Makefile that you don’t want to have a .SUFFIXES rule (.java.class) and instead, if you depend on the Java code, you let javac build everything every time. See the difference? One depends on a tool support for something, and fails when it isn’t there. The other allows you to take advantage of the tool support if it is there.

One reason that people don’t like make is that it is sensitive to white space. SCons is built in Python, also sensitive to white space. I guess those people will keep looking for something else.