I just has a quick look at your test script, and I notice it’s not using any of SCons’ speed features. Reading your problem domain, one in particular might be useful. SCons uses objects called ‘Deciders’ to figure out if a file/dependency has changed. The default Decider uses MD5 sums of the file contents, which adds a *lot* of time overhead. The reason this is the default behaviour is explained here: http://www.scons.org/doc/production/HTML/scons-user.html#AEN815, but the important point is that it can be easily changed (using one of several built-ins or writing your own). There’s one that will use the later-than-mtime instead, like make, (flaw: doesn’t catch introduction of older files into the file tree), and another that’ll use mtime-exact (any different mtime causes a rebuild), and several more. There are trade-offs involved with these, but we found that mtime-exact took 66% of the time of md5s, which is not as fast as others but takes a lot of the sting out.

It has evolved from Scons years ago to address several flexibility concerns and performance issues. Have a look:

http://code.google.com/p/waf
http://freehackers.org/~tnagy/testdoc/index.html

My current project and my last project used it. The #1 issue I have with it is no one seems to actually understand it and so because it’s just a python library and you have all of python with which to hang yourself every sub project ends up being some personal hack of the guy who setup the build for that sub project. Back in make days, editing or adding something to a makefile was always relatively easy. Writing my own build system in perl or python has been relatively easy but everytime I see someone go try to add something to scons it’s 4-8 hours of pain.

One thing that many build systems seem to have problems with is dependencies that can’t be known before the build starts. An example is you don’t know what textures need to be processed until you build the maya/max file. So what you really want is

.mb->.middleformat->.texturelist->[texture1, texture2, ...]

When .texturelist already exists and is up to date (ie, newer than both .middleformat and .mb) it’s easy for some build system to follow the rules and build the textures but most build systems I’ve used don’t like it when that list doesn’t exist yet and therefore has to be added after the build has started. Or to put it another way, most build systems start with only some programming language in mind and make the assumuption they can scan the text quickly to figure out implicit dependencies. That assumption is not true for assets.

“50 libraries, 100 classes each, 15 internal includes, 5 external includes). I built everything once, then ran it again and it took 49 seconds.”

I’ve done a fair amount of work recently analyzing no-change (aka null, do nothing etc) build times with SCons.

Frankly, I had never really considered test-driven builds. We’re definitely test-driving our data conversion tools (take this model from the intermediate format to the final one).

The main problems I see with a test-driven tool is that the high-level build process is a well-understood, generic process. It’s also a process that is highly performance sensitive and it’s going to be stressed with Gigabytes of data, so you want to parallelize it as much as possible. So given that, it seems that trying to adopt someone else’s solution is the way to go. Yes, there’s still no perfect build system out there, but they’re probably better than what a single person can do in a month or so.

On the other hand, if your game doesn’t have too much data, then you can just grab any of them (make, Scons, MSBuild) and be happy with it and you can spend your efforts in the things that really matter (the game). In general I’m not a fan of writing build systems from scratch as a set of custom scripts though.

http://www.xoreax.com/technology_xge.htm

http://sham.sourceforge.net/
http://www.cs.berkeley.edu/~billm/memoize.html

They basically work off of the same idea: run the commands to do the build, monitoring the inputs and outputs with kernel hooks to generate dependencies information. No need to specify or calculate the dependencies explicitly via some heuristic hack.

I imagine it would be pretty easy to implement a parallel build system on top of these. You could simply write your build instructions sequentially in a list with certain barrier points. All commands between barrier N and N+1 could be run in parallel. e.g.

compile blah/foo.cpp blah/out/foo.obj
compile blah/bar.cpp blah/out/bar.obj
compile blah/baz.cpp blah/out/baz.obj
compile guff/foo.cpp guff/out/foo.obj
compile guff/bar.cpp guff/out/bar.obj
compile guff/baz.cpp guff/out/baz.obj
——————————————- # barrier
make-library guff/out/*.obj libs/guff.lib
make-library blah/out/*.obj libs/blah.lib
——————————————- # barrier
# etc …