Add basic RIDs for ios and tvos #31953
Conversation
|
cc: @bartonjs |
|
Does it make sense to use ios/tvos with .NET Core without some other layers being involved? The question is really "is there a sub-platform package where the RID-graph extensions can be registered, instead of the root set?". The answer might be no; but I feel like I have to ask 😄. |
|
@bartonjs I am not sure I follow your question. I follow documented naming convention and I also expect dotnet/runtime to build a specific version instead of root ID as the implementation has minimal version requirements. |
| "any", | ||
| "base" | ||
| ], | ||
| "ios-arm64": [ |
There was a problem hiding this comment.
I think we should add iOS Simulator and Device as separate RIDs extending from the generic iOS RID.
There was a problem hiding this comment.
that would mean the rid would need to be called something like iosdevice-arm64 and I don't think that's a good idea.
There was a problem hiding this comment.
Apple decided to split them up into two separate SDKs/targets so I don't think we have a choice.
There was a problem hiding this comment.
ios-arm64 - device RID
ios-x64 - simulator RID
Both have parent RID ios. As I wrote above explicitly stating device in the RID is something I think we should try to avoid
There was a problem hiding this comment.
That will break down as soon as Apple introduces the rumored ARM MacBook. I really don't think we should bake in the assumption about which architectures are a device runtime vs. simulator runtime.
There was a problem hiding this comment.
why? such device would use different RID called osx-arm64
There was a problem hiding this comment.
I'm talking about the iOS Simulator running on an ARM MacBook. We'd need to use a simulator build of the runtime there, not a device one.
There was a problem hiding this comment.
Well, we don't know if simulator would be needed or not but even in that case the existing naming convention covers that with ios-arm64-jit like format.
There was a problem hiding this comment.
We discussed offline and I wasn't aware of the "additional qualifiers" specified in https://github.com/dotnet/runtime/blob/acdb8696b02f18f2dc34286fb4ba3bd26ad14db4/src/libraries/Microsoft.NETCore.Platforms/readme.md#naming-convention
[additional qualifiers] can be things like aot. Used to further differentiate different platforms.
This settles my concern.
src/libraries/pkg/Microsoft.NETCore.Platforms/runtime.compatibility.json
Show resolved
Hide resolved
|
My question is really "Is Microsoft.NETCore.Platforms the right place to define these RIDs?". For example, if running .NET on iOS or tvOS always requires some package like Xamarin.PlatformHost, then maybe these RID extensions belong in that layer. If there's an effort to get "vanilla" .NET Core running on iOS, or there's no appropriate funnel out a layer, then here's fine. |
There is effort for .NET 5 to build ios version of all dotnet/runtime |
|
/azp run runtime |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-live |
|
No pipelines are associated with this pull request. |
|
Failures are unrelated #18090 |
ghost
locked as resolved and limited conversation to collaborators
No description provided.