Skip to content

Simplify RID model and handle Linux libc flavors in orchestrated builds #113765

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.

Sign up for GitHub

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

Merged
merged 17 commits into from
Apr 14, 2025
Merged

Simplify RID model and handle Linux libc flavors in orchestrated builds #113765

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
9e230fe
Allow TargetOS and TargetRid to be overridden in DotNetBuild.props
jkoritzinsky Mar 21, 2025
15b7819
Adjust TargetOS for windows
jkoritzinsky Mar 21, 2025
963dd4d
Unify TargetRid and OutputRID and reuse our RID logic in DotNetBuild.…
jkoritzinsky Mar 26, 2025
3d67918
Remove concept of PackageRID. In the product, we produce packages for…
jkoritzinsky Mar 26, 2025
ba6b637
Use SDK portable RID for portable host OS paths
jkoritzinsky Mar 26, 2025
a4359f8
Update mono.proj
jkoritzinsky Mar 27, 2025
7aacc21
Fix repo-source-build publishing
jkoritzinsky Mar 27, 2025
017493d
Explicitly opt-in to using a local app host
jkoritzinsky Mar 27, 2025
d3bfb73
Enable restore binlogs using the new mechanism so I can figure out mo…
jkoritzinsky Mar 27, 2025
c4f0d9e
Don't force the apphost to be used for ILC. We may not have an apphos…
jkoritzinsky Mar 27, 2025
49247ba
Disable building crossgen2 and ilc on platforms where we won't be run…
jkoritzinsky Mar 27, 2025
6ffec62
Build the NativeExports with a release CRT always
jkoritzinsky Mar 27, 2025
f318e96
Various build fixes
jkoritzinsky Mar 28, 2025
0f8af8e
Set nethost path
jkoritzinsky Mar 28, 2025
38289af
Publish with BaseOS RID when its present
jkoritzinsky Apr 2, 2025
9d8edfe
Make sure the RID for the apphost pack is available
jkoritzinsky Apr 3, 2025
1076cdd
Undo Build.proj changes
jkoritzinsky Apr 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions Directory.Build.props
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -366,6 +366,7 @@
<PropertyGroup>
<CustomBeforeNoTargets>$(RepositoryEngineeringDir)NoTargetsSdk.BeforeTargets.targets</CustomBeforeNoTargets>
<CustomAfterTraversalTargets>$(RepositoryEngineeringDir)TraversalSdk.AfterTargets.targets</CustomAfterTraversalTargets>
<BeforeMicrosoftNETSdkTargets Condition="'$(MSBuildProjectExtension)' == '.ilproj'">$(BeforeMicrosoftNETSdkTargets);$(RepositoryEngineeringDir)ILSdk.BeforeTargets.targets</BeforeMicrosoftNETSdkTargets>
</PropertyGroup>

<PropertyGroup>
Expand Down
4 changes: 2 additions & 2 deletions Directory.Build.targets
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,11 +25,11 @@
<ItemGroup Condition="'$(DotNetBuildSourceOnly)' == 'true'">
<KnownFrameworkReference Update="Microsoft.NETCore.App">
<RuntimePackRuntimeIdentifiers
Condition="'%(TargetFramework)' == '$(NetCoreAppCurrent)'">%(RuntimePackRuntimeIdentifiers);$(PackageRID)</RuntimePackRuntimeIdentifiers>
Condition="'%(TargetFramework)' == '$(NetCoreAppCurrent)'">%(RuntimePackRuntimeIdentifiers);$(NETCoreSdkRuntimeIdentifier)</RuntimePackRuntimeIdentifiers>
</KnownFrameworkReference>
<KnownCrossgen2Pack Update="Microsoft.NETCore.App.Crossgen2">
<Crossgen2RuntimeIdentifiers
Condition="'%(TargetFramework)' == '$(NetCoreAppCurrent)'" >%(Crossgen2RuntimeIdentifiers);$(PackageRID)</Crossgen2RuntimeIdentifiers>
Condition="'%(TargetFramework)' == '$(NetCoreAppCurrent)'" >%(Crossgen2RuntimeIdentifiers);$(NETCoreSdkRuntimeIdentifier)</Crossgen2RuntimeIdentifiers>
</KnownCrossgen2Pack>
<!-- Avoid references to Microsoft.AspNetCore.App.Runtime.<rid> -->
<KnownFrameworkReference Remove="Microsoft.AspNetCore.App" />
Expand Down
64 changes: 15 additions & 49 deletions eng/DotNetBuild.props
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,56 +1,23 @@
<!-- When altering this file, include @dotnet/product-construction as a reviewer. -->

