Make has its quirks, lots of them. But it wouldn't be the most popular build-tool in the world if it was all wrong. So, my hint to the next guy trying to reinvent it: Take a very close look at Make first and then improve on it. Don't start in a clean-room because then you're doomed to repeat build-system history, including all the past mistakes (edit: unless you're Linus Torvalds, perhaps).
Also the build-system is an area where a sane DSL makes perfect sense. Don't make me write procedural code by default. I don't want to see lines like the following in my build-scripts:
objects = ' '.join(s + '.o' for s in sources)So, instead of writing a program to do the build I would rather see a simple DSL that allows me to specify just the minimal amount of configuration to get things going.
For example building the example on the fabricate wiki page, should not be more complicated than:
:program programname : program.c utils.c
(This is actually an a-a-p recipe that will do the same. Throw this in a main.aap file and you get everything that fabricate does, build, dependency checks, clean, etc.)I don't mind to script the build when things get more complex. But only then and only when there really is no simple built-in alternative.
Fabricate seems to be more like ant in the Java world. Where you specify in detail what your build should do. Most people have agreed by now that it is a waste of time and instead use Maven, which completely works on simple conventions and standard rules.
However, as soon as you start adding more complex stuff the fabricate gets much easier to work with and maintain. Make's $< $@ stuff, but also because you're forced into a targets-are-files mould, and because you don't have a real programming language to work in.