You seem to forget about autotools. Cmake is ugly but I'll take it over autotools.

As an end user: at least with autotools it's easy for me to see the available configuration options with ./configure --help in a nicely readable way. cmake has -LAH but it's still... kind of awful.

At least it knows how to use ninja though.

Problem is autotools doesn't work when cross compiling - the options are there but there is always something wrong, and it isn't easy to fix. cmake can at least get that right. Note that I cross compile a lot of code so this matters to me, if you just do the common thing autolools might work - but make would as well then.

Yeah; generally I find CMake rules are much easier to read and modify than autotools and makefiles. With Makefiles there’s about 18 different ways to write a rule to compile something, and I find I need to go hunting through a bunch of files to figure out how this makefile in particular defined a rule for compiling this C file in particular. CMake is much higher level. I can just see all the higher level targets, and how they’re built. Then - orthogonally - I can modify the build system that CMake uses to compile C code. It makes a lot more sense.

But I’d take cargo over any of this stuff. Cargo means I don’t have to think about compiler flags at all.

If you find yourself doing a lot of cross compiling C check out the Zig build system.

I am not going to rewrite the build system of a third party library.