Boris Kolpackov wrote:
But in case of build2 I believe you would at least be able give some tangible reasons as to why you are supporting both.
Honestly...
The common theme for these examples is the fundamental limitations of meta- build systems compared to native build systems:
- Meta-build systems are limited by the underlying build systems (make, ninja, msbuild, etc) that they must delegate to.
- Meta-build systems partition the build graph into two disjoint (or poorly joint) sub-graphs: configuration/project generation and build proper (in a sense, this is the same problem as "recursive make considered harmful").
That's part of it, but not all. Abstracting toolset-specific compile options, or rather lack of it, is not caused by any of the above. E.g. exception-handling=off, rtti=off, warnings-as-errors=on. There's nothing in CMake's architecture that precludes it, it's just not done. For the user audience who needs to build something with a specific toolset, using specific options, that's not an issue - you just hardcode the CMAKE_CXX_FLAGS. But for the audience of me who needs to write his test/CMakeLists.txt such that test_no_exceptions.cpp is compiled without exceptions, regardless of the user generator or compiler, this won't do at all. That's one reason why CMake isn't better _for me_, the developer who needs to write the build script. (There are of course reasons why CMake _is_ better for me.) Then there's the separate "run ctest" phase, which you didn't list. In b2, running tests is done by the build phase, each test has its own build node, is handled uniformly, participates in the parallel build, etc. You can tell b2 "build and run this specific test", and it will build the test and whatever it depends on, then run it.