Re: Boost/CMake

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-05-23 14:39:47

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