Hans Dembinski wrote:

...

On 21. May 2024, at 09:24, Alexander Grund via Boost wrote:

There are many libraries ready for building & testing with CMake: Mentioned (Atomic, Filesystem, Log, JSON), Mine (Nowide, Locale) and likely all Peter is maintaining.

Histogram, too.

All libraries build under CMake. To see what of them have CMake tests, you can look at this CI run: https://github.com/boostorg/boost/actions/runs/9171879935/job/25217197221 This excludes Geometry because its tests take an (additional) hour. :-) Developer documentation (not yet quite finished) is here: https://github.com/boostorg/cmake/blob/develop/developer.md but it doesn't yet cover testing. (It's on my to-do list.) There are several ways to implement testing, for each one there's probably an existing library that can be used as a template. The easiest one is to use boost_test_jamfile, which takes an existing Jamfile in test/ and (simple-mindedly) interprets it to create CMake tests. Endian is an example of using this testing strategy: https://github.com/boostorg/endian/blob/develop/test/CMakeLists.txt https://github.com/boostorg/endian/blob/develop/test/Jamfile.v2

On Tue, May 21, 2024 at 10:42 AM Robert Ramey via Boost wrote:

My interest is to remove b2 from the mix and still provide all the facility that I now enjoy.

You can't. It's required for the general testing and release management.

I have CMake testing implemented but it's not really integrated in the way that I want. I want to generate my Library_Status table for my libraries. I would also like to implement support for CDash.

That's all great. As long as it's in addition to the B2 support.

I've complained about the current system for years. It's just gotten to the point where I can't continue without fixing it up to my taste.

Has there been a point where I didn't address, or try to address, your concerns with B2? Or are the problems outside of B2? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

On Tue, May 21, 2024 at 2:50 PM Richard via Boost wrote:

Well, that's a shame. If I'm writing a new library for inclusion in boost, the *last* thing I want to do is write b2 scripts.

Are you volunteering to: 1. Write new release scripts which use cmake instead of b2, 2. Implement the building of all documentation using cmake 3. Submit pull requests to all libs to update their build scripts for cmake (docs included)? Thanks

On 5/22/24 01:50, Christian Mazakas via Boost wrote:

On Tue, May 21, 2024 at 2:55 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

Are you volunteering to: 1. Write new release scripts which use cmake instead of b2,

Maybe we should start considering it, given that we're already running into discrepancies like so:

Switching release scripts to CMake won't remove the need to maintain two build systems as long as we have to support them both for any reason. That is, dropping Boost.Build would require *everything* to work via CMake, not just the release scripts. Also, dropping Boost.Build would be a breaking change to those users who actually use Boost.Build. I'm not sure how many there are, but I suspect they do exist. I wonder if Boost.Build could be somehow improved to interface with CMake, so that Boost transition to CMake-only, if and when it happens, is more or less painless for the users.

Fwiw, Unordered is actually kind of guilty of this as well. Unordered's Jamfile has more tests than its CMake files do.

This certainly isn't ideal and shows the pain of maintaining two separate build systems.

One way to keep the build systems in sync is not having to sync at all. Just scan the filesystem and generate targets for tests based on what is found. This can be done more or less equivalently in both Boost.Build and CMake. For example: https://github.com/boostorg/scope/blob/eea343a918c586387b1b717c31c0a24bc612e... https://github.com/boostorg/scope/blob/eea343a918c586387b1b717c31c0a24bc612e... Of course, it isn't quite as easy for building the library, but for tests it's very doable.

Rewriting the release script to do its testing and generation of the install tree via CMake shouldn't be a huge change in theory, I'd imagine. But I've never looked at the scripts. All I know is, building Boost via CMake is very doable and running the tests is similarly doable.

One significant difference between the official releases on jfrog from CMake releases is the unified include tree. This tree is needed for building docs (at least, for some libraries), as well as some Boost users and packagers. If we are going to preserve our official releases backward compatible, CMake needs to be able to generate the unified header tree.

Christian Mazakas wrote:

On Tue, May 21, 2024 at 2:55 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

...

3. Submit pull requests to all libs to update their build scripts for cmake

This will definitely be the most time-consuming part but if we did a library a day every day, we'd be done in like a year!

