bazelbuild/rules_apple

How to build for multiple architectures

luispadron opened this issue · 10 comments

luispadron commented

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

luispadron commented

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?

keith commented

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

luispadron commented

This doesn't seem to have worked as far back as 1.0.0 using Bazel 5

luispadron commented

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

keith commented

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)

keith commented

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

  • 👍1
luispadron commented

Ah that was it, makes sense. Thanks!

So in summary for folks:

  • If distributing macos_*_framework which requires multiple arch support use xcframework rules instead.
  • If depending on a macos_*_framework rule use macos_framework instead within other targets.
luispadron commented

I guess we cant use .xcframework on macOS until #1475

keith commented

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?

  • 👍1
keith commented

probably worth a split_deps fix