You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
platform
offered more complex constraints to be specified (e.g. old or new) it might work betterThe text was updated successfully, but these errors were encountered: