Re: Boost/CMake

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-05-22 00:10:58

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_at_[hidden]> 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/eea343a918c586387b1b717c31c0a24bc612e5c9/test/CMakeLists.txt#L32-L54

https://github.com/boostorg/scope/blob/eea343a918c586387b1b717c31c0a24bc612e5c9/test/Jamfile#L46-L91

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.