<Project>
<PropertyGroup>
<!-- TargetRid can be set by the orchestrator, so we need to set OutputRID to that as a default. -->
<OutputRID Condition="'$(OutputRID)' == ''">$(TargetRid)</OutputRID>
Copy link
Member

Choose a reason for hiding this comment

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

If I recall correctly, OutputRID is dotnet/runtime's name for TargetRid. May be you want eliminate OutputRID and adopt TargetRid as part of the cleanup/simplification.

</PropertyGroup>

<Import Project="$(MSBuildThisFileDirectory)OSArch.props" Condition="'$(_ImportedOSArchProps)' != 'true'" />
<Import Project="$(MSBuildThisFileDirectory)RuntimeIdentifier.props" Condition="'$(_ImportedRuntimeIdentifierProps)' != 'true'" />

<PropertyGroup>
<GitHubRepositoryName>runtime</GitHubRepositoryName>

<BaseInnerSourceBuildCommand Condition="'$(OS)' == 'Windows_NT'">.\build.cmd</BaseInnerSourceBuildCommand>
<BaseInnerSourceBuildCommand Condition="'$(OS)' != 'Windows_NT'">./build.sh</BaseInnerSourceBuildCommand>

<_hostRid>$([System.Runtime.InteropServices.RuntimeInformation]::RuntimeIdentifier)</_hostRid>
<!-- TargetRid names what gets built. -->
<TargetRid Condition="'$(TargetRid)' == ''">$(_hostRid)</TargetRid>

<!-- Split e.g. 'fedora.33-x64' into 'fedora.33' and 'x64'. -->
<_targetRidPlatformIndex>$(TargetRid.LastIndexOf('-'))</_targetRidPlatformIndex>
<TargetArch>$(TargetRid.Substring($(_targetRidPlatformIndex)).TrimStart('-'))</TargetArch>
<TargetOS>$(TargetRid.Substring(0, $(_targetRidPlatformIndex)))</TargetOS>

<_hostRidPlatformIndex>$(_hostRid.LastIndexOf('-'))</_hostRidPlatformIndex>
<_hostArch>$(_hostRid.Substring($(_hostRidPlatformIndex)).TrimStart('-'))</_hostArch>

<LogVerbosity Condition="'$(LogVerbosity)' == ''">minimal</LogVerbosity>
</PropertyGroup>

<!-- Keep this list in sync with https://github.com/dotnet/sdk/blob/main/src/SourceBuild/content/Directory.Build.props#L23 -->
<PropertyGroup Label="ShortStacks">
<ShortStack Condition="'$(TargetOS)' == 'wasi'">true</ShortStack>
<ShortStack Condition="'$(TargetOS)' == 'browser'">true</ShortStack>
<ShortStack Condition="'$(TargetOS)' == 'ios'">true</ShortStack>
<ShortStack Condition="'$(TargetOS)' == 'iossimulator'">true</ShortStack>
<ShortStack Condition="'$(TargetOS)' == 'tvos'">true</ShortStack>
<ShortStack Condition="'$(TargetOS)' == 'tvossimulator'">true</ShortStack>
<ShortStack Condition="'$(TargetOS)' == 'maccatalyst'">true</ShortStack>
<ShortStack Condition="'$(TargetOS)' == 'android'">true</ShortStack>
<ShortStack Condition="'$(TargetOS)' == 'linux-bionic'">true</ShortStack>
<!-- Mono LLVM builds are short -->
<ShortStack Condition="'$(DotNetBuildMonoEnableLLVM)' == 'true' or '$(DotNetBuildMonoAOTEnableLLVM)' == 'true'">true</ShortStack>
</PropertyGroup>

