Removing the default macOS toolchain from rules_cc

[keith]

Overview

Currently for historical reasons there are 2 toolchains on the bazelbuild org that can target macOS. One in apple_support (that also supports iOS and other Apple platforms), and the one in rules_cc that is roughly shared with the default linux toolchain (roughly because many things differ between the 2 platforms).

Before this toolchain was moved out of the bazel repo and into rules_cc, it was not feasible to remove it. Now that both exist in separate repos, and both of these repos are depended on by bazel by default, we are planning to remove the duplicated rules_cc version of this toolchain, and require users to use the toolchain from apple_support moving forward.

Why

There are a few reasons for this:

• the toolchain in rules_cc isn't hermetic because of complexities with Apple's tools, this has been solved in apple_support, and to solve it here would just require duplicating the same implementation
• this reduces confusion from users because both toolchains are always registered, and always conflict, so which toolchain you actually get depends on the order of bazel_dep targets in your MODULE.bazel
• this reduces maintenance overhead for the maintainers
• Previously the apple_support toolchain did not support the Xcode Command Line Tools only (meaning it required a full Xcode install) but this is no longer the case

Plan

1. Merge an off by default environment variable to disable the rules_cc toolchain for early testing with --repo_env=BAZEL_USE_LEGACY_MACOS_TOOLCHAIN=0, release it ASAP (hopefully 0.2.20)
2. Flip the default, while still allowing users to bring the old toolchain back with --repo_env=BAZEL_USE_LEGACY_MACOS_TOOLCHAIN=1, release it 1 release later (hopefully 0.2.21)
3. Field issues that come up from subtleties for a few months
4. Fully delete the rules_cc toolchain, probably after bazel 10.x releases depending on the number of issues that come up

Known changes

• The apple_support toolchain has slightly different arguments / ordering of arguments than rules_cc that will not be aligned and likely won't cause issues but could, we'll have to field these case by case
• Projects can be calling configure_unix_toolchain manually with their own tools and expect the resulting toolchain to work with macOS. It's possible we could expand the apple_support toolchain to support similar behavior, but this will be considered case by case
• toolchains_llvm does the above, we will have to decide how to handle that repo
• apple_support only supports compilers shipped with Apple's tools, not the brew install of clang or gcc, support for this is possible some please comment if this is something that is desired (although possibly a better recommendation would be to move to one of the fully hermetic toolchains instead)

Other notes

• If you're using bazel 7.x or earlier, even if you update rules_cc this likely doesn't apply since this toolchain still lived in bazel at the time. This would apply to 8.x+
• apple_support doesn't support WORKSPACE anymore, but it could again if needed. The last version with workspace support was 1.24.5 which could likely also be used instead

Feedback

Please comment here, or file issues on apple_support with any issues you see with this plan, or incompatibilities you hit with this change.

If you would like to test this today you can add apple_support to your MODULE.bazel above rules_cc like:

bazel_dep(name = "apple_support", version = "2.6.1")
bazel_dep(name = "rules_cc", version = "0.2.19")

[keith]

Bazel 8.x actually has a nodeps dep on apple_support, so users have to manually add apple_support to their MODULE.bazel for that version.

[keith]

I updated #755 to only apply this change to 9.x+ so that folks don't have to worry about the nodeps issue with bazel 8.x and lower