boost 1.92.0 and externpro 26.01.5-35-gf401f71 sync

[smanders]

Summary

Sync externpro configuration and files

Changes

• Updated .gitignore with externpro patterns
• Created .github/release-tag.json (tag: xpvboost-1.92.0.1)
  • Optional: add the "release:tag" label to trigger tagging, release builds, and draft release notes
• If you add the "release:tag" label, the tag will be `xpvboost-1.92.0.1`
• Updated dependency files
  • Files:
    • xprodeps.md
    • xprodeps.svg

Workflow Update Report

• 🔧 xpbuild.yml: preserved repo key jobs.linux.with.cmake_workflow_preset_suffix
• 🔧 xpbuild.yml: preserved repo key jobs.macos.with.cmake_workflow_preset_suffix
• 🔧 xpbuild.yml: preserved repo key jobs.windows.with.cmake_workflow_preset_suffix

---

This PR was created automatically by GitHub Actions

[smanders]

Windows CI: MSB8066 ... exited with code -1 after Boost 1.92.0

Symptoms

On Windows, the b2.build ExternalProject step fails at the install phase with:

...updated 18523 targets...
Completed 'b2.build'
error MSB8066: Custom build for '...b2.build-download.rule; ...b2.build-install.rule; ...b2.build-complete.rule; ...b2.build.rule; ...CMakeLists.txt' exited with code -1.

The contradiction is intentional: b2 itself prints a successful-looking summary and returns exit code 0, but the Visual Studio / MSBuild CustomBuild task treats some line of b2 stdout as a fatal error and aborts the whole step with code -1.

Root cause

b2 install emits a non-fatal diagnostic that starts with error::

error: No best alternative for .../libs/histogram/install-libraries-shared with <link>static ... <variant>debug ...
    no match: <local-visibility>hidden

This is repeated for variant=debug and variant=release.

Why histogram?

libs/histogram/build.jam sets the project-level requirement <local-visibility>hidden. histogram is a header-only library, so boost-install is called with an empty $(libraries) list and creates install-libraries-shared (and similar) targets with no source libraries. The inherited <local-visibility>hidden causes b2 select-alternatives to find no matching alternative for that empty target, so it prints error: No best alternative.

b2 does not consider this a build failure and exits 0. However, MSBuild's CustomBuild / Exec tasks parse command output with a standard warning/error regex and treat any line containing error: as a fatal build error, producing MSB8066 ... exited with code -1.

Why only Windows?

The same error: lines appear on Linux and macOS, but those CI jobs use the Ninja CMake generator, which does not scan command output for error:/ warning: patterns. Only MSBuild (Visual Studio generator) does this. That is why the failure was Windows-only (VS2022 and VS2026).

Upstream fix

The issue is properly fixed in libs/histogram itself:

• boostorg/histogram@2193e29a — fix: move b2 project requirements out of build.jam (#433)

That commit removes <local-visibility>hidden from the histogram project requirements and moves the visibility/warning flags into test/Jamfile and examples/Jamfile, where they belong.

Externpro workaround

Because the externpro superproject currently pins libs/histogram from boostorg/histogram (not a fork), we cannot commit that change directly to the histogram submodule. Instead, we added a defensive guard in the externpro-forked tools/boost_install submodule:

• tools/boost_install/boost-install.jam

The boost-install and boost-install stage logic now only creates install-libraries-static, install-libraries-shared, stage-libraries-static, stage-libraries-shared, and the associated unprefixed variants when there is at least one actual library to install:

if $(libraries)
{
    install install-libraries-static : $(libraries) : ... ;
    alias install-libraries-shared : install-libraries-shared- ;
    ...
}

if $(unprefixed)
{
    install install-unprefixed-static : $(unprefixed) : ... ;
    ...
}

and similarly for the stage targets. This prevents the empty install-libraries-shared target from ever being created for header-only modular libraries, so b2 no longer prints the error: line that MSBuild trips over.

Verification

1. Reproduced on macOS by running the exact b2 install command from the generated build.ninja:
   • Before the patch: error: No best alternative for .../libs/histogram/install-libraries-shared appears twice.
   • After the patch: no error: or No best alternative output, b2 still exits 0.
2. Windows CI (xpbuild with VS2022 and VS2026) now passes.

Related references

• MSBuild parses error:/warning: in command output and can fail a custom build step even when the underlying process returns 0.
• curl/curl#16583 and the CMake developers' list describe the same MSBuild CustomBuild / Exec diagnostic-regex behavior and the difficulty of disabling it from CMake-generated projects.

Files changed

• tools/boost_install/boost-install.jam — guard creation of empty library install/stage targets.
• Superproject pointer update for tools/boost_install.

TODO / follow-up

• When libs/histogram is next bumped to a commit containing boostorg/histogram@2193e29a, this tools/boost_install guard could be re-evaluated, but it is harmless to keep because it only suppresses empty no-op targets.

[smanders]

changes from the boost-1.92.0 tag to the xpv1.92.0.1 tag release
boost-1.92.0...xpv1.92.0.1

[smanders]

issue externpro/externpro#345