<!--
Allow the VMR orchestrator to control whether or not to build rid-specific artifacts,
but provide defaults until the VMR orchestrator provides controls in all scenarios.
-->
<PropertyGroup Condition="'$(EnableDefaultRidSpecificArtifacts)' == ''">
<!-- Source-build always needs all artifacts to be published. -->
<EnableDefaultRidSpecificArtifacts Condition="'$(DotNetBuildSourceOnly)' != ''">false</EnableDefaultRidSpecificArtifacts>
<!-- Short-stack builds should always only publish RID-specific artifacts. -->
<EnableDefaultRidSpecificArtifacts Condition="'$(ShortStack)' == 'true'">true</EnableDefaultRidSpecificArtifacts>
<!-- If no override is specified, don't use RID-specific publishing. Instead, publish everything. -->
<EnableDefaultRidSpecificArtifacts Condition="'$(EnableDefaultRidSpecificArtifacts)' == ''">false</EnableDefaultRidSpecificArtifacts>
</PropertyGroup>

<Target Name="GetRuntimeSourceBuildCommandConfiguration"
BeforeTargets="GetSourceBuildCommandConfiguration">
<PropertyGroup>
Expand All @@ -63,21 +30,20 @@
<InnerBuildArgs Condition="'$(DotNetBuildOrchestrator)' == 'true' and '$(Sign)' == 'true'">$(InnerBuildArgs) $(FlagParameterPrefix)sign</InnerBuildArgs>
<InnerBuildArgs>$(InnerBuildArgs) $(FlagParameterPrefix)pack</InnerBuildArgs>

<InnerBuildArgs>$(InnerBuildArgs) $(FlagParameterPrefix)arch $(TargetArch)</InnerBuildArgs>
<InnerBuildArgs Condition="'$(DotNetBuildSourceOnly)' != 'true'">$(InnerBuildArgs) $(FlagParameterPrefix)os $(TargetOS)</InnerBuildArgs>
<InnerBuildArgs Condition="'$(CrossBuild)' == 'true' or ('$(TargetArch)' != '$(_hostArch)' and '$(ShortStack)' != 'true')">$(InnerBuildArgs) $(FlagParameterPrefix)cross</InnerBuildArgs>
<InnerBuildArgs>$(InnerBuildArgs) $(FlagParameterPrefix)arch $(TargetArchitecture)</InnerBuildArgs>
<InnerBuildArgs Condition="'$(_portableOS)' == 'win'">$(InnerBuildArgs) $(FlagParameterPrefix)os windows</InnerBuildArgs>
<InnerBuildArgs>$(InnerBuildArgs) $(FlagParameterPrefix)os $(_portableOS)</InnerBuildArgs>
<!-- Mobile builds are never "cross" builds as they don't have a rootfs-based filesystem build. -->
<InnerBuildArgs Condition="'$(CrossBuild)' == 'true' or ('$(TargetArchitecture)' != '$(BuildArchitecture)' and '$(TargetsMobile)' != 'true')">$(InnerBuildArgs) $(FlagParameterPrefix)cross</InnerBuildArgs>
Copy link
Member

@akoeplinger akoeplinger Apr 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

osx/win x64 host building for osx/win arm64 target is in the same situation and also doesn't use rootfs.

I know this is pre-existing but maybe for your cleanup instead of CrossBuild and the -cross flag we should have BuildUsingCrossRootFs and only apply it where we actually use a rootfs ?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd like to do that in a future PR so we can get this in by the deadline.

Copy link
Member

