rules_apple
rules_apple copied to clipboard
How to build for multiple architectures
When trying to build a FAT binary for a macos_dynamic_framework
using --macos_cpus=x86_64,arm64
I hit the following error:
Traceback (most recent call last):
File "/private/var/tmp/_bazel_lpadron/ad4b52c6b7f1c71771bd38a7ed554766/external/rules_apple~3.2.1/apple/internal/macos_rules.bzl", line 2946, column 13, in _macos_dynamic_framework_impl
fail(
Error in fail: error: Swift dynamic frameworks expect a single swift_library dependency.
This build works as-is when building for a single architecture. This is with Bazel 6.4.0
and rules_apple 3.2.1
I see the same with bazel build //test/starlark_tests/targets_under_test/ios:basic_framework --ios_multi_cpus=x86_64,arm64
in the tests here, is there a different way to generate universal frameworks?
Hrm did this ever work? Might be worth bisecting (or just testing the first sha that had this rule)
A potential fix is to fetch deps from ctx.split_attr.deps
instead, but I also wonder if we're misremembering how it should work
This doesn't seem to have worked as far back as 1.0.0 using Bazel 5
My use case right now is we want to release a macOS application and just noticed it was running under Rosetta because it was building using x86_64 github runners. apple_univaral_binary
seems to have the same error
Maybe this generally never worked and then it became virtually obsolete because xcframeworks solve multi-archs (even for macOS although it feels unnecessary since there aren't platform arch conflicts)
What rule is the application target? With a macOS application rule it should work. And if it fails because a macos_dynamic_framework is in the dependency tree you should replace that with a macos_framework. Theoretically the former should only be used for distribution
Ah that was it, makes sense. Thanks!
So in summary for folks:
- If distributing
macos_*_framework
which requires multiple arch support usexcframework
rules instead. - If depending on a
macos_*_framework
rule usemacos_framework
instead within other targets.
I guess we cant use .xcframework
on macOS until #1475
yea, I guess that was less of a priority since you can still use a fat framework there, but then i guess you hit this even on macOS?
probably worth a split_deps fix