We're already done because all of Boost builds (and installs) with CMake.

In general, I agree with Richard's sentiment. b2 is holding Boost back...

It's interesting that nobody considers the possibility that b2 is in fact a better build system than CMake, and consequently, that switching from b2 to CMake will actually make things _worse_ in some, if not many, respects. There's this axiomatic assumption that dropping b2 will automatically improve things, somehow, and I don't think it's true or warranted.

вт, 21 мая 2024 г. в 18:42, Robert Ramey via Boost :

I would also like to implement support for CDash.

You keep bringing up CDash. How is it in any way better than having a proper CI system? It's basically CI, but manual, and with fewer platforms. вт, 21 мая 2024 г. в 21:05, Alain O' Miniussi via Boost :

I use CMake for building and testing Boost.MPI. Not sure I added the last tests to the b2 framework.

This implies that MPI is not fully tested for release. ср, 22 мая 2024 г. в 07:55, Robert Ramey via Boost :

Hmmm ... Better in what way? They should produce the same result or close to it. My problem with B2 is that its complex, hard to understand, a lot of work to maintain and fragile.

I wondered what makes b2 so complex compared to CMake, so I opened two files from your project: one for b2 build, and another for CMake build https://github.com/boostorg/safe_numerics/blob/develop/test/Jamfile.v2 https://github.com/boostorg/safe_numerics/blob/develop/test/CMakeLists.txt Both look very simple and linear. The difference with the CMake file is that it sets properties used by IDE generators. Now, the CMake file uses such functions like test_run_pass, test_compile_pass, and test_compile_fail. These functions aren't a part of CMake itself, they are defined inside the project's root CML. For example, this is the definition of test_compile_fail: https://github.com/boostorg/safe_numerics/blob/develop/CMakeLists.txt#L129-L... So, the test is supposed to be run, fail, and the developer mentally (although, I guess physically, in a notebook, also works) checks it as succeeding. In a way it is in line with your appreciation for CDash, which is a sort of manual CI. Some people may think that surely, there should be a less backwards way to run compile-fail tests in CMake. There is! Peter Dimov has implemented it as part of his CMake support: https://github.com/boostorg/cmake/blob/develop/include/BoostTest.cmake#L187-.... The trick is to automate the "run and fail" part. The function launches _another_ instance of CMake that tries to build the target and fails. So, to be honest, I'm not a fan of abandoning b2 in favour of CMake. And I didn't even touch on multiconfig builds.

I also very much like that CMake can be used to create GUI projects in XCode, VS, etc. I actually use this facility.

I give you this, CMake does have good integration with IDEs. BTW, there have been several remarks about people having problems with b2 which couldn't be solved. But I don't see those on ML. Maybe I'm not subscribed to the correct list? I would be glad to help you with those issues, if I can.

----- On May 22, 2024, at 9:55 AM, Дмитрий Архипов via Boost boost@lists.boost.org wrote:

вт, 21 мая 2024 г. в 18:42, Robert Ramey via Boost :

...

I would also like to implement support for CDash.

вт, 21 мая 2024 г. в 21:05, Alain O' Miniussi via Boost :

...

I use CMake for building and testing Boost.MPI. Not sure I added the last tests to the b2 framework.

This implies that MPI is not fully tested for release.

It's never been, at some point b2 did not support some versions of Intel MPI, so all these were dropped. I was answered that "this is an Intel problem", which was true, but not helpful. Some other MPI implementation had their own issues. Depending on the cluster configuration, I need to switch between mpirun, mpiexec, srun etc... I'm sure it can be done with b2, but I don't even know where to start. I can't even find where the b2 MPI test launcher is located. And it's not widespread to the point that people will be likely to address these problems.

ср, 22 мая 2024 г. в 07:55, Robert Ramey via Boost :

...

Hmmm ... Better in what way? They should produce the same result or close to it. My problem with B2 is that its complex, hard to understand, a lot of work to maintain and fragile.

I wondered what makes b2 so complex compared to CMake, so I opened two files from your project: one for b2 build, and another for CMake build https://github.com/boostorg/safe_numerics/blob/develop/test/Jamfile.v2 https://github.com/boostorg/safe_numerics/blob/develop/test/CMakeLists.txt

I find them difficult to write, not to read. - Alain