Choose a reason for hiding this comment

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

yes, sorry if I wasn't clear but I was suggesting to keep this in mind for a separate cleanup PR.

<InnerBuildArgs>$(InnerBuildArgs) $(FlagParameterPrefix)configuration $(Configuration)</InnerBuildArgs>
<InnerBuildArgs>$(InnerBuildArgs) $(FlagParameterPrefix)verbosity $(LogVerbosity)</InnerBuildArgs>
<InnerBuildArgs>$(InnerBuildArgs) $(FlagParameterPrefix)nodereuse $(ArcadeFalseBoolBuildArg)</InnerBuildArgs>
<InnerBuildArgs>$(InnerBuildArgs) $(FlagParameterPrefix)warnAsError $(ArcadeFalseBoolBuildArg)</InnerBuildArgs>
<InnerBuildArgs Condition="'$(DotNetBuildUseMonoRuntime)' == 'true'">$(InnerBuildArgs) $(FlagParameterPrefix)usemonoruntime</InnerBuildArgs>
<!-- TODO: This parameter is only available on the Unix script. Intentional? -->
<InnerBuildArgs Condition="'$(OS)' != 'Windows_NT'">$(InnerBuildArgs) --outputrid $(TargetRid)</InnerBuildArgs>
<!-- PackageOS and ToolsOS control the rids of prebuilts consumed by the build.
They are set to RuntimeOS so they match with the build SDK rid. -->
<InnerBuildArgs Condition="'$(RuntimeOS)' != ''">$(InnerBuildArgs) /p:PackageOS=$(RuntimeOS) /p:ToolsOS=$(RuntimeOS)</InnerBuildArgs>
<!-- 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. -->
<InnerBuildArgs Condition="'$(OS)' != 'Windows_NT'">$(InnerBuildArgs) --outputrid $(OutputRID)</InnerBuildArgs>
<!-- BaseOS is an expected known rid in the graph that OutputRID is compatible with.
It's used to add OutputRID in the graph if the parent can't be detected. -->
<InnerBuildArgs>$(InnerBuildArgs) /p:AdditionalRuntimeIdentifierParent=$(BaseOS) /p:BaseOS=$(BaseOS)</InnerBuildArgs>
<!-- Pass through special build modes controlled by properties -->
<InnerBuildArgs Condition="'$(DotNetBuildRuntimeWasmEnableThreads)' == 'true'">$(InnerBuildArgs) /p:WasmEnableThreads=true</InnerBuildArgs>
Expand Down
6 changes: 6 additions & 0 deletions eng/ILSdk.BeforeTargets.targets
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
<Project>
<PropertyGroup>
<!-- Microsoft.NET.Sdk.IL SDK defaults to the portable host rid. Match it to the SDK RID (so source-build scenarios use the same RID as the host SDK). -->
<MicrosoftNetCoreIlasmPackageRuntimeId>$(NETCoreSdkRuntimeIdentifier)</MicrosoftNetCoreIlasmPackageRuntimeId>
</PropertyGroup>
</Project>
6 changes: 5 additions & 1 deletion eng/OSArch.props
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,4 +32,8 @@
<TargetArchitecture Condition="'$(TargetArchitecture)' == ''">x64</TargetArchitecture>
<Platform Condition="'$(Platform)' == '' and '$(InferPlatformFromTargetArchitecture)' == 'true'">$(TargetArchitecture)</Platform>
</PropertyGroup>
</Project>

