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/
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.