I think Cmkr fails to state its value proposition by focusing on how it works. Any system like CMake that wraps boatloads of complexity is going to have unexpected interactions and inscrutable failures. The question for any developer who doesn't want to become a build system guru is whether they can take a happy path far from any gotcha's. That's when people start defining conventions to solve classes of problems: fo…
Turn on all warnings? Yeah, just check if your CC is MSVC or else and set the flag!
Turn on sanitizers? Yeah, just include this 2000 line piece of CMake macro that checks your CC and turns on flags!
Find a package? Yeah, just write a FindFooCMake macro file that spells out the exact files to find in the filesystem and parses a header with more macro magic to determine the version. Maybe we decide to ship this shitty macro file with the default distribution later on and cause more conflicts and distress. By the way, we now have a superior C++ namespace inspired way of defining packages that we mix and match with the old stuff in our default distribution.
Can't you just use pkg-config files like everyone else? Yeah, just make sure to include another 3000 line CMake macro if you specifically want us to use pkg-config.
Cross compile my program for a different architecture? Of course CMake supports that, as long as you write a toolchain file that spells out the exact CC, CXX, sysroot, ... and all other things that could even get a maximally minimal Makefile to trivially cross compile. Make sure to force-overwrite some of the useless autoconfig inspired tests CMake will perform on your toolchain because they are broken with whatever cross compiler you are trying to use.
So while CMake does nothing to help with common things, their "CMakeCache" is the most powerful proof for "nothing is more complicated in programming than caching" the world has ever seen.