It was fine in its era, but that's a long time ago. It is completely unsuitable as a project management tool and a poor task runner.
Also its ubiquity is overhyped. There's no build platform where I can't download the tools I need, that's the entire point of a build platform, and most such platforms come with far more advanced tools pre-installed.
So it gets used a lot and it's only a language for dependencies and rules. It doesn't do "project management". Its the simplicity of what it's trying to that saves it from ever becoming irrelevant - because it can be made to fit almost any use case. It's not a special tool for enforcing one structure or building only one language - something that seems highly regressive to me but which is adopted by many languages now.
This is a non-priority, an unreal use case. I can't build GCC without a functioning C++ compiler and a fairly sophisticated OS environment and that's fine. Real-world use cases for bootstrapping a build environment from rubbing two sticks together are so exceptionally rare as to be near fictional.
Even if we allow that such cases exist, they are unicorns, not a thing to design tools around.
> It's not a special tool for enforcing one structure or building only one language - something that seems highly regressive to me but which is adopted by many languages now.
This is what makes it so unsuitable. A tool that can make no assumptions about its application is less and less useful a tool. A bread knife is better at cutting bread than a plain 10" kitchen knife, a boning knife better for deboning, etc.
We live in a world where for every language there are build tools that know far, far more about the needs of that language environment than make, and thus are far better suited.
The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. The more they assume the more niche they become.
So you might come up with some new thing that "Works For Me" and now all those people who are peacefully using the tool on their whatever platform have to fiddle with it to make it work again - or the person who made it work is no longer around and that platform loses support for the new versions.
When you say "cultural" you make it sound like people do things because they are ignorant and resistant to change but it's worth at least considering that their point of view is quite different.
They already do dominate. In the last bastion where make can be said to be popular (C) make has already lost to CMake and its usage shrinks every year [1]
The situation is moving even faster for C++ [2]
And for literally every other language in the systems programming space (C#, Swift, Rust, D, Go, Zig), make was never a player to begin with.
[1]: https://www.jetbrains.com/lp/devecosystem-2022/c/#which-proj...
[2]: https://www.jetbrains.com/lp/devecosystem-2022/cpp/#Which-pr...
There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake. It's slightly easier to understand than autotools, though, where one has the same problem.
That make happens to be a possible target of CMake is irrelevant to this discussion, it replaces the usage of make. make becomes an implementation detail.
No one should be writing Makefiles. You also shouldn't be using make as the underlying task runner but for a different set of reasons.
> There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake
You need exactly zero understanding of make or ninja to use CMake. Ninja explicitly is not meant to be understood by end users, and only as a target for generators like CMake:
>Where other build systems are high-level languages Ninja aims to be an assembler ... it is designed to have its input files generated by a higher-level build system [1]
You cannot name a single use case where it is beneficial to know the mechanics of make when using CMake, much less the mechanics of Ninja.
You would use compile_commands.json for this, which would show you the literal commands being invoked. What program is doing the invoking is 100% irrelevant. If the invoking program is what is breaking your build, your build is screwed beyond comprehension.
You don't need to know LLVM IR or the GCC intermediate representations, you don't need to know the internals of the ELF format, and you don't need to know make.
If you want to know these things more power to you, but don't insist that everyone should be writing LLVM IR because it's a more general building block than C++ or that anyone should use make for the same reason.
Languages don't exist in a vacuum.
A big reason for the resurgence of make by developers is every language/environment comes with something new that tries to recreate make. They all have issues and limitations where make ends up being a better tool.
Also, when you need to deal with multiple languages in a project, these tools tend not to be that helpful.
As a web developer, there's been so many attempts to make tools like gulp [1], grunt [2], npm scripts [3], web pack [4], etc. and a dozen more, to do a part of what make has been doing for decades. And literally every 6–12 months, there's a new, hot tool that everyone gets excited about. It's just reinventing the wheel over and over.
Now that I've settled on make for web projects, it's no longer a concern.
I much rather describe my dependencies using make than JavaScript (ugh), which many of these tools use. Some tools fall out of favor; developers stop creating plugins or whatever for them. As a user of the tool, you can find yourself shit out of luck for your particular project or use case.
The beauty of make is it can handle the tasks of building a web site or web app using modern tools that didn't exist when it was created. As someone mentioned further up, make is eternal; it's not going anywhere.
[1]: https://gulpjs.com
[2]: https://gruntjs.com/
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.
plan9 exists in an enviable position of only needing to build in a few controlled environments.
For example, http://9p.io/sources/plan9/sys/src/libmach/mkfile reads:
CFLAGS=$CFLAGS -I/sys/src/cmd
/shrug
Try reading the llama.cpp makefile, which is an example of an excellent cross platform makefile that works very well: https://github.com/ggerganov/llama.cpp/blob/master/Makefile
^ this is what many real Makefiles look like, and this one is excellent and well maintained.
Many are worse.
Make is good when you only have easy problems to solve (like, specifically, only having to build one specific constrained environment for one specific compiler).
I have good news for you: this is already the case! In all modern versions of make you can use semicolons instead of tabs.
You just write
target : dependencies ; rule
target : dependencies
^Irule
Many times, a Makefile snippet in an HTML page or a PDF file has had the tab character auto-magically morphed into spaces. So when it is copied, it will be a syntax error in a Makefile. Even copying Makefile snippets from one terminal window to another will eat those tab characters. Fortunately my vim editor is configured to handle most of those edge cases now, but it took me... I don't know... 10-15 years to get that right.
My personal rule is that control characters which are visually indistinguishable from other characters have no place in source code which are meant to be written, read, and copied by human beings. So yeah, that includes the <tab> character. And yes, I do think the Golang people got that wrong, although the 'go fmt' command largely solves that problem. Except when reading Go source code on web sites which don't handle tabs well, and you are nested 6 levels deep, and half the code is unreadable because it's bled off the right side of the page.
This is a text editor configuration issue, not a character choice issue.