-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass TargetRid and SourceBuildNonPortable to the native scripts #74504
Conversation
Tagging subscribers to this area: @hoyosjs Issue DetailsThe native build script uses the portablebuild argument when calculating the distro rid.
|
This PR passes the TargetRid and PortableBuild arguments to the native scripts. I've simplified corehost managed and native now both use __DistroRid to determine the output directory. |
b887874
to
45c616b
Compare
This is now working. When I run the runtime/src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Crossgen2.sfxproj Lines 32 to 48 in 7aef48a
Using This PR is up for review. |
Looks like this is trying to publish crossgen2 as a self-contained application. I would imagine it needs #69455 and then needs to set |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few suggestions, otherwise looks good.
@am11 thanks for reviewing! I've addressed your feedback. |
Is this good to merge? |
@dotnet/runtime-infrastructure is this good to merge? |
Can you merge this? This enables building runtime repo for source-build on platforms where the target rid is not yet known in the rid graph. |
Thanks for the work so far Tom. Unfortunately as already I mentioned, I'm not the right person to sign-off this change and I just asked the CLR team again to take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I apologize, I'm not really an expert in this area. To my limited knowledge the change looks good but I'm reluctant to approve it, I'd definitely suggest finding a reviewer who's more familiar with source build.
If the @MichaelSimons can you review/approve from source-build perspective? I've just extended |
@am11 @MichalStrehovsky can you please take a look? Am11 hope that's OK to ask you for a review but if I remember correctly, you made the original changes around RuntimeOS/TargetArch/TargetRid/... and have the most expertise in that area. |
|
||
<!-- BaseOS is an expected known rid in the graph that TargetRid is compatible with. | ||
It's used to add TargetRid in the graph if the parent can't be detected. --> | ||
<BaseOS>$(RuntimeOS)</BaseOS> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TargetRid
, RuntimeOS
, and BaseOS
should ripple down from source-build.
TargetRid
names what is built.. The build will add this rid to graph. If it can't find a parent (for example, alpine.4.15-x64
finds alpine-x64
as the parent) then BaseOS
is used as a parent. For example, if Orange Linux
is a musl based version of Linux, BaseOS
should be linux-musl
.
RuntimeOS
is the rid of the prebuilt SDK and artifacts that get used during the build. source-build/installer should set this to match the bootstrap SDK's NETCoreSdkRuntimeIdentifier
.
I can only be authoritative for the diff in src/coreclr/tools/aot/ILCompiler/ILCompiler.csproj. But this is an area that went through like 5 different values in the past year (used to be defined as __DistroRid, then ToolsRid, then Crossgen2PackageRid, then OutputRid, and now with this change PackageRid). I don't know what any of those mean. As long as the CI passes and we're still generating ARM64 bits when crossbuilding ARM64 from x64 (which would not be covered by the CI), that particular diff LGTM. |
@@ -1,7 +1,7 @@ | |||
<Project Sdk="Microsoft.NET.Sdk"> | |||
<PropertyGroup> | |||
<OutputPath>$(RuntimeBinDir)ilc/</OutputPath> | |||
<RuntimeIdentifier>$(OutputRid)</RuntimeIdentifier> | |||
<RuntimeIdentifier>$(PackageRID)</RuntimeIdentifier> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MichalStrehovsky I think this may be breaking to the cross-compilation scenario.
OutputRid
is linux-arm64
and PackageRID
is linux-x64
.
I see there is ILCompiler.csproj
, and ILCompiler_crossarch.csproj
.
This first, I guess, is used for creating a NuGet package (host: arm64 -> target: arm64)?
I think the latter is the one that is used on the build host (host: x64 -> target: arm64)?
Is that right?
I don't understand when/how ILCompiler
gets packed. Where does this happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It gets packed by a special project file pkgproj src/installer/pkg/projects/Microsoft.DotNet.ILCompiler/Microsoft.DotNet.ILCompiler.pkgproj
, which is ultimately using $(OutputRid)
(via properties inheritance).
This change is correct. The reason we haven't gotten any complaints before is because we are not (yet) cross-compiling ILCompiler in a way that HostOS and TargetOS differ (the first part of RID...).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@am11 does Microsoft.DotNet.ILCompiler.pkgproj
consume files built by ILCompiler.csproj
?
If so, for what rid were these files built? OutputRid
or PackageRID
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Microsoft.DotNet.ILCompiler.pkgproj
consume files built byILCompiler.csproj
It collects the files from various location and packs them together in a zip (.nupkg) file. In this case, PackageRID
is only used to restore the packages when building the managed assembly (we don't have proeprocessor conditions based on RuntimeIdentifier, it's all MSIL or #if TARGET_{OS_or_ARCH}
in the code). OutputRid is used in pkgprojs or passed to cmake to decide which bits to build and pack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like we won't break anything then.
From what you said, I wonder: does ILCompiler.csproj
need a RuntimeIdentifier
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does
ILCompiler.csproj
need aRuntimeIdentifier
?
Good question. As I understood it; RuntimeIdentifer
during the restore step is used to decide which runtime.{rid}.xyz
for a given package to restore, if the package has native assets. Here, ILCompiler.props has multiple PackageReference and ProjectReference, it is likely that the resolved dependency graph of this project (under obj
directory) has such package-with-native-assets
which is requiring the RuntimeIdentifier
to be specified.
@ViktorHofer, I approved this PR three weeks ago. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve from a source-build perspective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I've also approved the Arcade PR
Co-authored-by: Jeremy Koritzinsky <jkoritzinsky@gmail.com>
@ViktorHofer or someone else, can you merge this please? |
Unrelated, but there was a segfault when invoking msbuild:
Unfortunately I couldn't find a dump in the artifacts payload. Configuration: |
Fixes #74577.
cc @MichaelSimons @omajid