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.