----- On May 22, 2024, at 3:14 PM, Peter Dimov via Boost boost@lists.boost.org wrote:

Alain O' Miniussi wrote:

...

I can't even find where the b2 MPI test launcher is located.

Should be here somewhere:

https://github.com/bfgroup/b2/blob/main/src/tools/mpi.jam

Seems documented, even

https://github.com/bfgroup/b2/blob/cd7c1537f81d1fc408ea3124c997aa7ba539a606/...

Thanks, Actually, the part I should be looking for is more around line 588 (class mpi-test-generator). I guess I did at some point.

Peter Dimov via Boost writes:

It's interesting that nobody considers the possibility that b2 is in fact a better build system than CMake, and consequently, that switching from b2 to CMake will actually make things _worse_ in some, if not many, respects.

That may be true, but if you took a vote among all the Boost users asking them which build system Boost should drop, I think it's pretty clear what the large majority's answer would be.

There's this axiomatic assumption that dropping b2 will automatically improve things, somehow, and I don't think it's true or warranted.

A less obvious benefit of dropping one of the two build systems is that it frees you up to potentially adopt a forward-looking build system (or rather build system + package manager toolchain). While supporting two build systems has its overheads, supporting three would be untenable. I guess another way of putting it, what substantial benefit does b2 provide to Boost that is not provided by CMake or could not be provided by another build system (that would also provide other substantial benefits)?

Peter Dimov writes:

Boris Kolpackov wrote:

...

That may be true, but if you took a vote among all the Boost users asking them which build system Boost should drop, I think it's pretty clear what the large majority's answer would be.

If we supported build2 and CMake and we took that same vote, I'm fairly sure what the answer would be, too.

Yes, at this stage the answer to "CMake vs X" is clear for any X. But in case of build2 I believe you would at least be able give some tangible reasons as to why you are supporting both.

...

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.

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"). So maybe the insights here are: 1. It's unfortunate that the C++ community has largely settled on a meta-build system. 2. In a complex project like Boost there will always be a need for a native build system to accommodate more advanced use-cases. And, FWIW, all of the examples you have shown can be done with build2. The mental model is a bit different and some things are a bit more verbose at the moment, but the fundamentals like the ability to build with multiple compilers in the same build system invocation or automatically pull what's necessary is there. BTW, can b2 do something like this: b2 host-toolset=gcc host-variant=release toolset=aarch64-linux-gnu-gcc variant=debug And then build tools used during the build (like Qt moc) with (host) GCC while the rest with (target) GCC cross-compiler?

Peter Dimov writes:

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.

Hm, in my experience it's the other way around: end-users find it too tedious to remember the sequence of options to enable the right set of warnings for each compiler, etc. On the other hand, how often do you write a test that needs to be built with exceptions disables and how hard is it to specify the actual options for essentially two classes of C++ compilers: MSVC and everything else?

Then there's the separate "run ctest" phase, which you didn't list.

I am not certain why they did it this way but I strongly suspect one of the main reasons is the limitation of the underlying build systems they have to support (point 1 in my list).

ср, 22 мая 2024 г. в 12:27, Boris Kolpackov via Boost :

BTW, can b2 do something like this:

b2 host-toolset=gcc host-variant=release toolset=aarch64-linux-gnu-gcc variant=debug

The quick answer is "not exactly, and not out of the box". The long answer follows. As b2 is not a package manager, it doesn't have a special understanding of build and target platforms. In b2 every target has _some_ target platform implicitly defined by the sum of its properties, and some of those properties also implicitly define the build platform. So, there's no notion of build and target for the entire target graph. But you can create a dedicated feature that sets the properties of the build platform. To be clear, it's fairly non-trivial to do, but see this: https://gist.github.com/grisumbras/040b3b5ffc3572e395cbb3a8c9c11c09 If built with b2 host-platform=x86_64-linux-gnu-release variant=debug target-os=windows toolset=gcc the preprocessor program (moxtool) is built for the host (Linux), and the library is built for Windows.

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

On Tue, May 21, 2024 at 7:28 PM Peter Dimov via Boost wrote:

It's interesting that nobody considers the possibility that b2 is in fact a better build system than CMake, and consequently, that switching from b2 to CMake will actually make things _worse_ in some, if not many, respects.

