Skip to content

Support Bazel 9#597

Closed
smolkaj wants to merge 4 commits intomainfrom
bazel9-support
Closed

Support Bazel 9#597
smolkaj wants to merge 4 commits intomainfrom
bazel9-support

Conversation

@smolkaj
Copy link
Member

@smolkaj smolkaj commented Feb 28, 2026 •
edited
Loading

Summary

  • Removes the <9.0.0 upper bound from bazel_compatibility and bumps .bazelversion to 9.0.0.
  • Adds --incompatible_autoload_externally=+cc_library,+cc_binary to both .bazelrc files (root and bzlmod example). Bazel 9 removed native C++ rules from the global namespace; this flag restores the autoload for cc_library and cc_binary. The flag is a no-op on Bazel 7/8 where the rules remain native.
    • grpc 1.76.0 bazel/cython_library.bzl still uses native.cc_binary (upstream fix landed after the v1.78.0 tag)
    • grpc 1.76.0 third_party/address_sorting/address_sorting.bzl still uses native.cc_library (not yet fixed upstream)
  • Bumps re2 to 2025-11-05.bcr.1: gRPC 1.76.0 pulls in re2 2024-07-02.bcr.1 whose BUILD uses cc_test without a load(), which is another Bazel 9 hard error; the November 2025 release fixes that.
  • Adds 9.x to the CI matrix and removes the "once we support Bazel 9" TODO.

Notes

The --incompatible_autoload_externally workaround can be dropped once gRPC releases a BCR version that replaces native.cc_* with properly-loaded rules in those two files.

Test plan

  • CI passes on ubuntu-22.04, bazel-9.x
  • CI passes on ubuntu-latest, bazel-9.x
  • CI still passes on Bazel 7.x and 8.x

🤖 Generated with Claude Code

@smolkaj
Update Bazel dependencies and migrate off googleapis switched_rules
82083b4 
Motivation: These changes are required for P4Runtime to build
successfuly for downstream users who depend on it in their own projects.
This was dicovered while upstreaming P4Runtime v1.5.0 to the BCR, see
bazelbuild/bazel-central-registry#7594.

- Upgrade googleapis and replace the
  switched_rules extension with the new per-language modules
  (googleapis-cc, googleapis-go, googleapis-python, googleapis-grpc-cc).
  The old switched_rules extension only processes use_languages() calls
  from the root module, which breaks BCR presubmit and downstream users
  who don't call it themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>
@smolkaj
Close coverage gap in CI script, ensuring all targets built from anot…
1833d12 
…her Bazel workspace.

Details:
- In Bazel, it is possible and not uncommon that a project builds from its own workspace, but fails to build when depended on from another workspace.
- We have an example project in example/using-bzlmod that we build in our CI script to ensure both direct and transitive builds work.
- Despite this, in bazelbuild/bazel-central-registry#7594, P4Runtime did not build even though our CI script passed.
- The gap: our example project exercises some, but not all @p4runtime targets in a transitive fashion.
- The solution: run bazel build @p4runtime//... from the example workspace to close the gap.
- The proof: I reproduced the issue seen in bazelbuild/bazel-central-registry#7594 in #591.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>
@smolkaj smolkaj marked this pull request as draft February 28, 2026 08:02
@smolkaj smolkaj changed the base branch from update-bazel-deps to main February 28, 2026 08:06
@smolkaj @claude
Support Bazel 9
c90a487 
Bazel 9 removed native C++ rules from the global namespace by default
(native.cc_binary, native.cc_library).  Two gRPC 1.76.0 bundled files
still use these:
  - bazel/cython_library.bzl uses native.cc_binary
  - third_party/address_sorting/address_sorting.bzl uses native.cc_library

Use --incompatible_autoload_externally=+cc_library,+cc_binary to restore
the autoload for those rules.  This flag is a no-op in Bazel 7/8 where
the rules remain native.

Note: the flag is a workspace-local setting and is therefore not
propagated to downstream users, who will need to add it themselves until
a fixed gRPC BCR release ships.

