I'm not suggesting it's a good idea to drop CMake for one of its obscure rivals, that's why I put You should still probably use CMake. I don't want to have to learn an obscure build-system to work on someone's project, and I won't ask others to do the same for me.

To revisit the points I made in the old thread [0]:

We pay a price for fragmentation; it's better we all agree on one system. (Although I think it's fair to say that autotools has had its time in the sun at this point, I don't see a big problem in using it for Unix-only projects.) CMake can work very well, with impressive portability, if a project's CMake scripts are rock-solid. I plan to continue to use CMake, despite its considerable shortcomings.

If CMake did the following things, I could probably forgive the atrocious scripting language:

1. Overhaul the documentation. Every unit of documentation should be accompanied by an illustrative example; dry rambling essays are not the right format. Do what Microsoft do with their .Net documentation.

2. Official design-patterns for common tasks like Find modules. They shouldn't each have a character of their own. These scripts ought to be very consistent, very boilerplate-driven, and very boring.

3. Rework the officially bundled CMake scripts so that they all follow the current best-practices to the letter. As it stands, there's nowhere to go to see what real CMake scripts are meant to look like.

I would suggest a linter/improved errors and warnings, but I don't know if that's practical. I would suggest replacing the entire scripting language with something less awful, but it wouldn't do to throw out compatibility. Stability is a must-have for this kind of thing.

[0] https://news.ycombinator.com/item?id=24209573

Qbs

https://doc.qt.io/qbs/index.html

https://youtu.be/ZS0aWEi0338

(Unfortunately it has been deprecated)