The Shoes of the Fisherman's Wife Are Some Jive-Ass Slippers

Tue, 30 Mar 2004

SCons rocks like Spock in a box!

I've been using SCons for a project at work lately and have decided that it is not just a good tool but rather an amazingly good tool. For a good description of the shortcomings of make, see my favourite paper by Peter Miller, Recursive Make Considered Harmful. (Interestingly enough, it turns out that SCons uses Peter's Aegis software configuration management system which also contains a make replacement, called cook).

SCons has several extremely compelling advantages over regular and GNU make:

• Automatic calculation of header file dependencies.

  Most projects ignore header file dependencies, preferring to either just ignore them or make a half-assed broken attempt to represent them in make. This can be bad news for developers who have to have enough experience with the project to know when to run make clean after changing a critical header file. Incorrect or out of date hand-coded header file dependencies are slightly worse. You get the illusion of targets being rebuilt after header file changes but still have to know when to rebuild from scratch.

  There are a couple of solutions to this available. IDEs like Visual C++ automatically calculate header dependencies and rebuilt targets appropriately which is great for Windows programmers. In the autoconf world, header file dependencies are usually built around the creation of lots of little poos in your build directory containing the output of gcc -M. These files are included in your Makefile and you're off to the races. I don't think this is an ideal solution, especially if you aren't using gcc.

• Built in autoconf, automake and libtool-like functionality.

  I think the whole m4 based templating idea is a nice hack gone horribly wrong. While autoconf and friends serve the noble function of making software packages more portable across wierdly different architectures, they are quite slow compared to the speed of compilation, and this makes the test/debug/fix cycle for writing autoconf tests frustating and time-consuming.

  Disclaimer: builtin autotools functionality may not be completely equivalent to using the actual tools. I have had a brief play with creating runtime tests in SCons but I'm not sure how well this would scale to a large project with many runtime configuration tests and --with style options.

• The ability to create separate build environments for building different targets.

  This is something really special. Traditional autoconf based Makefiles have one set of environment variables - CFLAGS, CPPFLAGS, LDFLAGS, LIBS are the usual names for these guys. However, it is usually the case that every C file is built with the same flags. Creating multiple sets of flags is rather difficult. In Scons, environments can be copied and tweaked in a couple of lines of code.

• Automatic rebuilding of targets if the build command changes.

  This is actually quite a subtle feature and is something that you might not realise is a problem in make. If I make a change in a makefile, which targets need to be rebuilt? Make cannot determine this and so you either have to do make clean && make, or do a partial rebuild by removing selected objects or executables and rebuilding. SCons remembers the commands used to build a target and if this changes, then the target is rebuilt. If I write some comments, rename variables or otherwise make changes that don't affect the build commands, nothing is rebuilt.

SCons has some other advantages which aren't quite as eye-popping as the above list, but still are worthy features to have.

• It's written in Python which means your variables, tests and any other associated build stuff can be written in a fully-fledged scripting language, instead of make's environment which is pretty much a system for assigning values to variables. Indentation trolls are not welcome. (-:

• Running scons dir where dir is a subdirectory in your project will build all targets under that directory. Neat!

• Unecessary rebuilds are avoided by using checksums to determine whether a file has changed, rather than the timestamp.

• It works with Windows, not that there's anything wrong with that.

I guess to be fair I should add some negatives as well in a pathetic attempt to seem balanced.

• Scons is written in Python, so it requires some knowledge of the language to make full use of it. Fortunately Python is pretty easy to learn and the syntax is very intuitive.

• Scons is a very different environment from regular make. There is somewhat of a learning curve moving from one environment to another.
• I'll probably run into some more limitations as I continue to use the tool.