And after you have read it, read the documentation of apenwarr's implementation of djb's "redo", and see how everything about make can be simplified to the point that a 150 line portable bash script can be used as a non-dependency-tracking replacement (that is, rebuild everything on each run).
redo makes everything much simpler, more consistent, more dependable, and more robust. e.g all files are atomically replaced; dependencies are checked by a crypto hash of the content; dependency setup is sane; and it's all faster than make.
I wasn't praising make design though. Just mentioning that there are implicit decisions that could be of use if you have to deal with it.
Thanks for the info, I'll look into redo. I just watched a recent talk about Shake (make-like in Haskell) interesting results like 10x smaller ~makefiles and 2x speed improvement.
It's most of the point of make. The other point is templates. And it does both of them, but redo shows that it does them in an unnecessarily complex and inconsistent way.
A redo specification is generally much shorter[1] than the equivalent Makefile, yet simpler to write, can be guaranteed (unlike make / make depend) to rebuild whenever necessary and only when necessary. And while a supersmart dependency tracking incremental build version is not trivial, it's probably an order of magnitude or two shorter than make; And a 150 line bash script is enough to interpret the same specification without regard to dependencies or prior builds (that is: rebuild everything on every attempt).
redo makes everything much simpler, more consistent, more dependable, and more robust. e.g all files are atomically replaced; dependencies are checked by a crypto hash of the content; dependency setup is sane; and it's all faster than make.