|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-05-22 13:27:35
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk