The redo-inspired build tool I wrote abstracts the tasks of composing a build system, by replacing the idea of writing a build description file with command-line primitives which customize production rules from a library. So cleanly compiling a C file into an executable looks something like this:

Find and delete standard list of files which credo generates, and derived objects which are targets of *.do scripts:

> cre/rm std

Customize a library template shell script to become the file hello.do, which defines what to do to make hello from hello.c:

> cre/libdo (c cc c '') hello

Run the current build graph to create hello:

> cre/do hello

Obviously this particular translation is already baked into make, so isn't anything new, but the approach of pulling templated transitions from a library by name scales well to very custom transitions created by one person or team and consumed at build-construction-time by another.

Also see other test cases at https://github.com/catenate/credo/tree/master/test/1/credo and a library of transitions at https://github.com/catenate/credo/tree/master/lib/do/sh-infe...

I think this approach reduces the complexity of the build system by separating the definition of the file translations from the construction of a custom build system. These primitives abstract constructing the dependency graph and production rules, so I think it's also simpler to use. Driving the build system construction from the shell also enables all the variability in that build system that you want without generating build-description files, which I think is new, and also simpler to use than current build-tool approaches. Whether all-DSL (eg make), document-driven (eg ant), or embedded DSL (eg scons), build tools usually force you to write or generate complicated build description files which do not scale well.

Credo is also inspired by redo, but runs in Inferno, which is even more infrequently used than Go (and developed by some of the same people). I used Inferno because I work in it daily, and wanted to take advantage of some of the features of the OS, that Linux and bash don't have. Just today I ran into a potential user that was turned off by the Inferno requirement, so I'll probably have to port it to Linux/bash, and lose some of those features (eg, /env), to validate its usability in a context other than my own.

EDIT: Replaced old way, to call script to find and delete standard derived objects, with newer command.