-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Add arm64-ios & arm64-tvos runtime packs for simulator and produce new runtime packs #48216
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
To confirm my understanding of the issue:
Should we also rename ios-x64 to unify with whatever ios-arm64-simulator ends up looking like? I know there's not a huge likelihood of ios-x64-device being a thing that exists |
Your understanding is my understanding. I think having ios-arch-simulator packs makes a lot of sense. So, yes, I would support an x64 rename. |
I agree we should not suffix with -device and that it should be the shorter rid. I'm thinking about
This also means we need to change existing RIDs |
Looking at it, the precedent we have for sub-variants is Alpine Linux, i.e. |
If I understand the RID structure correctly, I think that shouldn't hurt us either way. |
Does this discussion also apply to tvOS? |
Yes |
Related: dotnet/llvm-project#99 |
One more question: am I eliminating RIDs which we won't produce any more from the graph, like ios-x64? Or should it still exist as a RID, merely no longer a thing we build?
…Sent from my iPhone
On Mar 4, 2021, at 12:02 PM, Marek Safar ***@***.***> wrote:
Does this discussion also apply to tvOS?
Yes
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Considering we didn't ship anything for these rid I'd be fine with that but please make this separate PR and we can double-check during the review. |
This change consolidates on the new iOS/tvOS RIDs, as per dotnet/runtime#49305 and dotnet/runtime#48216
Previously, we have had four iOS RIDs: iOS-arm iOS-arm64 iOS-x86 iOS-x64 Apple has never shipped an iOS device with an x86 or x64 processor. Instead, the x86/x64 RIDs have meant "iOS simulator with these arches" as opposed to "iOS with these arches". Amongst other things, that means building against a DIFFERENT SDK, iPhoneSimulator.platform vs iPhoneOS.platform In the Apple Silicon future, the iOS simulator is now an ARM64 binary - so we need: iOS-arm iOS-arm64 iOS-arm64, but built against the simulator SDK not the device SDK iOS-x86 iOS-x64 Clearly, there's a problem. The solution is to move the simulators to a different RID, to avoid the overloading issue: iOS-arm iOS-arm64 iOSSimulator-arm64 iOSSimulator-x86 iOSSimulator-x64 This PR introduces the new entries in the RID graph, moves our existing iOS-x{86,64} to iOS-sim-x{86,64}, adds a new iOS-arm64. The above also applies for tvOS, with a smaller set of OSes: tvOS-arm64 tvOSSimulator-arm64 tvOSSimulator-x64 Ref: #48216
We need a different build for ios simulator running on M1 machines. It has the same arch as 64 bits iOS bit the native assets cannot be shared. This is something that Apple might change in the future though.
I'd suggest deriving it from the existing ios-arm64 RID.
/cc @rolfbjarne
The text was updated successfully, but these errors were encountered: