A rule to update ARM dependencies to run on M1 arm64 sim#346
A rule to update ARM dependencies to run on M1 arm64 sim#346jerrymarino merged 12 commits intomasterfrom
Conversation
This PR is an RFC on an _additional_ rule to rules_ios that adds the ability to update the Mach-o header on imported libraries and frameworks to get arm64 binaires running on Apple silicon simulator. For the demo, it's added in `app.bzl` but will need a feature flag and more. Why bother doing this? Well some apps have many dependencies which could take along time on vendors or other parties to update. Because the M1 chip has the same ISA as ARM64, most binaries will run transparently. Most iOS developers code is high level enough and isn't specifc to a device or simulator. There are many caveats and eceptions but getting it running is better than nothing. ( e.g. `TARGET_OS_SIMULATOR` ) This solves the problem at the build system level with the power of bazel. The idea is pretty straight forward: 1. collect all imported paths 2. update the macho headers with Apples vtool and arm-to-sim 3. update the linker invocation to use the new libs Now it updates all of the inputs automatically - the action can be taught to do all of this conditionally if necessary. Additionally the apsect was generating the action but I moved it into the rule. Mainly because you can't make an executable input to an aspect to scheudle actions there. This has an interesting propery: you get a single path for framework lookups at linktim. Today with bazel and rules_ios ld has an O(MFrameworks*NFrameworkPaths) search requirmenet. This is an additional consequence and worth comparing link time impovements but is a future exercise. There are some minor followups, but seeing what people think about it
|
👍 Love the idea! Every time we bump one of the few holdout frameworks, it's an adventure full of unarchiving, transmogrifying, archiving, vtooling, codesigning, etc. This would make the whole process transparent. Plus, it will be even more important down the line, when these holdout frameworks become increasingly rare and obscure. One (likely completely out of scope) improvement here could be automating transmogrification of older |
|
@bogo first off, thanks for the excellent write-up on all of this! Second, thank you for publishing the source to handle the object file fix-up 🙏 Having this capability in the build system dramatically simplifies dealing with this and makes M1 a reality. There's a lot of iOS dependencies out there without an xcframework right now and a lot of people looking to get up and running on the M1 simulator. I suspect a decent amount of these dependencies could continue to have updates that don't have an xcframework slice, making updates an ongoing problem.
The current version of this code takes any |
- fix missing plists - add to tests
258a7b1 to
4dd1bb2
Compare
- Add missing framework files - Remove redundant dep search
|
Fixed many issues and cleaned this to remove RFC status. There's a couple planned TODOs which I'll fix tomorrow AM:
Additionally, as other PRs:
|
cf40ec2 to
3341948
Compare
3341948 to
f88b1aa
Compare
- remove syslibroot from libtool - cleanup aspect refactoring code
Moves it out of the main rule body and cleanups up dynamic framework calculation
Co-authored-by: Thiago Cruz <thiago.hmcruz@gmail.com>
bb049f6 to
813329a
Compare
This was a TODO but will require more effort because rules_swift isn't working here
Additionally namespace tmp dirs and run buildifier
This PR is an RFC on an additional rule to rules_ios that adds the ability to
update the Mach-o header on imported libraries and frameworks to get arm64
binaires running on Apple silicon simulator. For the demo, it's added in
app.bzlbut will need a feature flag and more.Why bother doing this? Well some apps have many dependencies which could take
along time on vendors or other parties to update. Because the M1 chip has the
same ISA as iOS ARM64, most binaries will run transparently. Much iOS developers
code is high level enough and isn't specifc to a device or simulator. There are
many caveats and exceptions but getting it running is better than nothing. ( e.g.
TARGET_OS_SIMULATOR)This solves the problem at the build system level with the power of bazel. The
idea is pretty straight forward:
Now it updates all of the inputs automatically - the action can be taught to do
all of this conditionally if necessary.
Additionally the apsect was generating the action but I moved it into the rule.
Mainly because you can't make an executable input to an aspect to scheudle
actions there. This has an interesting propery: you get a single path for
framework lookups at link time. Today with bazel and rules_ios ld has an
O(MFrameworks*NFrameworkPaths) search requirmenet. This is an additional
consequence and worth comparing link time impovements but is a future exercise.
There are some minor followups, but seeing what people think about it