As you say, a small elegant makefile is lovey.

That is not the sort of makefile you get from the autoconf/automake family, and (ha!), good luck if something goes wrong.

The reality is that a small simple makefile is not sufficient to build real software.

The problem is fundamentally that make doesn’t compose well.

Most real build systems such as cmake, scons, cargo, etc. provide primitives for dealing with complex messy situations like “oh today I’m using visual studio not clang” or “does this platform have stdbool.h?” or “is the flag for disabling a warning different on this compiler?”

…and a way of composing that tasks into smaller ones (eg. add_subdirectory() and find_package()).

Make does not.

Make is a simple tool for simple tasks.

The reason people don’t like it, in my experience, is they have had to work with a make based project that has grown beyond the trivial size and it’s become a nightmare.

It makes easy things easier, and hard things much harder.

If worked on SPAs where they used make instead of webpack; but it’s a stupid solution. It doesn’t do live reloading, or any of the other pipeline stuff… but by gosh they tried!

You know what I like about clojure? It’s a simple tool that scales well for both simple and complex tasks.

Make simply doesnt.

…and that is reflected in the reality, which is that increasingly build tools are moving away from it and towards others, even for the low level tasks that people used to “generate makefiles” for eg. to ninja

I really am not a cmake fan; but there absolutely no denying it works very well in many real world situations, where trivial “-lsqlite” flags in a naive makefile don’t and cant work.