Skip to content
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

Merged
merged 22 commits into from
Sep 28, 2022

Conversation

tmds
Copy link
Member

@tmds tmds commented Aug 24, 2022

@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Aug 24, 2022
@ghost
Copy link

ghost commented Aug 24, 2022

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

Issue Details

The native build script uses the portablebuild argument when calculating the distro rid.

cc @MichaelSimons @omajid

Author: tmds
Assignees: -
Labels:

area-Infrastructure-coreclr

Milestone: -

@tmds tmds changed the title SourceBuild: pass portable argument via the build script arg. Pass TargetRid and SourceBuildNonPortable to the native scripts Aug 25, 2022
@tmds
Copy link
Member Author

tmds commented Aug 25, 2022

This PR passes the TargetRid and PortableBuild arguments to the native scripts.
The native scripts take these into account now when calculating __DistroRid.
When source-build passes a TargetRid that gets used as a __DistroRid.
Previously PortableBuild was ignored and assumed to be portable causing __DistroRid to always be the portable rid.

I've simplified init-distro-rid.sh a bit by only calling initNonPortableDistroRid for non-portable builds.

corehost managed and native now both use __DistroRid to determine the output directory.

@tmds tmds force-pushed the sb_portable branch 3 times, most recently from b887874 to 45c616b Compare August 26, 2022 11:09
@tmds
Copy link
Member Author

tmds commented Aug 26, 2022

This is now working.

When I run the ./build.sh command and pass in an unknown rid --packagerid fedora.40-x64 everything in the default set builds, with the exception of Microsoft.NETCore.App.Crossgen2.sfxproj which is using the PackageRID:

<MSBuild Projects="$(RepoRoot)src/coreclr/tools/aot/crossgen2/crossgen2.csproj"
Targets="Restore"
Properties="MSBuildRestoreSessionId=$([System.Guid]::NewGuid())
;RunningPublish=true
;RuntimeIdentifier=$(PackageRID)
;CoreCLRArtifactsPath=$(CoreCLRArtifactsPath)
;R2ROverridePath=$(MSBuildThisFileDirectory)ReadyToRun.targets" />
<MSBuild Projects="$(RepoRoot)src/coreclr/tools/aot/crossgen2/crossgen2.csproj"
Targets="Publish;PublishItemsOutputGroup"
Properties="RunningPublish=true
;RuntimeIdentifier=$(PackageRID)
;CoreCLRArtifactsPath=$(CoreCLRArtifactsPath)
;R2ROverridePath=$(MSBuildThisFileDirectory)ReadyToRun.targets">
<Output TaskParameter="TargetOutputs"
ItemName="_RawCrossgenPublishFiles" />
</MSBuild>

Using /p:AdditionalRuntimeIdentifiers=fedora.40-x64 it should be possible to make Microsoft.NETCore.Platforms.csproj generate a package that can be used to let the this project know about the fedora.40-x64 rid. I'm don't know how to do this in practice. @ericstj do you have some suggestions?

This PR is up for review.

@ericstj
Copy link
Member

ericstj commented Aug 26, 2022

generate a package that can be used to let the this project know about the fedora.40-x64 rid.

Looks like this is trying to publish crossgen2 as a self-contained application. I would imagine it needs #69455 and then needs to set BundledRuntimeIdentifierGraphFile. Still unclear to me if that's enough since I'm not sure how that project fetches the runtime that it's trying to link in.

@tmds
Copy link
Member Author

tmds commented Aug 28, 2022

Thanks @ericstj. I've created #74721 to look further into Microsoft.NETCore.App.Crossgen2.sfxproj for source-build.

Copy link
Member

@am11 am11 left a 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.

eng/build.sh Outdated Show resolved Hide resolved
eng/build.sh Outdated Show resolved Hide resolved
@tmds
Copy link
Member Author

tmds commented Aug 31, 2022

@am11 thanks for reviewing! I've addressed your feedback.

eng/build.sh Outdated Show resolved Hide resolved
@tmds
Copy link
Member Author

tmds commented Sep 13, 2022

Is this good to merge?

@tmds
Copy link
Member Author

tmds commented Sep 20, 2022

@dotnet/runtime-infrastructure is this good to merge?

@tmds
Copy link
Member Author

tmds commented Sep 26, 2022

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.

@ViktorHofer
Copy link
Member

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.

Copy link
Member

@trylek trylek left a 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.

@tmds
Copy link
Member Author

tmds commented Sep 27, 2022

If the Build Linux x64 release SourceBuild passes, that means this is in a good state.

@MichaelSimons can you review/approve from source-build perspective?

I've just extended SourceBuild.props so it figures out the appropriate RuntimeOS instead of taking it as an argument.
This needs to do a CI run.

@ViktorHofer ViktorHofer requested a review from am11 September 27, 2022 08:31
@ViktorHofer
Copy link
Member

@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>
Copy link
Member Author

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.

@MichalStrehovsky
Copy link
Member

@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.

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>
Copy link
Member Author

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?

Copy link
Member

@am11 am11 Sep 27, 2022

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...).

Copy link
Member Author

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?

Copy link
Member

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 by ILCompiler.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.

Copy link
Member Author

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does ILCompiler.csproj need a RuntimeIdentifier?

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.

@am11
Copy link
Member

am11 commented Sep 27, 2022

Am11 hope that's OK to ask you for a review

@ViktorHofer, I approved this PR three weeks ago. :)

Copy link
Member

@MichaelSimons MichaelSimons left a 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.

Copy link
Member

@jkoritzinsky jkoritzinsky left a 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

eng/pipelines/common/global-build-job.yml Show resolved Hide resolved
Co-authored-by: Jeremy Koritzinsky <jkoritzinsky@gmail.com>
@tmds
Copy link
Member Author

tmds commented Sep 28, 2022

@ViktorHofer or someone else, can you merge this please?

@ViktorHofer
Copy link
Member

Unrelated, but there was a segfault when invoking msbuild:

/__w/1/s/.dotnet/sdk/7.0.100-preview.7.22377.5/MSBuild.dll /nologo -maxcpucount /m -verbosity:m /v:minimal /bl:/__w/1/s/artifacts/log/Checked/ToolsetRestore.binlog /clp:Summary /clp:ErrorsOnly;NoSummary /nr:false /p:TreatWarningsAsErrors=true /p:ContinuousIntegrationBuild=true /p:__ToolsetLocationOutputFile=/__w/1/s/artifacts/toolset/8.0.0-beta.22469.1.txt /t:__WriteToolsetLocation /warnaserror /__w/1/s/artifacts/toolset/restore.proj
/__w/1/s/eng/common/tools.sh: line 474:   512 Segmentation fault      (core dumped) "$_InitializeBuildTool" "$@"
Build failed with exit code 139. Check errors above.
Finishing: Build and generate native prerequisites

Unfortunately I couldn't find a dump in the artifacts payload. Configuration: CoreCLR Product Build Linux x86 checked

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Infrastructure-coreclr community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

source-build TargetRid and SourceBuildNonPortable don't flow through to the native scripts
9 participants