That's a nice set of rules, although I don't think they're all easy to follow or verify that 1000 lines of Make is following. I considered 3 main use cases, an

That's a nice set of rules, although I don't think they're all easy to follow or verify that 1000 lines of Make is following. I considered 3 main use cases, and I wrote Makefiles from scratch for all of them. Make works to an extent for each case, but I still have problems. 1. Building mixed Python/C app bundles [1] 2. Building my website [2]. Notably people actually do complain about Jekyll build speed, to the point where they will use a different system like Hugo. So incremental/parallel builds are really useful in this domain! 3. Doing analytics on web log files (e.g. time series from .gz files) One thing I didn't mention is that they all involve some sort of build parameterization or "metaprogramming". That requirement interacts with the problem of parallel and incremental builds. For example, for #1, there is logic shared between different bundles. Pattern rules aren't really expressive enough, especially when you have two dimensions. Like (app1, app2, ...) x (debug, release, ASAN, ...) A pet peeve of mind is having to "make clean" between a debug and a release build, and nearly all usages of Make have that problem, e.g. Python and bash's build system. You could say they are violating your rules because each artifact doesn't have a unique name on the file system (i.e. debug and release versions of the same object file.) Likewise, Make isn't exactly flexible about how the blog directory structure is laid out. I hit the multiple outputs progblem -- I have Jekyll-style metadata at the front of each post (title, date, tags), so each .md file is split into 2 files. The index.html file depends on all the metadata, but not the data. All of them have dynamic dependencies too: 1. I generate dependencies using the Python interpreter 2. I add new blog posts without adding Make rules 3. I add new web log files without adding Make rules Make does handle this to an extent, but there are definitely some latent bugs. I have fixed some of them, but without a good way of testing, I haven't been motivated to fix them all. I wrote up some more problems in [3], but this is by no means exhaustive. I'm itching to replace all of these makefiles with something that generates Ninja. It's possible I'll hit some unexpected problems, but we'll see. My usage is maybe a bit out of the ordinary, but I don't see any reason why a single tool shouldn't handle all of these use cases. [1] Rewriting Python's Build System From Scatch http://www.oilshell.org/blog/2017/05/05.html http://www.oilshell.org/blog/2017/05/05.html [2] http://www.oilshell.org/site.html http://www.oilshell.org/site.html [3] Build System Observations http://www.oilshell.org/blog/2017/05/31.html http://www.oilshell.org/blog/2017/05/31.html