On 22/05/2024 08:58, Peter Dimov via Boost wrote:
I guess another way of putting it, what substantial benefit does b2 provide to Boost that is not provided by CMake ...
From my point of view, some examples are
b2 toolset=msvc-14.3,gcc warnings=extra warnings-as-errors=on
or
b2 toolset=msvc-14.0,msvc-14.1,msvc-14.2,msvc-14.3 cxxstd=14,latest variant=debug,release
or
b2 toolset=gcc,clang undefined-sanitizer=norecover
or
b2 libs/something/test
where that last line doesn't need a separate run with -DBUILD_TESTING=ON, or -DBOOST_INCLUDE_LIBRARIES=something, or a separate ctest run, all test types are supported equally well, and everything is automatically parallelized.
I thought somebody else might reply to this specific set of why b2 has advantages over cmake, but they didn't, so I suppose I will. Build variants are provided by toolchain files in cmake. You can provide a directory of canned toolchain files named by what they do (e.g. gcc-12-asan.cmake), this is what most do, but there is another option: cmake script files which generate toolchain files on the fly. cmake has a perfectly good scripting functionality such that one could write a b2.cmake whereby: ``` cmake -P b2.cmake -- toolset=msvc-14.0,msvc-14.1,msvc-14.2,msvc-14.3 cxxstd=14,latest variant=debug,release ``` if you don't want to run the test suite, or: ``` ctest -S b2.cmake -- toolset=msvc-14.0,msvc-14.1,msvc-14.2,msvc-14.3 cxxstd=14,latest variant=debug,release ``` if you do want to run the test suite. The cmake script file writes out the toolchain files for each toolset, and invokes cmake/ctest to do each of the builds per toolchain file. If one so chose, the b2.bat/b2 shell script could then invoke cmake -P b2.cmake/ctest -S b2.cmake as appropriate in a way that existing b2 based build systems would mostly "just works". You thus migrate to a 100% cmake based build fully portable to everywhere cmake works, but `b2` works just as now. Now as to whether this is worth doing or not ... for me personally, b2 gets the job of building Boost done, for that it "just works". Where I have been very keen on cmake build support is for when I wish to directly include a part of Boost into my existing code not as an external project, or imported targets, but **directly** because of large advantages to seeing Boost internals in debuggers, or for particularly bespoke or custom build settings. And Boost's cmake support now does all that, so for me I'm satiated and happy as an end user. For Boost library devs and the release maintainers it's a very different set of trade offs, but they're a tiny minority of the userbase, so TBH whatever suits them best they can choose. If they want to maintain two build systems, rock on. My only skin in the game is a header only library, so I really don't mind what is chosen so long as the userbase still gets full fat Boost cmake build support. Niall