tree 32e98fad34fee8ef7995b362557a02a617eb332e
parent 120309defcf80fd65f5ecd46e124c95658bc8d84
author Marcel Hlopko <hlopko@google.com> 1558954446 -0700
committer Copybara-Service <copybara-worker@google.com> 1558954511 -0700

Split toolchains from cc_toolchains in cc_configure

This change modifies which part of cc_configure is executed unconditionally and which only on demand.

The root of the problem was the call `register_toolchains(@local_config_cc//:all)`. Because this was appended to the WORKSPACE file, each Bazel project executed the repository (and therefore tried to detect C++ toolchain and its capabilities) even when the C++ toolchain was not needed for the build.

This change split `@local_config_cc` into 2 repositories:

1. `@local_config_cc_toolchains` which contains only `toolchain` targets, and doesn't require C++ toolchain to be detected.
2. `@local_config_cc` which contains `cc_toolchain` targets, which do require C++ toolchain to be detected.

The point is that toolchain resolution has all the information needed to select the appropriate toolchain without autoconfiguration, therefore C++ toolchain will only be autoconfigured only after we already know it will be selected.

This cl is backwards incompatible for projects that relied on `@local_config_cc` containing `toolchain` targets. But because https://github.com/bazelbuild/bazel/issues/7260 is not yet flipped, there are not that many users of toolchains with C++ who manually instantiate `cc_autoconf` rule.

Fixes https://github.com/bazelbuild/bazel/issues/7751.
Progress towards https://github.com/bazelbuild/bazel/issues/7260.

RELNOTES: Repository containing autoconfigured C++ toolchain `@local_config_cc` has been split in 2 - see `local_config_cc_toolchains`.

Closes #8459.

PiperOrigin-RevId: 250131245