Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Platform compatibility issues for Bazel 7+8 #330

Open
mkruskal-google opened this issue Jan 29, 2025 · 1 comment
Open

Platform compatibility issues for Bazel 7+8 #330

mkruskal-google opened this issue Jan 29, 2025 · 1 comment

Comments

@mkruskal-google
Copy link

mkruskal-google commented Jan 29, 2025

I'm trying to migrate our small example repo to use clang-cl on windows. We test this repo under a bunch of different configurations to ensure that the protobuf rules work for downstream users. The relevant configurations here are Bazel 7 and Bazel 8, using either bzlmod or workspace.

When we added support for Bazel 8, we had to migrate MODULE.bazel to use @rules_cc//cc:extensions.bzl, because it no longer exists in @bazel_tools. Following https://bazel.build/configure/windows#clang, we defined a platform using @bazel_tools//tools/cpp:clang-cl. Unfortunately, this constraint value changes drastically between Bazel 7 and Bazel 8:

  • In Bazel 7 + bzlmod, this is a constraint value for a setting defined in @bazel_tools. This is distinct from the @rules_cc constraint, and toolchain resolution fails (because @local_config_cc is coming from @rules_cc now).
  • In Bazel 8 + bzlmod, this is an alias for the setting in @rules_cc and toolchain resolution works.

If I switch the constraint value to @rules_cc//cc/private/toolchain:clang-cl, ignoring the fact that I'm reaching into private stuff, I get a different problem. Both bzlmod builds work now, since they both use the @rules_cc constraint value. However, the WORKSPACE build fails because @local_config_cc seems to come from bazel by default (in Bazel 7). If I explicitly call rules_cc_toolchains() in my WORKSPACE file, all 4 configurations now seem to work.

This was a very painful process to debug, and the only solution I found that worked was to reference something private from @rules_cc. I think at the very least this should probably be documented somewhere more surfaceable (I had to dig through internal code at multiple releases of two different github repos). But bigger picture, it seems like the strategy of using aliases as a migration tool for constraint_values is flawed. If platform offered more complex constraints to be specified (e.g. old or new) it might work better

@comius
Copy link
Collaborator

comius commented Jan 29, 2025

Related to this: bazelbuild/bazel#25128

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants