-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"experimental_platform_in_output_dir" caused action conflict on M1 #21255
Comments
One workaround, if you want to keep I'm not sure if there's a good way to detect this during the action conflict check and suggest it, but it would be nice if we could. |
I think I see the problem. As bazel-contrib/rules_go#3851 (comment) mentions, But if you set I think we should default I have to admit the resulting paths are much cleaner when you can set --experimental_override_name_platform_in_output_dir mappings (see bazel-contrib/rules_go#3851 (comment)). We don't yet have better logic that allows setting this from distributed sources. |
I wrote a doc a while ago explaining the interplay between all these flags and how they affect what output paths look like. Happy to share if anyone wants a summarized reference. @katre , @aranguyen and I are also trying to clean up and remove these flags as much as we can. Some of them are pure legacy logic that AFAIU is no longer relevant. |
cc: @fmeum I think turning off If that's the case, I would prefer if this is an opt-in flag as the current approach is still much friendlier to end-users.
|
See Platforms in output paths review - an attempt to cleanly explain what all the flags do and their history.
Exactly. As mentioned in the doc I'd love to be able to globally default One option is use platform base names and have Bazel actively check for clashes and cleanly error builds that mix platforms in unsafe ways. Then it's up to users to organize to avoid that. |
Description of the bug:
A detailed description could be found here bazel-contrib/rules_go#3851
Which category does this issue belong to?
Configurability
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Make sure to use an ARM64 MacOS machine to reproduce this.
Which operating system are you running Bazel on?
MacOS
What is the output of
bazel info release
?release 7.0.2
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
No
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
See the discussion in bazel-contrib/rules_go#3851
The text was updated successfully, but these errors were encountered: