3 ms·

What would you use instead? What does a bleeding-edge modern C++ build system look like? conan + meson?

MaxBarraclough 6y ago
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 https://news.ycombinator.com/item?id=24209573
0xabe 6y ago
Qbs https://doc.qt.io/qbs/index.html https://doc.qt.io/qbs/index.html https://youtu.be/ZS0aWEi0338 https://youtu.be/ZS0aWEi0338 (Unfortunately it has been deprecated)

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 https://news.ycombinator.com/item?id=24209573

0xabe 6y ago

Qbs https://doc.qt.io/qbs/index.html https://doc.qt.io/qbs/index.html https://youtu.be/ZS0aWEi0338 https://youtu.be/ZS0aWEi0338 (Unfortunately it has been deprecated)