bazel: Using `--cpu=darwin_x86_64` in `platform_mappings` triggers unnecessary toolchain evaluation
Description of the bug:
This is a follow-up to #12897. The fix (#14096) doesn’t address the original problem when platform_mappings
is in use. When not using platform_mappings
, there is no problem.
What’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
The objective is to prevent bazel from analysing objc_library
targets on Linux.
Create this BUILD file:
objc_library(
name = "objc",
target_compatible_with = [
"@platforms//os:macos",
],
)
platform(
name = "macos",
constraint_values = [
"@platforms//os:macos",
],
)
The target is appropriately skipped on a Linux machine:
$ bazel build //:all
INFO: Analyzed target //:objc (0 packages loaded, 117 targets configured).
INFO: Found 1 target...
Target //:objc was skipped
INFO: Elapsed time: 0.481s, Critical Path: 0.04s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
Now add a platform_mappings
file:
platforms:
//:macos
--cpu=darwin_x86_64
flags:
--cpu=darwin_x86_64
//:macos
and you see the same error originally reported in #12897:
$ bazel build --platform_mappings=platform_mappings //:all
ERROR: /bazel-cache/phil/bazel/_bazel_phil/8299a41ccdd1478ccc4dfad80faab3e8/external/local_config_cc/BUILD:47:19: in cc_toolchain_suite rule @local_config_cc//:toolchain: cc_toolchain_suite '@local_config_cc//:toolchain' does not contain a toolchain for cpu 'darwin_x86_64'
ERROR: /bazel-cache/phil/bazel/_bazel_phil/8299a41ccdd1478ccc4dfad80faab3e8/external/local_config_cc/BUILD:47:19: Analysis of target '@local_config_cc//:toolchain' failed
ERROR: Analysis of target '//:objc' failed; build aborted:
INFO: Elapsed time: 0.232s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 258 targets configured)
It’s worth noting that this only happens with --cpu=darwin_x86_64
. If I instead add a --cpu=k8
platform mapping, then the error goes away again.
Which operating system are you running Bazel on?
x86_64 Debian 11
What is the output of bazel info release
?
development version
If bazel info release
returns development version
or (@non-git)
, tell us how you built Bazel.
$ git log --oneline -1
61c433e896 (HEAD, upstream/master) Content clarifications and markdown fixes for consistency with other tutorials.
$ git status
HEAD detached at upstream/master
nothing to commit, working tree clean
$ bazel build -c opt //src:bazel-bin
What’s the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD
?
$ git remote get-url upstream
https://github.com/bazelbuild/bazel
$ git rev-parse HEAD
61c433e8968549781664194b9c046335f125c07a
Have you found anything relevant by searching the web?
N/A
Any other information, logs, or outputs that you want to share?
I will investigate possible solutions to this.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 19 (16 by maintainers)
Perhaps a related question is: What’s the motivation behind
objc_library
performing this transition? Seems like it’s making a decision that users should be making. I.e. I would imagine, all use cases ofobjc_library
can still be satisfied without this self-transition.Yes, that makes sense @pcjanzen (and I hope that addresses your confusion @philsc about why
objc_library
targets a different platform than you intended - it’s set in a transition).I understand your use case. Thanks for detailing it out. The challenge with this bug is that all pieces of functionality are working as intended. It’s not a bug, per se. But you’re showing how that can still produce a bad user experience.
Core configurability devs will review this this week as part of routine bug triage. Let’s get another update from that review.