You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Microsoft.NETCore.App.Crossgen2.sfxproj in source-build #74721
For source-build this needs to use the runtime that got built from the runtime repo.
When we're source-building .NET, runtime gets built twice: once as runtime-portable, and then as (non-portable) runtime.
When the non-portable runtime build happens, it is using packages that got source-built by runtime-portable. So all output artifacts from runtime were built from source, and we meet the built-from-source requirement.
The runtime-portable is taking up a large chunk of the build time, and it would be a huge improvement if we can eliminate it.
To meet the built-from-source requirement, the Microsoft.NETCore.App.Crossgen2 package may only contain things that were built from source. We can't use a pre-built Microsoft.NETCore.App.Runtime.<rid> package and should change to use artifacts that are built as part of runtime.
Then runtime can produce built-from-source artifacts in a single pass.
We can then eliminate the runtime-portable build by making builds use the non-portable packages built by runtime (like #75597 and dotnet/aspnetcore#43937)
Is this needed for .NET 7? From what I see this depends on #69455 which is not merged. We are already past RC2 snap.
Once that's in, I wonder if we need a task to update KnownFrameworkReference et al to account for AdditionalRuntimeIdentifiers in RuntimePackRuntimeIdentifiers and have the runtime packs be produced in a place visible to it.
Is this needed for .NET 7? From what I see this depends on #69455 which is not merged. We are already past RC2 snap.
I think we should set our goal to .NET 7 if that is feasible for everyone involved.
source-build's timing doesn't make it feasible to change something before rc.
From what I see this depends on #69455 which is not merged.
In this case, the rid we're publishing would be an exact match with a known rid.
I don't know if it needs to be in the graph for this match to work ... may be.
Once that's in, I wonder if we need a task to update KnownFrameworkReference et al to account for AdditionalRuntimeIdentifiers in RuntimePackRuntimeIdentifiers and have the runtime packs be produced in a place visible to it.
I don't know about the Task. In #75597 I'm making some changes so source-build can pick up non-portable rids from a previous build.
It would be good if we could eliminate the known references to things we shouldn't be using when DotNetBuildFromSource == true. That would be a good guard for the built-from-source requirement.
Infrastructure changes are OK to go into 7.0 so long as they stay constrained to infrastructure and feed into the source-build requirements. We can take them to Tactics if we think there is some product risk - typically we don't and instead work to mitigate the risk through some PR validation (manual checks, test cases, etc). I closed out that PR since I'm not actively working on it and my time for making fixes (especially those that others are dependent on) is pretty small at the moment. I think it makes more sense for that to be driven by folks who need it and can test the end-to-end with the change.
@mangod9 I Cc'd @dotnet/crossgen-contrib but there's no volunteer, could you nominate one? I assume this is blocking source build in .NET 7, but I don't know anything about source build or "packs".
Are you seeing that failure in the ResolveRuntimePackAssets task when doing the following sequence of commands with the diff given above? I have no prior knowledge of that part of SDK; however, it should not be difficult to debug this.
I'll try to capture what happens when source-build runs this.
@ViktorHofer@AntonLapounov it doesn't look like the top-level verbosity ripples down to the MSBuild tasks. How can I get more verbose logging of what happens in these MSBuild tasks:
The Crossgen2 package should be built using Microsoft.NETCore.App.Runtime.banana.10-x64 package, instead of the pre-built Microsoft.NETCore.App.Runtime.linux-x64 package.
<NativeAotSupportedCondition="('$(TargetOS)' == 'windows' or '$(TargetOS)' == 'linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</NativeAotSupported>
maybe it's better to merge the condition in crossgen2 into the top-level Subsets.props to avoid any unexpected build state. It is basically controlling "after compiling crossgen2 assembly, whether to publish crossgen2 as nativeaot app (NativeAotSupported=true) or a singlefileapp (NativeAotSupported=false)".
Activity
jkotas commentedon Aug 28, 2022
It may be easiest to publish it as framework dependent app for source-build.
ViktorHofer commentedon Sep 13, 2022
@hoyosjs, @trylek, @jkoritzinsky (@agocke) just changed labels as this isn't related to the libraries infrastructure. Can you please take a look?
tmds commentedon Sep 14, 2022
When we're source-building .NET, runtime gets built twice: once as
runtime-portable, and then as (non-portable)runtime.When the non-portable
runtimebuild happens, it is using packages that got source-built byruntime-portable. So all output artifacts fromruntimewere built from source, and we meet the built-from-source requirement.The
runtime-portableis taking up a large chunk of the build time, and it would be a huge improvement if we can eliminate it.To meet the built-from-source requirement, the
Microsoft.NETCore.App.Crossgen2package may only contain things that were built from source. We can't use a pre-builtMicrosoft.NETCore.App.Runtime.<rid>package and should change to use artifacts that are built as part ofruntime.Then
runtimecan produce built-from-source artifacts in a single pass.We can then eliminate the
runtime-portablebuild by making builds use the non-portable packages built byruntime(like #75597 and dotnet/aspnetcore#43937)hoyosjs commentedon Sep 20, 2022
Is this needed for .NET 7? From what I see this depends on #69455 which is not merged. We are already past RC2 snap.
Once that's in, I wonder if we need a task to update
KnownFrameworkReferenceet al to account forAdditionalRuntimeIdentifiersinRuntimePackRuntimeIdentifiersand have the runtime packs be produced in a place visible to it.tmds commentedon Sep 21, 2022
I think we should set our goal to .NET 7 if that is feasible for everyone involved.
source-build's timing doesn't make it feasible to change something before rc.
In this case, the rid we're publishing would be an exact match with a known rid.
I don't know if it needs to be in the graph for this match to work ... may be.
I don't know about the Task. In #75597 I'm making some changes so source-build can pick up non-portable rids from a previous build.
It would be good if we could eliminate the known references to things we shouldn't be using when
DotNetBuildFromSource == true. That would be a good guard for the built-from-source requirement.cc @ericstj
ericstj commentedon Sep 21, 2022
Infrastructure changes are OK to go into 7.0 so long as they stay constrained to infrastructure and feed into the source-build requirements. We can take them to Tactics if we think there is some product risk - typically we don't and instead work to mitigate the risk through some PR validation (manual checks, test cases, etc). I closed out that PR since I'm not actively working on it and my time for making fixes (especially those that others are dependent on) is pretty small at the moment. I think it makes more sense for that to be driven by folks who need it and can test the end-to-end with the change.
9 remaining items
tmds commentedon Sep 29, 2022
@ViktorHofer @MichalStrehovsky can someone take a look at this?
tmds commentedon Sep 29, 2022
fyi, this is what my latest attempt looks like:
And
dotnet pack Microsoft.NETCore.App.Crossgen2.sfxprojgives me:MichalStrehovsky commentedon Sep 29, 2022
@mangod9 I Cc'd @dotnet/crossgen-contrib but there's no volunteer, could you nominate one? I assume this is blocking source build in .NET 7, but I don't know anything about source build or "packs".
mangod9 commentedon Sep 30, 2022
Is this required for 7? @trylek @AntonLapounov should be able to help here.
tmds commentedon Sep 30, 2022
Strictly speaking it is not required as we are capable of building .NET 7.
We should still aim to fix this for .NET 7 as it enables reducing source-build's build time by 25% and more, see dotnet/installer#14549 (comment).
tmds commentedon Oct 4, 2022
@trylek @AntonLapounov can one of you ptal?
AntonLapounov commentedon Oct 6, 2022
Are you seeing that failure in the
ResolveRuntimePackAssetstask when doing the following sequence of commands with the diff given above? I have no prior knowledge of that part of SDK; however, it should not be difficult to debug this.tmds commentedon Oct 10, 2022
I'll try to capture what happens when source-build runs this.
@ViktorHofer @AntonLapounov it doesn't look like the top-level verbosity ripples down to the
MSBuildtasks. How can I get more verbose logging of what happens in theseMSBuildtasks:runtime/src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Crossgen2.sfxproj
Lines 32 to 48 in c325a5a
tmds commentedon Oct 10, 2022
@AntonLapounov if you want to take a stab at this.
You can perform a build like this:
The Crossgen2 package should be built using
Microsoft.NETCore.App.Runtime.banana.10-x64package, instead of the pre-builtMicrosoft.NETCore.App.Runtime.linux-x64package.tmds commentedon Oct 10, 2022
Maybe this is already consuming the runtime pack that got built?
What does this do:
runtime/src/coreclr/tools/aot/crossgen2/crossgen2.csproj
Lines 56 to 58 in f156fb9
And, what is the contents of
MicrosoftNetCoreAppRuntimePackDir? Is this a package that got extracted, or was this built from source?cc @agocke @am11
agocke commentedon Oct 10, 2022
Yes, that pulls the runtime pack that just got built
am11 commentedon Oct 10, 2022
Btw,
<NativeAotSupportedproperty is set in two places with different conditions:runtime/eng/Subsets.props
Line 102 in d6fdb3a
runtime/src/coreclr/tools/aot/crossgen2/crossgen2.csproj
Line 8 in d6fdb3a
maybe it's better to merge the condition in crossgen2 into the top-level Subsets.props to avoid any unexpected build state. It is basically controlling "after compiling crossgen2 assembly, whether to publish crossgen2 as nativeaot app (NativeAotSupported=true) or a singlefileapp (NativeAotSupported=false)".
tmds commentedon Oct 11, 2022
Great! I can just close this then.