Add --host_macos_cpus flag
#13461
Add --host_macos_cpus flag
#13461
Conversation
When your macOS build has tools that build with the Apple rules, such as `macos_command_line_application`, you likely want to share caches between Apple Silicon and Intel machines. Today your tool would build for the host architecture (ideally, see bazelbuild#13440) which means the tools would differ between the different architectures, leading to split caches. This flag allows you to pass `--host_macos_cpus=arm64,x86_64` in order to produce a fat binary for host tools. This has the downside of increasing binary size for your tools, but likely that trade-offs is worth it for almost everyone versus having split caches.
|
Here's an example alternative for |
|
@dmaclach Any concerns here? |
|
I wanted to make sure my comment on the other PR was seen here as well: bazelbuild/rules_apple#1155 (comment) |
|
This is also very useful for remote execution, being able to have the host and remote executor be on differing architectures. |
|
Seems this is needed to get bazelbuild/rules_apple@73c041d to work for host tools. |
|
Can we please have this in? Although it's possible to do this with Starlark, it's a pain to update the rules everywhere; if we have this, it would be just a single flip. |
|
Last I checked it required more changes to work |
|
dropping this for now, not sure if we really need anymore or not, we can bring back up if needed |
When your macOS build has tools that build with the Apple rules, such as
macos_command_line_application, you likely want to share cachesbetween Apple Silicon and Intel machines. Today your tool would build
for the host architecture (ideally, see #13440)
which means the tools would differ between the different architectures,
leading to split caches. This flag allows you to pass
--host_macos_cpus=arm64,x86_64in order to produce a fat binary forhost tools. This has the downside of increasing binary size for your
tools, but likely that trade-off is worth it for almost everyone versus
having split caches.