Incremental builds are finnicky beasts. To pick one of many ways they can go wrong, consider that many languages allow compile-time inlining of certain kinds of constants, even constants from other compilation units. Keeping track of the interdependencies between compilation units is a fair amount of work if the language doesn’t have that baked in, and eventually someone’s going to miss something, sending quite a bit of time down the hole while you diagnose why your incremental build isn’t reflecting all of your changes.

They’re somewhat useful on the developer’s workstation if you’ve got a large code base, but I generally prefer to break up large code bases into smaller pieces that can be rebuilt en bloc instead of spending time on incremental build support. For builds intended to be seen by others, even just internal users, rebuilding from scratch is the way to go every time.

That’s my incoherent 2¢

desc ‘All those implementation details’
define ‘teh-impl’ do
compile.with AXIS_OF_WS, OPENJPA
compile { open_jpa_enhance }
package :jar
end

is that it’s terser than the equivalent maven configuration; it’s not particularly clearer.

In return, have you looked at scons?

http://incubator.apache.org/buildr/

Though… if you have a complex build, it’s probably worth simplifying it – very few of the “complex” builds I’ve encountered have actually needed the complication; most were poorly-factored and could’ve been broken down into several stages for easier maintenance.