Bazel: incompatible_use_cc_configure_from_rules_cc: Use cc_configure from @rules_cc

[hlopko]

Flag: --incompatible_use_cc_configure_from_rules_cc
Introduced in: 1.2
Will be flipped: not anytime soon AFAIK

Description

We are moving cc_configure, the logic that automatically configures C++ toolchain for the host machine, to @rules_cc.

Migration

TODO

[smukherj1]

Bazel docs here points to this issue for migration instructions but I don't see any migration instructions here. Any idea when those will be posted?

I encountered this issue in https://github.com/bazelbuild/rules_docker/issues/1354 when attempting to cross compile a Go binary with CGO using rules_go on Linux for Mac.

FYI @jayconrod

[meisterT]

cc @oquenchil

[pcj]

@hlopko Note the bazel source code refers users to this issue for migration instructions, and as @smukherj1 has pointed out, the migration instructions are still a TODO despite the flag being flipped in 3.0.0.

[oquenchil]

Hi, I'm looking at the code and it seems this wasn't flipped in 3.0.0. The top comment here does say that it will be flipped in 3.0.0 but that did not happen as far as I can tell. Before I update the comment, please let me know if this was really flipped and I'm just not seeing it.

[systemlogic]

Any fix for Mac? On Rhel it works.

Build label: 3.0.0
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Apr 6 12:55:48 2020 (1586177748)
Build timestamp: 1586177748
Build timestamp as int: 1586177748
harora37@Harishs-MacBook-Air learn-bazel %      bazel build thirdparty/...
DEBUG: Rule 'com_github_grpc_grpc' indicated that a canonical reproducible form can be obtained by modifying arguments commit = "414bb8322de2411eee1f4e841ff29d887bec7884", shallow_since = "1599598806 -0700" and dropping ["tag"]
DEBUG: Call stack for the definition of repository 'com_github_grpc_grpc' which is a git_repository (rule definition at /private/var/tmp/_bazel_harora37/2a6ebc57f664787b8508faa4e6c82156/external/bazel_tools/tools/build_defs/repo/git.bzl:195:18):
 - <builtin>
 - /Users/harora37/learn-bazel/WORKSPACE:178:1
ERROR: While resolving toolchains for target //thirdparty/bzl/examples/aspect:app: No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.
ERROR: Analysis of target '//thirdparty/bzl/examples/aspect:app' failed; build aborted: No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.
INFO: Elapsed time: 0.293s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

please help.
FYI @hlopko @pcj

[oquenchil]

The flag wasn't flipped as far as I can tell nor will it be flipped any time soon.

[systemlogic]

As I said earlier. Error is only coming in OSX not on linux(rhel/ubuntu). Behavior is not consistent in two platform.

[oquenchil]

Can you please point me to where this flag was flipped in native Bazel code? I can't find it, it might be that it's in your bazelrc.

[systemlogic]

@oquenchil my repository is https://github.com/systemlogic/learn-bazel. This repo works without any config on linux, but throw an error as stated above in the original message.

[systemlogic]

Please note I have installed xcode and cpp and cc are in path.

[limdor]

@hlopko could you update the part "Will be flipped:" to reflect the current plan? Looks like with not happen soon right?

[hlopko]

Hi all,

done.

@systemlogic the error message says "maybe" the flag was flipped :) This flag is not flipped by Bazel, so it's either flipped by your workspace, or it's not flipped and the culprit is elsewhere.

In general, the presence of the flag in the Bazel binary doesn't mean anything, the backwards compatibility process allows us to create flags and then abandon them (when e.g. we discovered unexpected problems). The source of truth are Github issues and their labels (https://docs.bazel.build/versions/3.5.1/backward-compatibility.html#github-labels). This flag and this issue doesn't have the labels required, therefore it won't be flipped, and you can ignore it. I'd advice not to flip flags that don't have the right Github labels set, you'll only discover bugs and you'll be met with no support form owners.

[limdor]

@hlopko but then, shouldn't all_incompatible_changes be discouraged? From the docs looks like it is ok to use all_incompatible_changesbut from what I understand from you comment is that it is not a good idea to use incompatible_use_cc_configure_from_rules_ccor am I missing something?
Or wouldn't make sense to have two all_incompatible_changes? One that has all of them and one that has the ones that have the github label or to be flipped in the next release.

Enables all options of the form --incompatible_*. Use this option to find places where your build may break in the future due to deprecations or other changes.

[hlopko]

@lberki can we remove --all_incompatible_changes flag? :)

Yup, I'd say don't use --all_incompatible_changes, it's an old flag that was used for Starlark evolution long before Bazel adopted a backwards compatibility story. Those 2 approaches are incompatible and --all_incompatible_changes is (supposed to be) discouraged. If you want to keep an eye on Bazel's incoming changes, I'd recommend using Bazelisk (https://github.com/bazelbuild/bazelisk#other-features). I'd recommend Bazelisk in any case though :)

[lberki]

Let's wait a bit with that; I'd like to remove it, but let's do that only when the LTS release model is active.