<PropertyGroup>
<_ImportedOSArchProps>true</_ImportedOSArchProps>
</PropertyGroup>
</Project>
2 changes: 1 addition & 1 deletion eng/Publishing.props
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -78,7 +78,7 @@
but we do produce them in both the VMR and the runtime official build.
-->
<PropertyGroup Condition="'$(DotNetBuildOrchestrator)' == 'true'">
<ShouldGenerateProductVersionFiles Condition="'$(PackageRID)' == 'win-x64' and ('$(DotNetBuildPass)' == '' or '$(DotNetBuildPass)' == '1')">true</ShouldGenerateProductVersionFiles>
<ShouldGenerateProductVersionFiles Condition="'$(OutputRID)' == 'win-x64' and ('$(DotNetBuildPass)' == '' or '$(DotNetBuildPass)' == '1')">true</ShouldGenerateProductVersionFiles>
<ShouldGenerateProductVersionFiles Condition="'$(DotNetBuildSourceOnly)' == 'true'">true</ShouldGenerateProductVersionFiles>
</PropertyGroup>

Expand Down
37 changes: 4 additions & 33 deletions eng/RuntimeIdentifier.props
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,38 +25,6 @@
<_portableOS Condition="'$(HostOS)' == 'win' and '$(TargetsMobile)' != 'true'">win</_portableOS>
</PropertyGroup>

<!-- PackageRID is used for packages needed for the target. -->
<PropertyGroup Label="CalculatePackageRID">
<_packageOS>$(_portableOS)</_packageOS>

<_packageOS Condition="'$(CrossBuild)' == 'true' and '$(_portableOS)' != 'linux-musl' and '$(_portableOS)' != 'linux-bionic' and '$(_portableOS)' != 'android'">$(_hostOS)</_packageOS>

<!-- source-build sets PackageOS to build with non-portable rid packages that were source-built previously. -->
<PackageRID Condition="'$(PackageOS)' != ''">$(PackageOS)-$(TargetArchitecture)</PackageRID>
Copy link
Member

Choose a reason for hiding this comment

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

@jkoritzinsky it seems that this PR is removing the distinction between PackageRID and OutputRID?

PackageRID are packages that are consumed from the previous build.
OutputRID is the name of the packages that are produced.

For example:

Let's say I've built an SDK on Banana Linux 8.1 that has a rid of banana.8.1-x64.

For Banana Linux 8.2, I want to use this banana.8.1-x64 SDK to build a new SDK with a rid of banana.8.2-x64.

For that build, PackageRID=banana.8.1-x64 and OutputRID=banana.8.2-x64.

cc @ViktorHofer

Copy link
Member

Choose a reason for hiding this comment

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

I think @jkoritzinsky's approach is that PackageRID would be the "host's RID" which is provided by the SDK. In your example NETCoreSdkRuntimeIdentifier will have banana.8.1-x64. Though I don't remember all the corner cases we discussed in previous PRs (onboarding new platform, community platform cross with MSFT's SDK, community platform on its native host with previous version of SDK etc.).

I bet there will be snakes but perhaps not all of the scenarios need to be supported if there is a way to override host RID for exotic cases (like onboarding) and rest of them are supported by source build.

Copy link
Member

@tmds tmds Mar 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

I find the substitutions from PackageRID to OutputRID suspicious.

What currently works is that you can build the VMR with Microsoft's portable SDK and produce an SDK with name rid1. Then you can use that SDK with the other artifacts generated for rid1, and build an SDK named rid2 (on any system that is binary compatible with the rid1 SDK).

These build work without having to manually handle any rids.

We should preserve this UX and avoid relying on distro owners to understand rids.

If this scenario continues to work as is, then this is all good. Otherwise, I think we've oversimplified it and pushed complexity to the user.

Copy link
Member Author

@jkoritzinsky jkoritzinsky Mar 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Some of the PackageRID to OutputRID substitutions come from places where I added PackageRID and the correct option was OutputRID. The documentation is quite sparse about this, so I selected the wrong one of the two. Most of those were during this release, so no one noticed the issue so far.

I'm highly confident about using NETCoreSdkRuntimeIdentifier as the substitution for the places where PackageRID was correctly used, as PackageOS (which feeds into PackageRID) was calculated from NETCoreSdkRuntimeIdentifier: https://github.com/dotnet/sdk/blob/38767559c98d3b08fb6af8978e8bd39114d953b3/src/SourceBuild/content/repo-projects/Directory.Build.targets#L34. We rely on this invariant throughout the system (for our _inbuild projects for example).

