Worth mentioning that the "single phase" concept seems to be the same as djb redo http://cr.yp.to/redo/atomic.html which djb described (but never released) some 10 years ago.

apenwarr implemented the redo spec in python "to the letter", and also a shell script called "do" which is very short, and can be shipped with a project so one does not have to worry about having it installed.

That said, a quick look at fbuild shows that it is interesting, and despite a similar concept, very different from redo.

Here is the meaty part:

    As I mentioned previously, every build system I've
    found is based off of a multi-phase declarative tree
    evaluation.  Here's the list of the system I looked at:

    * [Ant] (http://ant.apache.org/)
    * [Automake] (http://www.gnu.org/software/automake/)
    * [Boost Build] (http://www.boost.org/doc/tools/build/index.html)
    * [Cmake] (http://www.cmake.org/)
    * [Make] (http://www.gnu.org/software/make/)
    * [Ocamlbuild] (http://gallium.inria.fr/~pouillar/)
    * [Omake] (http://omake.metaprl.org/index.html)
    * [Qmake] (http://doc.trolltech.com/4.2/qmake-manual.html)
    * [Rake] (http://rake.rubyforge.org/)
    * [SCons] (http://www.scons.org/)
    * [Waf] (http://code.google.com/p/waf/)

   By "declarative tree evaluation", I mean that the order
   of evaluation is explicitly encoded in a dependency
   tree.  Each node has a function that takes one or more
   inputs and returns one or more outputs. By 
   "multi phased", I consider building the tree as one
    phase, walking the dependencies as another, and 
   evaluating the nodes as yet another.  This contrasts
   with `Fbuild`, which I consider to be a single-phase
   procedural build system.  As python evaluates each
   cached function, the dependency implicitly gets
   evaluated.  This means that it's possible to dynamically
   modify the build on demand: