Add tooling for populating boost versions #6179

UebelAndre · 2025-10-11T12:49:47Z

Changes:

Adds modules/boost/add_boost_version.py for populating boost versions.
Introduce boost meta-module which allows for validation of all available boost modules in a single module.
Backfills missing 1.88.0.bcr.1 boost versions.

bazel-io · 2025-10-11T12:50:05Z

Hello @Vertexwahn, modules you maintain (boost.coroutine2, boost.foreach, boost.geometry, boost.graph, boost.heap, boost.icl, boost.lockfree, boost.log, boost.mysql, boost.phoenix, boost.process, boost.property_tree, boost.serialization, boost.sort, boost.spirit, boost.xpressive) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

bazel-io · 2025-10-11T12:50:06Z

Hello @wep21, modules you maintain (boost.foreach, boost.geometry, boost.graph, boost.heap, boost.icl, boost.log, boost.phoenix, boost.process, boost.property_tree, boost.serialization, boost.sort, boost.spirit, boost.xpressive) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

bazel-io · 2025-10-11T12:50:06Z

Hello @vtsao-openai, modules you maintain (boost.heap, boost.lockfree) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

bazel-io · 2025-10-11T12:50:07Z

Hello @lalten, modules you maintain (boost.log) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

bazel-io · 2025-10-11T12:50:08Z

Hello @kekxv, modules you maintain (boost.mysql) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

bazel-io · 2025-10-11T12:50:08Z

Hello @hofbi, modules you maintain (boost.process) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

bazel-io · 2025-10-11T12:50:09Z

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (boost) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

gemini-code-assist

Code Review

This pull request introduces a valuable script for automating the addition of new Boost versions and backfills version 1.88.0.bcr.1 for numerous Boost modules. The overall approach and implementation are solid. I've identified a couple of instances where test-only dependencies should be marked as development dependencies and a minor inconsistency in the generated presubmit configuration for the new boost meta-module. Addressing these points will improve dependency management for downstream users and ensure consistent test coverage.

gemini-code-assist · 2025-10-11T12:52:22Z

modules/boost.heap/1.88.0.bcr.1/MODULE.bazel

+bazel_dep(name = "boost.container", version = "1.88.0.bcr.1")
+bazel_dep(name = "boost.foreach", version = "1.88.0.bcr.1")
+bazel_dep(name = "boost.test", version = "1.88.0.bcr.1")
+bazel_dep(name = "platforms", version = "1.0.0")


Dependencies that are only used for testing should be marked as development dependencies with dev_dependency = True. This prevents them from being transitively included for downstream users of this module, reducing dependency bloat.¹

Suggested change

bazel_dep(name = "boost.container", version = "1.88.0.bcr.1")

bazel_dep(name = "boost.foreach", version = "1.88.0.bcr.1")

bazel_dep(name = "boost.test", version = "1.88.0.bcr.1")

bazel_dep(name = "platforms", version = "1.0.0")

bazel_dep(name = "boost.container", version = "1.88.0.bcr.1", dev_dependency = True)

bazel_dep(name = "boost.foreach", version = "1.88.0.bcr.1", dev_dependency = True)

bazel_dep(name = "boost.test", version = "1.88.0.bcr.1", dev_dependency = True)

bazel_dep(name = "platforms", version = "1.0.0", dev_dependency = True)

Style Guide References

Footnotes

The style guide indicates that development dependencies can be specified with dev_dependency = True and will be ignored when the module is used as a dependency. It is best practice to use this for test-only dependencies. ↩

gemini-code-assist · 2025-10-11T12:52:22Z

modules/boost.sort/1.88.0.bcr.1/MODULE.bazel

+bazel_dep(name = "boost.test", version = "1.88.0.bcr.1")
+bazel_dep(name = "platforms", version = "1.0.0")


Dependencies that are only used for testing should be marked as development dependencies with dev_dependency = True. This prevents them from being transitively included for downstream users of this module, reducing dependency bloat.¹

Suggested change

bazel_dep(name = "boost.test", version = "1.88.0.bcr.1")

bazel_dep(name = "platforms", version = "1.0.0")

bazel_dep(name = "boost.test", version = "1.88.0.bcr.1", dev_dependency = True)

bazel_dep(name = "platforms", version = "1.0.0", dev_dependency = True)

Style Guide References

Footnotes

The style guide indicates that development dependencies can be specified with dev_dependency = True and will be ignored when the module is used as a dependency. It is best practice to use this for test-only dependencies. ↩

gemini-code-assist · 2025-10-11T12:52:22Z

modules/boost/add_boost_version.py

+PRESUBMIT_CONTENT = """\
+matrix:
+  platform:
+    - debian10
+    - debian11
+    - macos
+    - macos_arm64
+    - ubuntu2004
+    - ubuntu2204
+    - windows
+  bazel: [7.x, 8.x]
+tasks:
+  verify_targets:
+    name: Verify build targets
+    platform: ${{ platform }}
+    bazel: ${{ bazel }}
+    build_flags:
+      - '--process_headers_in_dependencies'
+    build_targets:
+      - '@boost//...'
+"""


The PRESUBMIT_CONTENT for the meta-module is missing ubuntu2404 in the platform matrix and rolling in the bazel versions. Other new boost modules in this PR include them. These should be added for consistency and to ensure the meta-module is tested on all relevant platforms and Bazel versions. After updating the script, please regenerate the presubmit.yml for boost/1.88.0.bcr.1.

PRESUBMIT_CONTENT = """\ matrix: platform: - debian10 - debian11 - macos - macos_arm64 - ubuntu2004 - ubuntu2204 - ubuntu2404 - windows bazel: [7.x, 8.x, rolling] tasks: verify_targets: name: Verify build targets platform: ${{ platform }} bazel: ${{ bazel }} build_flags: - '--process_headers_in_dependencies' build_targets: - '@boost//...' """

UebelAndre · 2025-10-11T13:05:39Z

@bazel-io skip_check compatibility_level

UebelAndre · 2025-10-11T13:05:47Z

@bazel-io skip_check unstable_url

vtsao-openai

🚀

modules/boost/add_boost_version.py

fmeum · 2025-10-11T20:32:06Z

modules/boost/add_boost_version.py

+    name = "boost",
+    version = "{version}",
+    bazel_compatibility = [">=7.6.0"],
+    compatibility_level = {compatibility_level},


Do we still need this? If we assume 7.6.0, could we rely on nodep deps and the synthetic boost module to force the same version for all modules?

I'm not actually familiar with the impact of compatibility level. It was only something I saw when trying to use boost modules and it blocked me from being able to use them. So I tried to conform to what I thought was the existing pattern. If there's a better path forward for the meta module then I'm open to adding it.

Depending on module versions with different compatibility levels is an error, which makes deps on boost somewhat risky right now. If the public API isn't actually all that unstable but consistent versions have to be used of different boost modules, forcing them all to the highest version in the graph via a bazel_dep cycle could be an alternative.

@Vertexwahn @wep21 for input

@fmeum You mean we should add bazel_dep(name = "boost.pin_version", version = "1.88.0.bcr.1") to modules/boost/1.88.0.bcr.1/MODULE.bazel? Makes sense - but then we also need to add bazel_dep(name = "boost", version = "1.88.0.bcr.1", repo_name = None) to modules/boost.pin_version/1.88.0.bcr.1/MODULE.bazel - since we have the policy "do not modifiy existing things" - the change is currently not possible - therefore, I would drop it for now (1.88.0.bcr.1 and 1.89.0), and do it mabye for boost@1.90.0 (which comes in December) or 1.88.0.bcr.2 and 1.89.0.bcr.1, etc.

Sounds good to me.

We probably wouldn't need pin_version anymore if we already have a boost meta module, right?

@meteorcloudy If new boost versions end up with cyclic dependencies, we would need to make sure that CI can handle them in a single PR.

@UebelAndre In the past, all attempts to get many boost modules in at the time failed - I propose you split this PR (maybe 6-10 modules per PR) - maybe an own PR for boost tooling - of course, you can still try to get in everything in on PR but I think there some rate limits with Apple build jobs, etc. that will give you a hard time... do whatever works for you - just my personal experience... -> see this PR for instance: #4989 which never made it in becaue of "reasons"

I did notice most jobs failing to fetch github metadata. There should probably be a retry added but i have no idea where the code lives for bcr_presubmit.py. I would expect CI to be able to handle rate limits and I think updates to boost should generally happen in one change.

If new boost versions end up with cyclic dependencies, we would need to make sure that CI can handle them in a single PR.

I think it should work already?

I did notice most jobs failing to fetch github metadata.

There were some network issue on macOS VMs last week. Retried.

I'm also hearing complaints from users about bumped compatibility_level for boost libraries. Do I understand correctly that the plan is to stop bumping it with the next boost version and switch to use non-dep with the boost module?

I would expect CI to be able to handle rate limits and I think updates to boost should generally happen in one change.

I agree, let me know if CI is blocking this. Currently we are having outage for macOS VMs and are still working on finding a solution. bazelbuild/continuous-integration#2385

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Require module maintainers' approval for newly pushed changes.

UebelAndre mentioned this pull request Oct 11, 2025

[Bug]: Many boost modules missing in latest version #4930

Open

gemini-code-assist bot reviewed Oct 11, 2025

View reviewed changes

UebelAndre added 2 commits October 11, 2025 05:57

Added script to add boost modules

bd53c08

boost@1.88.0.bcr.1

58ad8a0

UebelAndre force-pushed the boost branch from 6710513 to 58ad8a0 Compare October 11, 2025 12:57

This comment was marked as duplicate.

Sign in to view

bazel-io added skip-compatibility-level-check Skip the compatibility_level check for MODULE.bazel skip-url-stability-check Skip the URL stability check for the PR labels Oct 11, 2025

This comment was marked as resolved.

Sign in to view

Vertexwahn mentioned this pull request Oct 11, 2025

boost@1.88.0.bcr.1 #5226

Open

vtsao-openai previously approved these changes Oct 11, 2025

View reviewed changes

fmeum added the presubmit-auto-run Presubmit jobs will be triggered for new changes automatically without reviewer's approval label Oct 11, 2025

fmeum reviewed Oct 11, 2025

View reviewed changes

modules/boost/add_boost_version.py Outdated Show resolved Hide resolved

fmeum reviewed Oct 11, 2025

View reviewed changes

Update modules/boost/add_boost_version.py

19e4389

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

UebelAndre added 3 commits October 11, 2025 15:53

regenerate meta module

9b7ed8e

Merge branch 'bazelbuild:main' into boost

2ac2f72

ignore pin_version

0a41734

Vertexwahn approved these changes Oct 12, 2025

View reviewed changes

		bazel_dep(name = "boost.test", version = "1.88.0.bcr.1")
		bazel_dep(name = "platforms", version = "1.0.0")

Add tooling for populating boost versions #6179

Are you sure you want to change the base?

Add tooling for populating boost versions #6179

Conversation

UebelAndre commented Oct 11, 2025

Uh oh!

bazel-io commented Oct 11, 2025

Uh oh!

bazel-io commented Oct 11, 2025

Uh oh!

bazel-io commented Oct 11, 2025

Uh oh!

bazel-io commented Oct 11, 2025

Uh oh!

bazel-io commented Oct 11, 2025

Uh oh!

bazel-io commented Oct 11, 2025

Uh oh!

bazel-io commented Oct 11, 2025

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Oct 11, 2025

Choose a reason for hiding this comment

Style Guide References

Footnotes

Uh oh!

gemini-code-assist bot Oct 11, 2025

Choose a reason for hiding this comment

Style Guide References

Footnotes

Uh oh!

gemini-code-assist bot Oct 11, 2025

Choose a reason for hiding this comment

Uh oh!

This comment was marked as duplicate.

UebelAndre commented Oct 11, 2025

Uh oh!

UebelAndre commented Oct 11, 2025

Uh oh!

This comment was marked as resolved.

vtsao-openai left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vertexwahn Oct 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Vertexwahn Oct 12, 2025 •

edited

Loading