There's this axiomatic assumption that dropping b2 will automatically improve things, somehow, and I don't think it's true or warranted.

For what it's worth, I'm not proposing anything concrete or actionable. But I was, ironically, musing the other day if b2 was holding Boost back from receiving more outside contributions. If we want Boost to survive and thrive, we need contributors. Potential contributors don't know b2, they know CMake. We can argue that yes, libraries support CMake and contributors can use that as their primary tooling but b2 will eventually worm its way into the equation. Whether or not b2 is a better build system is irrelevant because no one knows it and no one seems keen on learning it. It's relegated solely to Boost and its developers. All that being said, this was just something I was musing. I have no idea in all actuality if completely dropping b2 will bring contributors back to Boost. But I kind of agree with Richard in that, I think it is a turn off. The usage of "warranted" stood out to me, btw. We should regularly evaluate our tools and consider technical costs and potential directions we might want to steer the project. Where will Boost be and what state will it be in five years from now? What state do we want it to be in? - Christian

On Wed, May 22, 2024 at 9:38 AM Peter Dimov via Boost wrote:

The only part of Boost suffering from lack of outside contributions is b2 itself, which problem is not going to be solved by dropping b2.

Yup. This is the alternative path. With some elbow grease, we could make b2 a lot better. Maybe it'd be good if we enumerate our gripes with it so we at least have an outline here. One of my biggest gripes with it is how permissive it can be in many cases. It'd be nice if there were strict modes where you can require something like zlib and b2 fails if it's not found. Maybe this is already supported but who knows. I think it's also a function of documentation and working examples as well. Error message output also isn't the best with b2 either. I'm thinking about the time I forgot to add a: using asciidoctor ; to my user-config.jam. b2's output was absolutely unintelligible to me and it was even to the people walking me through the steps. - Christian

From: Boost on behalf of Peter Dimov via Boost Date: Tuesday, May 21, 2024 at 9:28 PM To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] Boost/CMake Christian Mazakas wrote:

On Tue, May 21, 2024 at 2:55 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

...

3. Submit pull requests to all libs to update their build scripts for cmake

This will definitely be the most time-consuming part but if we did a library a day every day, we'd be done in like a year!

We're already done because all of Boost builds (and installs) with CMake.

In general, I agree with Richard's sentiment. b2 is holding Boost back...

It's interesting that nobody considers the possibility that b2 is in fact a better build system than CMake, and consequently, that switching from b2 to CMake will actually make things _worse_ in some, if not many, respects. There's this axiomatic assumption that dropping b2 will automatically improve things, somehow, and I don't think it's true or warranted. B2 seems perfectly capable, and it’s use in boost releases mostly proves that – I’m not arguing that CMake has a better feature set, has a more active development community, or is easier to understand. I would argue that CMake is just as good as B2, and it’s advantage is that almost every project in the open source community is using it successfully. Switching is a costly prospect – but the fact that many boost library developers are already paying that price for the advantages they thing CMake gives them means that it has obvious value. My own experience is that using b2 has always been a struggle simply because boost is the only thing I have ever encountered that used it. I also recall that CMake 2.x was no panacea, when I first looked into it I was unimpressed, but in 2024 CMake has no rivals and my team uses it for at least 80 different projects, many of which are legacy systems where the main body of work we’ve done is create the CMake build.

----- On May 22, 2024, at 12:50 AM, Christian Mazakas via Boost boost@lists.boost.org wrote:

In general, I agree with Richard's sentiment. b2 is holding Boost back and nowadays, even packagers are moving on from it and are building Boost purely via CMake or are relying on Boost's CMake support.

Maybe I missed something, but I was unable to build with b2 with a clang based Cray compiler. I can understand why since it's not publicly available (it's a PITA with most tools actually) but CMake was able to do the job. Maybe that's a corner case, it's difficult to know how many unknown compilers are out there. -- Alain

Rob Boehne wrote:

Boost would be better if it used CMake for building releases – that is really where it’s most important, where the average user comes into contact with the build.

We don't build our releases - they are source code. (Well, except for Windows, but those take advantage of b2's ability to build more than one configuration at once. That's not impossible to achieve with CMake but it's not clear what exactly we'll gain.)