Try to fix failing b2 + cmake test

[mborland]

No description provided.

[mborland]

@Flamefire any idea how to fix the failures with your new B2 + Cmake test? I tried manually adding the cmake config information in the cmake/ folder, but that doesn't seem to work out.

[Flamefire]

I tried manually adding the cmake config information in the cmake/ folder, but that doesn't seem to work out.

This test is for testing that the CMake config installed using the B2 workflow can actually be consumed by CMake, to mirror what a user would do.
So changing the CMake files is not required here as IIRC B2 doesn't use (or even know) about those.

However it makes sense to ensure that those are also complete.

You are missing the install part in the B2 files, for header only libs I checked Boost.System: https://github.com/boostorg/system/blob/e6595f0d6481b5759e9282d97d0205e65e358187/build.jam#L24-L26

I.e. in your build.jam below call-if : boost-library safe_numbers add install boost_safe_numbers

I added some comments while checking your changeset with things I noticed while reading the diff

[mborland]

You are missing the install part in the B2 files, for header only libs I checked Boost.System: https://github.com/boostorg/system/blob/e6595f0d6481b5759e9282d97d0205e65e358187/build.jam#L24-L26

I.e. in your build.jam below call-if : boost-library safe_numbers add install boost_safe_numbers

I'll give that a shot. I thought install lib was only for compiled libs.

[mborland]

This error is new as of this morning (see https://github.com/cppalliance/safe_numbers/actions/runs/25377007558/job/74414709606?pr=197):

Run cd "$BOOST_ROOT"
  cd "$BOOST_ROOT"
  mkdir __build_cmake_test__ && cd __build_cmake_test__
  cmake -G "Visual Studio 17 2022" -DCMAKE_BUILD_TYPE=Debug -DBOOST_INCLUDE_LIBRARIES=$SELF -DBUILD_SHARED_LIBS=OFF -DBUILD_TESTING=ON -DBoost_VERBOSE=ON ..
  cmake --build . --target tests --config Debug -j$B2_JOBS
  ctest --output-on-failure --build-config Debug
  shell: C:\Program Files\Git\bin\bash.EXE --noprofile --norc -e -o pipefail {0}
  env:
    GIT_FETCH_JOBS: 8
    NET_RETRY_COUNT: 5
    B2_VARIANT: debug,release
    B2_LINK: shared,static
    LCOV_BRANCH_COVERAGE: 1
    CODECOV_NAME: Github Actions
    BOOST_CI_TARGET_BRANCH: develop
    BOOST_CI_SRC_FOLDER: D:/a/safe_numbers/safe_numbers
    SELF: safe_numbers
    BOOST_ROOT: /d/a/safe_numbers/boost-root
    B2_TOOLSET: 
    B2_COMPILER: 
    B2_CXXSTD: 11
    B2_JOBS: 5
CMake Error at CMakeLists.txt:13 (project):
  Generator

    Visual Studio 17 2022

  could not find any instance of Visual Studio.

According to the GHA README Windows 2025 is supposed to have that version installed: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md.

[Flamefire]

Might be an issue with that runner. The same job in Boost.CI just passed for me: https://github.com/boostorg/boost-ci/actions/runs/25378171088/job/74418838451?pr=336

[mborland]

@Flamefire Is there a library that you know is using Boost.CI and passing this B2 + CMake test so I can try and copy-paste their setup?

I make it to here now:

CMake Error at CMakeLists.txt:11 (find_package):
  Found package configuration file:

    /tmp/boost_install_b2/lib/cmake/boost_safe_numbers-1.92.0/boost_safe_numbers-config.cmake

  but it set boost_safe_numbers_FOUND to FALSE so package
  "boost_safe_numbers" is considered to be NOT FOUND.  Reason given by
  package:

  No suitable build variant has been found.

[Flamefire]

The current switch from find_package(Boost isn't really necessary.

The problem is that this is a header-only library and targets for those are only created by the CMake installation process, but not (yet) by B2. See current discussion in Slack.

Basically for this test using the installed library you'd need to use the headers component and target instead, while the sub-dir test and when installed by CMake the current, specific target can be used.

I just added a commit to Boost.CI to help with that: boostorg/boost-ci@e70bf6d

As for the issues with Visual Studio, I've noticed this warning in the logs:

NOTICE: windows-2025 requests are being redirected to windows-2025-vs2026 by May 12, 2026

And there VS 2022 isn't installed -.- So maybe they already doing the change randomly.
See actions/runner-images#13638

Let's see what comes out of that.

[mborland]

The current switch from find_package(Boost isn't really necessary.

Depending on the CMake version, you either get a warning that find_package(Boost is deprecated or that it is removed. Not sure why it still works when it's been "removed" (probably because of the quite old version still in our cmake_minimum_required), but we should probably move past it incase it actually is removed in the future.

The problem is that this is a header-only library and targets for those are only created by the CMake installation process, but not (yet) by B2. See current discussion in Slack.

Basically for this test using the installed library you'd need to use the headers component and target instead, while the sub-dir test and when installed by CMake the current, specific target can be used.

I just added a commit to Boost.CI to help with that: boostorg/boost-ci@e70bf6d

Thanks. I saw the conversation, but it wasn't entirely clear to me how to apply it.

As for the issues with Visual Studio, I've noticed this warning in the logs:

NOTICE: windows-2025 requests are being redirected to windows-2025-vs2026 by May 12, 2026

And there VS 2022 isn't installed -.- So maybe they already doing the change randomly. See actions/runner-images#13638

Let's see what comes out of that.

Always something with GHA.

[Flamefire]

Depending on the CMake version, you either get a warning that find_package(Boost is deprecated or that it is removed. Not sure why it still works when it's been "removed" (probably because of the quite old version still in our cmake_minimum_required), but we should probably move past it incase it actually is removed in the future.

This is only the FindBoost.cmake that gets removed, which has nothing to do with our Config files.
You can avoid the warning by setting the policy, or telling CMake to auto-enable it when running in a newer CMake: cmake_minimum_required(VERSION 3.5...3.31)
Or just ignore it, no harm there.

[mborland]

Looks like we're finally good here. Thanks for the help @Flamefire