The scenario @tmds shared above will work.

In fact, this brings us closer to supporting the following scenario cleanly:

  1. Start with an SDK targeting banana.8.1-x64
  2. Build an SDK targeting banana.8.2-arm64 with the SDK from step 1.

Today, PackageRID would be banana.8.1-arm64, which is wrong, and ToolsRID would be banana.8.1-x64, which is correct. OutputRID would be the correct banana.8.2-arm64. After this change, we'd use banana.8.1-x64 in all places where it's the correct option and OutputRID would continue to be banana.8.2-arm64.

Copy link
Member

Choose a reason for hiding this comment

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

this brings us closer to supporting the following scenario cleanly:

Fyi, we're cross-building the vmr for s390x/ppc64le (both use mono) and those SDK works for doing a native vmr build on these architectures. If it's wrong, we haven't noticed in our builds.

Copy link
Member

Choose a reason for hiding this comment

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

The correct solution is to fully implement a bootstrapping build in runtime.

This sounds heavy. As I understand it, this is a naming issue. If we let the build SDK know about the OutputRID being built, then it should work.

Long long ago.NET could only be built from portable RID assets and source-build built runtime twice: once to produce portably-named source-built artifacts, and once producing non-portably named source-build artifacts.

Let's avoid going back in that direction and try to solve naming issues by handling names.

Copy link
Member

Choose a reason for hiding this comment

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

Long long ago.NET could only be built from portable RID assets and source-build built runtime twice: once to produce portably-named source-built artifacts, and once producing non-portably named source-build artifacts.

IIUC, it won't be the same type of bootstrapping. It'd be optional for platform which do not have SDK or LKG baseline available for source-build, like linux-riscv64. e.g. if fedora-x64 has net10-preview2 available, which is required to build preview3, it doesn't need to bootstrap.

BTW, the TwoStage build which is running in CI in every PR these days is similar thing (which I think will be refurbished as "new bootstrapping"). It doesn't multiply the build time, instead it only builds selective components (80% of the product) in first stage and rest in second. They are mutually exclusive.

Copy link
Member Author

Choose a reason for hiding this comment

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

The correct solution is to fully implement a bootstrapping build in runtime.

This sounds heavy. As I understand it, this is a naming issue. If we let the build SDK know about the OutputRID being built, then it should work.

It's actually not a naming issue. The assets are already going to be correctly named (as packing is done somewhere else that can know the RID). That hasn't changed in this PR. The problem is the restore having a RID that the LKG sdk's RID graph doesn't know about. And we can't just change it at build time as the RID needs to be the same for restore and build otherwise the SDK errors out. The changes I have made in this PR will put us back into the exact same state as we have in main for SourceBuild.

This would be a very slim bootstrapping process like @am11 mentioned. It would build the minimal assets needed to be able to ILC something for OutputRid, so basically the following list:

  • runtime-agnostic managed libraries
  • native AOT runtime
  • native AOT managed libraries
  • updated RID graph

Then we would build the product using said updated rid graph and targeting the live assets to build ilc and crossgen2 for the target RID.

Copy link
Member

Choose a reason for hiding this comment

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

It's actually not a naming issue. The assets are already going to be correctly named (as packing is done somewhere else that can know the RID). That hasn't changed in this PR. The problem is the restore having a RID that the LKG sdk's RID graph doesn't know about.

The unknown name is what I meant by a naming issue.

And we can't just change it at build time as the RID needs to be the same for restore and build otherwise the SDK errors out.

I understand the RID needs to be the same for restore and build for the SDK. I think if the RID is known to the SDK, the restore operation could be made to result in: I shouldn't need to download anything for this RID, we'll be using live built assets.

Anyway...

The changes I have made in this PR will put us back into the exact same state as we have in main for SourceBuild.

I will run it through some scenarios to validate.

Copy link
Member

Choose a reason for hiding this comment

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

I will run it through some scenarios to validate.

I won't have any time to do validation this week. I can make time for it early next week.

Feel free to merge already, unless you want to wait for some extra confirmation the behavior has not changed.

<PackageRID Condition="'$(PackageRID)' == ''">$(_packageOS)-$(TargetArchitecture)</PackageRID>
</PropertyGroup>

<!-- ToolsRID is used for packages needed on the build host. -->
<PropertyGroup Label="CalculateToolsRID">
<!-- _portableHostOS is the portable rid-OS corresponding to the build host platform.

To determine _portableHostOS we use _hostOS, similar to how _portableOS is calculated from TargetOS.

When we're not cross-building we can detect linux flavors by looking at _portableOS
because the target platform and the build host platform are the same.
For cross-builds, we're currently unable to detect the flavors. -->
<_portableHostOS>$(_hostOS)</_portableHostOS>
<_portableHostOS Condition="'$(_portableHostOS)' == 'windows'">win</_portableHostOS>
<_portableHostOS Condition="'$(CrossBuild)' != 'true' and '$(_portableOS)' == 'linux-musl'">linux-musl</_portableHostOS>

<!-- source-build sets ToolsOS to build with non-portable rid packages that were source-built previously. -->
<ToolsRID Condition="'$(ToolsOS)' != ''">$(ToolsOS)-$(_hostArch)</ToolsRID>
<ToolsRID Condition="'$(ToolsRID)' == ''">$(_portableHostOS)-$(_hostArch)</ToolsRID>

<!-- Microsoft.NET.Sdk.IL SDK defaults to the portable host rid. Match it to ToolsRID (for source-build). -->
<MicrosoftNetCoreIlasmPackageRuntimeId>$(ToolsRID)</MicrosoftNetCoreIlasmPackageRuntimeId>
</PropertyGroup>

<!-- OutputRID is used to name the target platform.
For portable builds, OutputRID matches _portableOS.
For non-portable builds, it uses __DistroRid (from the native build script), or falls back to RuntimeInformation.RuntimeIdentifier.
Expand Down Expand Up @@ -97,4 +65,7 @@
<TargetsWindows Condition="'$(TargetOS)' == 'windows'">true</TargetsWindows>
<TargetsUnix Condition="'$(TargetsFreeBSD)' == 'true' or '$(Targetsillumos)' == 'true' or '$(TargetsSolaris)' == 'true' or '$(TargetsHaiku)' == 'true' or '$(TargetsLinux)' == 'true' or '$(TargetsNetBSD)' == 'true' or '$(TargetsOSX)' == 'true' or '$(TargetsMacCatalyst)' == 'true' or '$(TargetstvOS)' == 'true' or '$(TargetsiOS)' == 'true' or '$(TargetsAndroid)' == 'true'">true</TargetsUnix>
</PropertyGroup>
</Project>
<PropertyGroup>
<_ImportedRuntimeIdentifierProps>true</_ImportedRuntimeIdentifierProps>
</PropertyGroup>
</Project>
18 changes: 9 additions & 9 deletions eng/Signing.props
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,20 +14,20 @@
We have specific jobs that produce RID-agnostic packages or packages for multiple RIDs set this property.
- Mono AOT LLVM builds only publish LLVM-specific packages always.

VMR jobs can control whether or not a vertical has EnableDefaultRidSpecificArtifacts set to true or false in DotNetBuild.props.
The VMR orchestrator will set EnableDefaultRidSpecificArtifacts=true as a global property based on its configuration.

Packages that do not meet the above rules are added with Vertical visibility in the VMR and excluded in non-VMR builds.
-->
<EnableDefaultArtifacts Condition="'$(MonoAOTEnableLLVM)' == 'true'">false</EnableDefaultArtifacts>
<EnableBlobArtifacts>true</EnableBlobArtifacts>
<EnableBlobArtifacts Condition="'$(MonoAOTEnableLLVM)' == 'true'">false</EnableBlobArtifacts>

<!-- Set the TargetRid property to our PackageRID, which is the right RID to use for selecting packages from our repo. -->
<TargetRid>$(PackageRID)</TargetRid>
<!-- Set the TargetRid property to our OutputRID, which is the right RID to use for selecting packages from our repo. -->
<TargetRid>$(OutputRID)</TargetRid>

<!-- The final stage of the runtime official build should publish everything. -->
<EnableDefaultRidSpecificArtifacts Condition="'$(DotNetFinalPublish)' != ''">false</EnableDefaultRidSpecificArtifacts>
<EnableDefaultRidSpecificArtifacts Condition="'$(EnableDefaultRidSpecificArtifacts)' == ''">true</EnableDefaultRidSpecificArtifacts>
<EnableDefaultRidSpecificArtifacts Condition="'$(EnableDefaultRidSpecificArtifacts)' == '' and '$(DotNetBuildOrchestrator)' != 'true'">true</EnableDefaultRidSpecificArtifacts>

<UseDotNetCertificate>true</UseDotNetCertificate>
</PropertyGroup>
Expand Down Expand Up @@ -119,29 +119,29 @@
<Choose>
<When Condition="'$(MonoAOTEnableLLVM)' == 'true'">
<ItemGroup>
<PackageArtifacts Include="$(ArtifactsPackagesDir)**\*.LLVM.AOT.$(PackageRID).*.nupkg" />
<PackageArtifacts Include="$(ArtifactsPackagesDir)**\*.LLVM.AOT.$(OutputRID).*.nupkg" />
<Artifact Include="@(PackageArtifacts)"
IsShipping="$([System.String]::Copy('%(RecursiveDir)').StartsWith('Shipping'))"
Kind="Package" />
</ItemGroup>
</When>
<When Condition="'$(EnableDefaultRidSpecificArtifacts)' == 'true'">
<ItemGroup Condition="'$(PackageRID)' == 'ios-arm64'">
<ItemGroup Condition="'$(OutputRID)' == 'ios-arm64'">
<PackageArtifacts
Include="$(ArtifactsPackagesDir)**\Microsoft.NET.Runtime.iOS.Sample.Mono.*.nupkg;
$(ArtifactsPackagesDir)**\Microsoft.NET.Runtime.LibraryBuilder.Sdk.*.nupkg;
$(ArtifactsPackagesDir)**\Microsoft.NET.Runtime.MonoAOTCompiler.Task.*.nupkg;
$(ArtifactsPackagesDir)**\Microsoft.NET.Runtime.MonoTargets.Sdk.*.nupkg" />
</ItemGroup>
<ItemGroup Condition="'$(PackageRID)' == 'android-arm64'">
<ItemGroup Condition="'$(OutputRID)' == 'android-arm64'">
<PackageArtifacts
Include="$(ArtifactsPackagesDir)**\Microsoft.NET.Runtime.Android.Sample.Mono.*.nupkg" />
</ItemGroup>
<ItemGroup Condition="'$(PackageRID)' == 'wasi-wasm'">
<ItemGroup Condition="'$(OutputRID)' == 'wasi-wasm'">
<PackageArtifacts
Include="$(ArtifactsPackagesDir)**\Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk.*.nupkg" />
</ItemGroup>
<ItemGroup Condition="'$(PackageRID)' == 'browser-wasm' and '$(WasmEnableThreads)' != 'true'">
<ItemGroup Condition="'$(OutputRID)' == 'browser-wasm' and '$(WasmEnableThreads)' != 'true'">
<PackageArtifacts
Include="$(ArtifactsPackagesDir)**\Microsoft.NET.Runtime.wasm.Sample.Mono.*.nupkg;
$(ArtifactsPackagesDir)**\Microsoft.NET.Runtime.WorkloadTesting.Internal.*.nupkg;
Expand Down
Loading
Loading