Looks like our CMake misses some of the b2 features
Hi, Looks like b2 was doing many things behind the scene and I've get used to it. Now I'm getting instantly hit by bugs because CMake misses the functionality. Below are some of the missing features ## Installation testing With b2 there is no need to test installation. It just works. CMake is different in that place, without CI scripts to test installation things break ( https://github.com/boostorg/dll/issues/102, https://github.com/boostorg/pfr/issues/217 ) ## CLI convenience cd libs/pfr/tests; ../../../b2 toolset=gcc14,gcc-15,clang-21 cxxstd=11,14,17,20,23,26 variant=debug, release and the library is tested in 36 configurations. CMake miss that functionality, and it also can not be run from libs/pfr/tests. Instead of that a list of libraries should be provided via CMake variable. Workarounds via CI matrix or shell scripts are clumsy and require copy pasting between Boost libraries. The same story with C++20 modules. If b2 was able to build modules, the syntax would be like modules=on. With CMake it is -DBOOST_USE_MODULES=1 -DCMAKE_EXPERIMENTAL_CXX_IMPORT_STD=0e5b6991-d74f-4b3d-a41c-cf096e0b2508 -G Ninja. ## Non-run tests CMake miss the compile, compile-fail, link, link-fail testing rules of b2 https://www.boost.org/doc/libs/1_76_0/tools/build/doc/html/index.html#bbv2.b... ## Double efforts for build scripts Manual rewriting of Jamfiles to CMakeLists is boring and tiring. Keeping those two in sync is pain. ## Regression tests matrix The regression tests https://regression.boost.io/develop/developer/summary.html use b2. As a result cmake tests are limited to github CI only. # How to make things better In my naiive opinion many of the above issues could be bypassed by the following steps: 1) How about adjusting b2 to be able to run cmake? I mean it should under the hood convert b2 arguments into CMake arguments and run the cmake and tests. It can check for particular tests compile/link failures to emulate the missing cmake functionality. It could also run the the installation tests (test against an installed Boost library) 2) Can b2 fallback to CMake if there's no Jamfile? In that way the developers could transparently move from Jamfiles to CMake As a bonus, the following step could simplify the migration: 3) Can b2 be adjusted to generate CMakeLists from Jamfiles? Not necessary fully functional, but at least something to simplify the migration.
El 13/09/2025 a las 11:47, Antony Polukhin via Boost escribió:
Hi,
Looks like b2 was doing many things behind the scene and I've get used to it. Now I'm getting instantly hit by bugs because CMake misses the functionality.
[...]
## CLI convenience cd libs/pfr/tests; ../../../b2 toolset=gcc14,gcc-15,clang-21 cxxstd=11,14,17,20,23,26 variant=debug, release and the library is tested in 36 configurations. CMake miss that functionality, and it also can not be run from libs/pfr/tests. Instead of that a list of libraries should be provided via CMake variable. Workarounds via CI matrix or shell scripts are clumsy and require copy pasting between Boost libraries.
Chris Mazakas wrote a convenient script to cover that use case: https://github.com/cmazakas/c2 It'd be terrific if this tool were formally adopted by Boost and placed under boost/tools. Joaquín M López Muñoz
El 13/09/2025 a las 11:47, Antony Polukhin via Boost escribió:
Hi,
Looks like b2 was doing many things behind the scene and I've get used to it. Now I'm getting instantly hit by bugs because CMake misses the functionality.
3) Can b2 be adjusted to generate CMakeLists from Jamfiles? Not necessary fully functional, but at least something to simplify the migration.
This sort of achieves the same result: https://github.com/boostorg/bloom/blob/develop/test/CMakeLists.txt Joaquín M López Muñoz
Antony Polukhin wrote:
## Non-run tests CMake miss the compile, compile-fail, link, link-fail testing rules of b2 https://www.boost.org/doc/libs/1_76_0/tools/build/doc/html/index.html#bbv2.b...
If you use BoostTest.cmake, it supports those. https://github.com/boostorg/cmake/blob/8da84d1b53cc23000e39294eeac817c899783... https://github.com/boostorg/uuid/blob/2b160eb689ca3775b9522ce9437655e905967b...
## Double efforts for build scripts Manual rewriting of Jamfiles to CMakeLists is boring and tiring. Keeping those two in sync is pain.
If your test/Jamfile is simple enough, you can use boost_test_jamfile. https://github.com/boostorg/endian/blob/c0b5c80603b8de7eeea8724c9a4f2761c3df...
Many thanks for all the hints and tweaks! Does it mean that CMake is now the default build system and we can drop the b2?
On 13 Sep 2025 16:58, Antony Polukhin via Boost wrote:
Many thanks for all the hints and tweaks!
Does it mean that CMake is now the default build system and we can drop the b2?
No. Documentation is still only built with b2. Not all libraries support testing with CMake, many still have a single test that simply verifies that building with CMake works. I believe, our officially distributed binaries are still built using b2.
c2.py needs alpha testers. We should use LLMs to convert testing Jamfiles. And we can solve documentation via CMake too, it's just tedious. - Christian
On Sat, 13 Sept 2025, 21:48 Vinnie Falco via Boost, <boost@lists.boost.org> wrote:
On Sat, Sep 13, 2025 at 12:01 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
c2.py needs alpha testers.
Consider explaining what that is, for the folks that don't know
The project README explains it quite well. Although Python is a subjective choice to me, the whole idea of b2-ifying proxy script for CMake has a huge potential. ... I'd write it in C++. I'd contribute the features to CMake itself, as ultimate long term goal. Mateusz
On Sat, Sep 13, 2025 at 12:58 PM Mateusz Loskot via Boost < boost@lists.boost.org> wrote:
The project README explains it quite well. Although Python is a subjective choice to me, the whole idea of b2-ifying proxy script for CMake has a huge potential. ... I'd write it in C++. I'd contribute the features to CMake itself, as ultimate long term goal.
Yeah, I wrote it in Python just because it has quick iteration times. You're right in that if we wrote it in C++, it ships better as a part of Boost because we already require a compiler be present on the host machine. Plus, we don't actually have to do anything all that fancy to get it working. Also, I actually did realize this belongs in CMake itself and that I basically fixed CMake lol. I've wanted something like this in CMake for every single project I've ever written. To Vinnie's point and for those that don't know, c2.py is a port of b2 that does parallel CMake configurations and then can do a superbuild of all of them at the same time with full throughput. CTest support is also included this. The tool works relatively simply. We just create a root build directory, then we do a nested build directory for each configuration. We generate a superbuild ninja file in the root which includes all the child ninja files. Doing this requires us actually modify the CMake-generated ninja files but it's not that hard to make it all play nicely. We also then make a custom CTest file which enables us to run all of the tests in parallel as well. The tool supports a b2-style CLI and also a JSON file that describes the build. This is a good opportunity for Boost because it means there's one less reason to depend on b2. Currently, I'm looking for alpha testers to let me know where all the rough edges and problems are. - Christian
participants (7)
-
Andrey Semashev -
Antony Polukhin -
Christian Mazakas -
Joaquin M López Muñoz -
Mateusz Loskot -
Peter Dimov -
Vinnie Falco