That's a good observation.

Any deficiency in a complex, widely used and difficult to change development tool will be fixed by adding an extra layer over it.

If the deficiency is something like complexity or lack of reliability that can not be fixed by adding extra layers, read this comment again.

Great example is Fastlane abstracting over the impenetrable iOS command line tools.

Is that how cmake came to exist?

Cake came into existence because all other alternatives were pure crap.

And since cmake's inception, all cmake alternatives are still pure crap.

The definition of "well" is relative.

> And since cmake's inception, all cmake alternatives are still pure crap.

…including CMake. :-)

Although, to be fair, I think CMake did at least achieve to prove that creating a turing complete "jack of all trades" meta build system is not a good idea in pretty much every case (although I'd argue that boost had done that well in advance).

It's too sad that with the myriad of legacy patterns around in the C/C++ build space (in production), there is pretty much 0 chance of simplifying the problem for a majority of cases instead.

Yeah cmake is pretty crappy, and it's a shame that nothing better popped up in the last, say, 20 years.

However, to be fair cmake's main problem is it's appalingly poor documentation and user experience. It's very telling that since the release of cmake 3 the main source of info on how to do cmake the right way is not anythig churned out by cmake, whose docs are pretty much unintelligible, but random blog posts that manage to put together basic idiomatic code snippets.

This poor state of affairs is reflected in collaborative sources of info such as stack overflow, where well-meaning users reiterate poor or straight-out wrong ways of doing things mainly because they don't and can't know better.

> cmake's main problem is it's appalingly poor documentation and user experience.

"I thought I was dumb until I realized it's the book".

Top Amazon review of the top book on CMake. And I am still wondering whether it is the book, or the tool.

So, while not just use distribution package creation and managing tools, like the Debian ones? Or even better Guix?

As I said, to me the whole thing looks like a giant log jam made of bad tools causing other bad tools and there is no simple way of cleaning up the landscape without whipping out a chainsaw and breaking existing workflows and use cases first.

However, if you are in the privileged position of being able to address every use case by compiling and/or cross-compiling from a nix or Guix setup for a project, I'd certainly go with that, too.

The problem there is that this is likely never the case if you can't just containerize your application or prescribe which system it will run on -- which holds true for a lot of software.

That's why I stopped using Ansible in favour of pyinfra.