True, but having "sophisticated" build processes are a problem in their own right. I understand that there may be special cases, but generally, if you have troubles making a build process work with Make, then using a "better" tool is just paving over the underlying problem.

Just today I was trying to help a friend build some tool with Bazel. While I'm sure there's a reason for Bazels existence, but it's just way to complex. The build failed and debugging the Bazel config was just a major hassle compared to had we just looked at the Java commands in a Makefile.

Similar with Pythons setuptools, even though that is significantly easier with the new pyproject.toml. It's really powerful, but what all I wanted is basically to copy a bunch of files and add a bit of metadata.

Not only that, but look at any advanced-age project that uses make. There are layers of includes, and defines and rules are smeared across multiple files.

I think many modern web-build tools were made by people who thought "hey, I can do better than make" (or worse, "What's make?" and reinvented the wheel) and then wound up in a similar conundrum.

The creator of Make actually apologized for it, as far as I have read.

I'm very happy with Make, though I have to agree, the syntax could be better. I don't mind using tabs, but why are spaces not OK as well? It would also be good to be able to not have to break long lines or multiline things with backslashes all the time. Yes you can set that oneshell thingy, but that is inconvenient in other ways, because it is for the whole file instead of a single command or a single target.

So it could be better, definitely, but it does the job of doing DAGs well and it is available on most systems, so I don't have to add some huge tree of dependencies just to run tasks.