search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.29k stars 4.74k forks source link

macOS-architecture RIDs #44931

Open TheFanatr opened 3 years ago

TheFanatr commented 3 years ago

By the time .NET 6 is released, it will have been more than five years since Apple renamed this operating system to "macOS". It's not called "OS X" any more. If it can be done correctly in TFMs, it can be done correctly in RIDs.

Originally posted by @warrenrumak in https://github.com/dotnet/runtime/issues/43313#issuecomment-707261960

This is in reference to the fact that RIDs for macOS are still osx-architecture (and seems like it will be osx-arm64 for Apple Silicon Macs); this should be fixed at this point before it becomes more set in stone.

@richlander replied to the above quoted comment, for the OP to file an issue, but they haven't and it's been a month, so here is mine.

Hope this gets done; if there's already an issue for this or it was already done, I didn't find it or notice, and someone can close.

Dotnet-GitSync-Bot commented 3 years ago

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.

danmoseley commented 3 years ago

@terrajobst ?

am11 commented 3 years ago

* NO MERGE * but this is not a PR. 🙂

aaronfranke commented 3 years ago

@danmosemsft This issue is labeled * NO MERGE * but in #43313 it says "Support compilation targeting osx-arm64" and the box is checked. So this has already been merged, and should be fixed soon before it's too late.

danmoseley commented 3 years ago

Thanks for pointing that out. As much as it's not ideal as is, I expect doing this would require cutting work in other places including NuGet. Could you say a little more about what you believe the relative priority of this should be and why?

Cc @terrajobst @richlander @wfurt @sdmaclea

aaronfranke commented 3 years ago

@danmosemsft The issue is that the longer we wait the bigger the potential breakage is. Since .NET 6 introduces new names (the mentioned inaccurate osx-arm64), the optimal strategy is to use the correct names from the start, and then the only breakages that have to be worried about are with the existing code. So I think this should be solved before .NET 6 is in preview; if .NET 6 follows a similar schedule to .NET 5, this means that this issue should be solved within the next few months.

EDIT: I suggest throwing this issue and #44120 on a milestone of some sort so it's not forgotten. I see that there is a "6.0.0" milestone, but maybe it should also go on some other milestone or tracker so it gets done within the next few months.

danmoseley commented 3 years ago

Cc @ericstj @marek-safar

sdmaclea commented 3 years ago

We will probably need to create macos & macos-* as an alias for osx & osx-*. I am not sure osx-arm64 makes the situation any worse as we would probably want to keep things symmetrical.

TheFanatr commented 3 years ago

I think it's also somewhat useful to point out that not only is the operating system no longer called Mac OS X, macOS Big Sur is actually version 11 of the software, as opposed to 10.X for the multiple previous macOS releases, so it's incorrect on multiple levels due to "OS X" being version 10 by definition.

marek-safar commented 3 years ago

like it will be osx-arm64 for Apple Silicon Macs

yep, that's correct, and current setup

I agree there should be a way to alias OSX to macOS and vice-versa so developers can use both names on CLI and in their projects/NuGets. I don't think we should be pedantic and block osx-arm64 though.

ericstj commented 3 years ago

Looks like this issue might be tracking the same thing as https://github.com/dotnet/runtime/issues/44120

krwq commented 3 years ago

I assume this is now out of scope for 6.0?

krwq commented 3 years ago

Changed to future since the other issue is marked as Future