Conversation
|
so there's still weird behavior here, and we need this alongside bazelbuild/bazel#13440 With just this change, the path to the output has the right arch in it, but the binary has the wrong arch: and without this change, but with that bazel default change you get the right arch but the wrong path: |
d35cf2f to
ba33d70
Compare
When building on an Apple Silicon machine, this CPU would still have been for x86_64, when you are building a macOS target explicitly, you can pass `--macos_cpus` (although that can also be inconvenient), but when the binary is a host binary there wasn't a way to override that.
ba33d70 to
5d48ea3
Compare
|
I no longer see the issue mentioned above with 5.0.0rc2 |
|
Lyft integration job started: https://buildkite.com/lyft/rules-apple/builds/152 (must be Lyft employee to view) |
| if macos_cpus: | ||
| return "darwin_{}".format(macos_cpus[0]) | ||
| cpu_value = settings["//command_line_option:cpu"] | ||
| if cpu_value.startswith("darwin_"): |
There was a problem hiding this comment.
On Intel Macs, unless --cpu=darwin_x86_64 is passed, this defaults to darwin.
| if cpu_value.startswith("darwin_"): | |
| if cpu_value.startswith("darwin"): |
There was a problem hiding this comment.
But would we want to return darwin, or fall through to the darwin_x86_64 case? I think we want to preserve old behavior for Intel.
There was a problem hiding this comment.
hrm yea that's kinda weird either way. I guess in that case we can continue letting it fallthrough as it was before, but we should try to eliminate that ambiguous arch identifier anyways
|
I tested this and it works. I think we should merge it in order to fix bazelbuild/bazel#14284. |
When building on an Apple Silicon machine, these CPUs would still have
been for x86_64. This flips the default to match the host machine instead.
Users can still pass the platform specific cpu flags to override them.
Closes bazelbuild/bazel#14284.