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
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:
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
platformoffered more complex constraints to be specified (e.g. old or new) it might work better