-
Notifications
You must be signed in to change notification settings - Fork 135
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
Bug 1688178 - Big Sur/M1 updates: xcframeworks, using Xcode clang, lipo #1485
Conversation
9128e40
to
4ebbc1b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
havewebeenappledyet.com? LGTM!
282584c
to
1c4441b
Compare
1c4441b
to
ebd5e13
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still looks good to me!
Now that the 2 iOS tasks don't depend on each other we can run them in parallel! The summed up runtime will be the same, but the actual runtime should be shorter! |
2f208f4
to
7735132
Compare
This is my first try at building Glean iOS on a M1 (arm) machine.
It essentially requires us to use xcframeworks, because the Carthage workaround is not suitable on M1 machines (as we can't exclude the arm64 target, because that IS the host target).
I can build Glean iOS now on my M1.
I can't run the tests though, because Rust doesn't know the difference between the host system and the simulator.
It's also likely that our sample app won't work the same anymore, at least not if I also want to get that compilable and runnable on an M1. It will need to start using xcframeworks too.
Carthage currently cannot produce xcframework binary releases, so the sample will always need to compile Glean.
Consumers wouldn't be affected, as long as they don't require xcframeworks. It just means I can't build those projects.