cmake generates makefiles (or ninja) so it doesn't replace them. It replaces autotools - it works out what features a system has and what build flags to enable and from a generic description of your program it generates makefiles or ninja.build.

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.

> cmake generates makefiles (or ninja) so it doesn't replace them

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.

[1] https://ninja-build.org/

When something doesn't build properly then you start needing to know the details and your logic about how make is an implementation detail is true of everything in the end - nobody cares how builds are done compared to the thing they build and often they don't care about that either except that it is needed by something which they need.

> When something doesn't build properly then you start needing to know the details and your logic

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.