Use the live crossgen2 corresponding to the runtime we're building against #59551
Conversation
…2 lookup (when they should only influence old crossgen lookup)
…jects (where we use R2R)
dotnet-issue-labeler
bot
added
the
area-infrastructure
|
Hey @dotnet/aspnet-build, looks like this PR is something you want to take a look at. |
| @@ -108,7 +109,7 @@ | |||
| <KnownCrossgen2Pack Update="Microsoft.NETCore.App.Crossgen2"> | |||
| <Crossgen2PackVersion | |||
| Condition=" '%(TargetFramework)' == '${DefaultNetCoreTargetFramework}' ">${MicrosoftNETCoreAppRuntimeVersion}</Crossgen2PackVersion> | |||
| <Crossgen2RuntimeIdentifiers Condition=" '$(DotNetBuildSourceOnly)' == 'true' ">$(TargetRuntimeIdentifier)</Crossgen2RuntimeIdentifiers> | |||
| <Crossgen2RuntimeIdentifiers Condition="'$(DotNetBuildOrchestrator)' == 'true'">$(NETCoreSdkRuntimeIdentifier);$(TargetRuntimeIdentifier)</Crossgen2RuntimeIdentifiers> | |||
There was a problem hiding this comment.
OK this is a bit problematic. I was going to override the NETCoreSdkRuntimeIdentifier as it controls what the SDK is bringing in: dotnet/sdk#45362
But if I now override that property then we don't restore the host crossgen2 pack anymore. Maybe we need an SDK change to allow a more fine-grained control over the pack RIDs that are being restored? I.e. there's already a property that controls the apphost pack's RID but there isn't one for the other packs: https://github.com/dotnet/sdk/blob/4a7aa40342ebf9095014de685fcb399c3e497db7/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets#L157
There was a problem hiding this comment.
I noticed that you are adding the host rid in https://github.com/dotnet/windowsdesktop/pull/4815/files. Why is that?
There was a problem hiding this comment.
OK this is a bit problematic. I was going to override the
NETCoreSdkRuntimeIdentifieras it controls what the SDK is bringing in: dotnet/sdk#45362But if I now override that property then we don't restore the host crossgen2 pack anymore. Maybe we need an SDK change to allow a more fine-grained control over the pack RIDs that are being restored? I.e. there's already a property that controls the apphost pack's RID but there isn't one for the other packs: dotnet/sdk@
4a7aa40/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets#L157
Yeah, we can't just override NETCoreSdkRuntimeIdentifier in dotnet/sdk#45362 as it controls how the SDK selects tools that it knows can run on the host machine. It works fine for Win-x86 because we can run Win-x86 tools on a Win-x64 build machine, but if we tried to do that for linux-arm64 for example, things would break pretty badly (crossgen would just completely fail to execute).
I think we need different/additional controls within the SDK to control which pack RIDs are restored instead of changing the SDK's understanding of its current RID.
I noticed that you are adding the host rid in https://github.com/dotnet/windowsdesktop/pull/4815/files. Why is that?
In dotnet/windowsdesktop#4815 I don't need to add the host RID as we aren't changing the RID list there. We aren't changing the RID list as we never need to add the "target RID" to the list because we're never building windowsdesktop with a nonportable RID.
| </ItemGroup> | ||
|
|
||
| <PropertyGroup Condition="Exists('$(NuGetPackageRoot)microsoft.netcore.platforms/$(MicrosoftNETCorePlatformsVersion)')"> | ||
| <RuntimeIdentifierGraphPath>$(NuGetPackageRoot)microsoft.netcore.platforms/$(MicrosoftNETCorePlatformsVersion)/PortableRuntimeIdentifierGraph.json</RuntimeIdentifierGraphPath> |
There was a problem hiding this comment.
Yes, this is a property defined by the SDK that (by default) points to the portable RID graph that the SDK shipped with.
| @@ -15,8 +15,6 @@ | |||
| <RollForward>LatestPatch</RollForward> | |||
| <!-- Precompile the shared framework with ReadyToRun. ReadyToRun is not currently supported on s390x or ppc64le or armv6 or loongarch64. --> | |||
| <PublishReadyToRun Condition=" '$(TargetArchitecture)' == 's390x' OR '$(TargetArchitecture)' == 'armv6' OR '$(TargetArchitecture)' == 'ppc64le' OR '$(TargetArchitecture)' == 'loongarch64' ">false</PublishReadyToRun> | |||
| <!-- VMR doesn't produce valid crossgen for the host/build machine https://github.com/dotnet/source-build/issues/3793 --> | |||
| <PublishReadyToRun Condition=" '$(DotNetBuild)' == 'true' AND '$(Crossbuild)' == 'true' ">false</PublishReadyToRun> | |||
To build our shared frameworks in the VMR like how we build them in the Microsoft build, we need to run crossgen2 on them to pre-JIT code. However, in the VMR we currently don't have a crossgen2 that runs on the host.
dotnet/runtime#110676 has the runtime changes to provide such a crossgen2 in the VMR environment.
This PR makes the required changes to use this crossgen2 in the aspnetcore build in the VMR (as well as work around some SDK issues along the way).