incompatible_enable_cc_toolchain_resolution: Turn on toolchain resolution for cc rules

[katre]

Flag: --incompatible_enable_cc_toolchain_resolution
Available since: 0.23
Will be flipped in: 7.0.0

Description

C++ toolchain resolution is an improved mechanism that selects a proper C++ toolchain (compiler) based on a pair of target and execution platforms (think cross compilation from linux to mac). It’s an improvement over the old mechanism that sets the --crosstool_top flag. More information about platforms and toolchain resolution on https://bazel.build/reference/be/platforms-and-toolchains

Current status

• C++ toolchain resolution has been in use at large repository at Google for a year without significant problems.
• rules_apple and rules_swift lack toolchainization, however they work using platform_mapping
• Bazel's C++ toolchain autoconfiguration already supports toolchain resolution.

Migration

If you're not using C++, or custom --crosstool_top, --cpu, or --compiler,
you don't use select on these options, you can stop reading now, there is
nothing to migrate for you.

Migration before the flag is flipped (only in case you're building for custom platforms, using custom C++ toolchains or using custom rules invoking cc_common.compile and cc_common.link):

1. Add C++ platform definitions, register C++ toolchains
2. Add missing C++ toolchain requirements to rules (Already added to OSS rules)
3. Update blazerc configuration to use custom platforms
4. Update Starlark configuration transitions to use platforms (ones affecting --cpu and --crostool_top, in cases platform_mappings isn’t used)
5. Update or fix configurations (bazelrc) to use --platforms (where --cpu or --crosstool_top is used)

Migration after the flag is flipped:

1. Replace cpu and os based selects with platform based selects (for example selects cc_target_os, target_cpu and other)
2. Remove --crosstool_top, --cpu flags from bazelrcs and from Starlark configuration transitions
3. Remove part of platform_mappings configuration needed for C++
4. Remove _cc_toolchain implicit dependency

Additional details

1. Add C++ platform definitions, register C++ toolchains

Please use constraint_settings and constraint_values from
the canonical Bazel Platforms
Repository (don't hesitate to propose
missing targets!). If there is a need for C++ specific constraints, feel free to
upload a PR to the rules_cc
repository. It is extremely important that the whole ecosystem uses the same
constraints, we can only reuse libraries and toolchains when we speak the same
language.

2. Add missing C++ toolchain requirements to rules

For Starlark rules owners who depend on C++ toolchain it will be necessary to
declare dependency on C++ toolchain type.

Before:

foo = rule(
    implementation = _foo_impl,
    attrs = {
        "_cc_toolchain": attr.label(default = Label("@bazel_tools//tools/cpp:current_cc_toolchain")),
    },
)

After:

foo = rule(
    implementation = _foo_impl,
    attrs = {
        "_cc_toolchain": attr.label(default = Label("@bazel_tools//tools/cpp:current_cc_toolchain")),
    },
    toolchains = use_cpp_toolchain(),
  )

See the docs and use @rules_cc//cc:find_cc_toolchain.bzl
(if using Bazel >= 0.27) or @bazel_tools//tools/cpp:toolchain_utils.bzl to locate current C++ toolchain (otherwise). Also see examples for general usage.

[katre]

Note that this flag will supercede and replace the previous --enabled_toolchain_types flag, which was introduced before the incompatible change policy was formulated, and which was only ever used for the cc rules, anyway.

[katre]

People who are interested: @hlopko, @lberki, @nlopezgi.

[gregestren]

Will native transitions like

bazel/src/main/java/com/google/devtools/build/lib/rules/android/AndroidRuleClasses.java

Line 252 in 4b00ab1

splitOptions.get(BuildConfiguration.Options.class).cpu = androidOptions.cpu;

also need attention?

[katre]

Yes, @aragos and I have been discussing a plan. We will probably not be able to flip this flag until we have a solution, so I am removing the "Will be flipped in" tag.

[dslomov]

Please do not assign issues to more than one team

[keertk]

Hi all, confirming if we still plan to flip this flag in 7.0?

[meteorcloudy]

Should this issue be closed since the flag is now flipped?

[comius]

Should this issue be closed since the flag is now flipped?

Closing the issue when the flag is removed. Or perhaps leaving it open, so that users can more easily find migration instructions?