ResolveReadyToRunCompilers: map non-portable rids when targetOS is determined. #28380
Conversation
…tches the host rid.
| new[] { "linux", "linux-musl", "osx", "win" }, | ||
| out _); | ||
|
|
||
| // For source-build, allow the bootstrap SDK rid to be unknown to the runtime repo graph. |
There was a problem hiding this comment.
After the initial bootstrap using Microsoft's SDK (e.g. linux-x64) further builds of source-build can use a non-portable SDK that was previously built (e.g. fedora.36-x64).
The runtime repo overwrites the BundledRuntimeIdentifierGraphFile to either the one it includes in its sources, or the one that it generates.
These graph files may not know the rid from the bootstrap SDK (e.g. fedora.36-x64).
(It will be known to the graph that is in the SDK.)
Rather than make the BundledRuntimeIdentifierGraphFile also use the SDK graph in some cases, I've opted to special case it here under _targetRuntimeIdentifier == _hostRuntimeIdentifier.
|
The CI failure on Windows doesn't look related to this change. |
|
All CI jobs must be green to merge a PR. I have restarted the failed leg. |
|
CI is all green now. |
|
Thanks a lot @tmds |
…termined (backport dotnet#28380)
|
@AntonLapounov @ViktorHofer can you initiate a backport of this PR to 7.0? |
|
@AntonLapounov can you do so please and fill out the servicing template? |
|
Do we use a /backport command or do it manually in SDK? I guess we could use the template from #28380. I know only that this is needed for source-build. |
|
There is no backport command here, you would need to do it manually. Usually in the SDK, changes are applied to the lowest applicable branch and then bots will auto-flow them into the newer branches. |
…termined. (dotnet#28380) * ResolveReadyToRunCompilers: map non-portable rids when targetOS is determined. * For source-build, allow using a rid that is not in the graph if it matches the host rid.
Fixes #28312.
cc @AntonLapounov @ViktorHofer ptal.