Also:
- Bump re2 to 2025-11-05.bcr.1 (BCR grpc 1.76.0 pulls in re2
  2024-07-02.bcr.1 whose BUILD uses cc_test without load(), which is
  another Bazel 9 error; the 2025-11-05 release fixes that).
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add 9.x to the CI matrix and remove the "once we support Bazel 9" TODO.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@smolkaj @claude
CI: test on Bazel 7.x and 9.x only (skip 8.x)
0599472 
Bazel 8 is expected to work (it is between two tested versions), so
there is no need to test it explicitly.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
smolkaj added a commit to p4lang/p4c that referenced this pull request Feb 28, 2026
@smolkaj @claude
Support Bazel 9
59bf7db 
Bazel 9 is now released. The only blocker is that BCR `p4runtime 1.5.0`
declares `bazel_compatibility < 9.0.0`. Suppress the check via
`--check_bazel_compatibility=off` until a new p4runtime BCR release is
cut (tracked in p4lang/p4runtime#597). Unlike `git_override`, this flag
works for modules published to the BCR.

Also add a Bazel version matrix to CI (7.x and 9.x), and fix macOS
builds: use Command Line Tools clang to avoid requiring a full Xcode
install, and set `macos_minimum_os=10.15` which is the minimum for
`std::filesystem` support in libc++.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This was referenced Feb 28, 2026
Merged
Merged
smolkaj added a commit to smolkaj/bazel-central-registry that referenced this pull request Feb 28, 2026
@smolkaj
Add p4runtime 1.5.0.bcr.1
a035653 
The 1.5.0 BCR entry declares bazel_compatibility = [">=7.0.0", "<9.0.0"],
blocking downstream users from upgrading to Bazel 9. The upper bound is overly
conservative; no Bazel-9-specific incompatibilities exist. This new .bcr.1
release removes it so BCR users can adopt Bazel 9.

The upstream fix is tracked at p4lang/p4runtime#597.

Changes from 1.5.0:
- MODULE.bazel: remove upper bound, bump version to 1.5.0.bcr.1, add re2
  dependency (required by gRPC on Bazel 9), update googleapis/grpc/protobuf
  to latest BCR versions
- proto/p4/{config/v1,v1}/BUILD.bazel: load proto_library from
  @protobuf//bazel rather than the deprecated @rules_proto
- presubmit.yml: test on Bazel 7.x and 9.x
bazel-io pushed a commit to bazelbuild/bazel-central-registry that referenced this pull request Feb 28, 2026
@smolkaj
Add p4runtime 1.5.0.bcr.1 (#7742)
970d887 
## Motivation

The 1.5.0 BCR entry declares `bazel_compatibility = [">=7.0.0",
"<9.0.0"]`,
blocking downstream users from upgrading to Bazel 9. The upper bound is
overly
conservative — no Bazel-9-specific incompatibilities were found. This
entry
adds a `.bcr.1` release that removes it so BCR users can adopt Bazel 9.

The upstream fix is tracked at
p4lang/p4runtime#597.

## Implementation

A single patch (`fix_bazel_files.patch`) transforms the raw source
tarball into
the desired state, mirroring the structure of the existing `1.5.0`
entry:

- `MODULE.bazel`: remove upper bound and TODO comment, bump version to
  `1.5.0.bcr.1`, add `re2` dep (required by gRPC on Bazel 9), update
  `googleapis`/`grpc`/`protobuf` to latest BCR versions
- `proto/p4/{config/v1,v1}/BUILD.bazel`: load `proto_library` from
  `@protobuf//bazel` rather than the deprecated `@rules_proto`
- `presubmit.yml`: test on Bazel 7.x and 9.x
smolkaj added a commit to p4lang/p4c that referenced this pull request Mar 1, 2026
@smolkaj @claude
Support Bazel 9
d46189c 
Bazel 9 is now released. The only blocker is that BCR `p4runtime 1.5.0`
declares `bazel_compatibility < 9.0.0`. Suppress the check via
`--check_bazel_compatibility=off` until a new p4runtime BCR release is
cut (tracked in p4lang/p4runtime#597). Unlike `git_override`, this flag
works for modules published to the BCR.

Also add a Bazel version matrix to CI (7.x and 9.x), and fix macOS
builds: use Command Line Tools clang to avoid requiring a full Xcode
install, and set `macos_minimum_os=10.15` which is the minimum for
`std::filesystem` support in libc++.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
smolkaj added a commit to p4lang/p4c that referenced this pull request Mar 1, 2026
@smolkaj @claude
Support Bazel 9
3d4c149 
Bazel 9 is now released. The only blocker is that BCR `p4runtime 1.5.0`
declares `bazel_compatibility < 9.0.0`. Suppress the check via
`--check_bazel_compatibility=off` until a new p4runtime BCR release is
cut (tracked in p4lang/p4runtime#597). Unlike `git_override`, this flag
works for modules published to the BCR.

Also add a Bazel version matrix to CI (7.x and 9.x), and fix macOS
builds: use Command Line Tools clang to avoid requiring a full Xcode
install, and set `macos_minimum_os=10.15` which is the minimum for
`std::filesystem` support in libc++.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@smolkaj smolkaj mentioned this pull request Mar 1, 2026
Open
@smolkaj
Copy link
Member Author

smolkaj commented Mar 1, 2026

Superseded by #590, which now incorporates all the Bazel 9 changes.

@smolkaj smolkaj closed this Mar 1, 2026
smolkaj added a commit to smolkaj/bazel-central-registry that referenced this pull request Mar 1, 2026
@smolkaj
Add p4runtime 1.5.0.bcr.1
af23587 
The 1.5.0 BCR entry declares bazel_compatibility = [">=7.0.0", "<9.0.0"],
blocking downstream users from upgrading to Bazel 9. The upper bound is overly
conservative; no Bazel-9-specific incompatibilities exist. This new .bcr.1
release removes it so BCR users can adopt Bazel 9.

The upstream fix is tracked at p4lang/p4runtime#597.

Changes from 1.5.0:
- MODULE.bazel: remove upper bound, bump version to 1.5.0.bcr.1, add re2
  dependency (required by gRPC on Bazel 9), update googleapis/grpc/protobuf
  to latest BCR versions
- proto/p4/{config/v1,v1}/BUILD.bazel: load proto_library from
  @protobuf//bazel rather than the deprecated @rules_proto
- presubmit.yml: test on Bazel 7.x and 9.x
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@smolkaj