Expose compiler constraint values in public API

[srikantharun]

Summary

• Adds public constraint_setting and constraint_value targets to //cc/compiler
• Converts cc/private/toolchain constraints to aliases for backward compatibility
• Updates BUILD.windows.tpl to use new public paths

Problem

Users who need to define platforms constrained by compiler type currently have to reference @rules_cc//cc/private/toolchain:clang-cl (and similar), which:

1. Exposes private implementation details
2. Behaves inconsistently between Bazel 7 and 8 with bzlmod
3. Is not documented as the canonical location

Solution

Users can now use the public API:

platform(
    name = "windows_clang_cl",
    constraint_values = [
        "@platforms//os:windows",
        "@rules_cc//cc/compiler:clang-cl_constraint",
    ],
)

Test plan

• bazel build //cc/compiler:all //cc/private/toolchain:all succeeds
• Backward compatibility maintained via aliases

Fixes #330

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[fmeum]

I know that the Windows toolchain has been using this pattern for a while, but I'm not sure whether platform constraints are the best way to choose compilers vs. a Starlark flag. Have you considered that approach?

[srikantharun]

Thanks for raising this - it's a good architectural question.

I considered Starlark flags, but platform constraints seem more appropriate here for a few reasons:

1. Toolchain resolution - Platform constraints integrate directly with Bazel's toolchain resolution mechanism (toolchain() rule's target_compatible_with). Starlark flags would require a separate selection layer on top.
2. Consistency with existing patterns - As you noted, Windows toolchain already uses this pattern. The unix toolchain in rules_cc also uses @rules_cc//cc/private/toolchain:clang constraints. This PR just exposes what's already there publicly.
3. Platform semantics - Compiler choice is often a property of the target platform (e.g., "this embedded platform requires arm-none-eabi-gcc"), not just a user preference. Constraints model this well.

That said, Starlark flags could work for use cases like "I want to switch compilers on the same platform" (e.g., clang vs gcc on Linux). Would a hybrid approach make sense - constraints for toolchain resolution, with an optional flag to override?

Happy to discuss further or adjust the approach if there's consensus on a different direction.

[fmeum]

The situation is unfortunately more complex than that, partially for historical reasons:

1. Toolchain resolution does take Starlark flags into account via the required_settings attribute of toolchains.

2./3. The Windows toolchain has used constraints on the exec platform. You are suggesting that it's commonly a constraint on the target platform. I would argue it's neither since whether you can use a given compiler often depends more on how you write your code than on where it is supposed to run. Runtime libraries such as the choice of libc would clearly map to target platform constraints, but for compilers, this seems less clear.

We probably need to collect more concrete use cases and examples of build configuration to distill put the right abstractions. There is a lot of value in that if we get it right.

[srikantharun]

Good points - I appreciate the nuanced breakdown.

You're right that I conflated exec/target platform constraints, and that required_settings does support Starlark flags for toolchain resolution.

I'd be happy to help collect use cases. From my experience, the common scenarios are:

1. Cross-compilation - targeting embedded ARM with arm-none-eabi-gcc (target platform constraint?)
2. Hermetic builds - enforcing clang version across team (exec platform or flag?)
3. Code compatibility - codebase requires MSVC for Windows-specific APIs (flag seems right here)
4. CI matrix - testing same code with gcc/clang/msvc (definitely a flag use case)

Should I hold this PR while we work through the design? Is there an existing issue or design doc tracking this, or should we create one?

[fmeum]

I think that the complexity of this topic deserves a prior discussion, which could be a short design doc or a GitHub discussion.

Another important aspect is the distinction between hermetic toolchains and non-hermetic toolchains, where the latter may only be available on certain exec platforms (think RBE runners with a commercial compiler that has to be preinstalled).

[srikantharun]

Created a design discussion to explore this properly: #564

Marking this PR as draft until we have consensus on the approach.