Make parts of the build not require coreclr to be built

[steveisok]

As of right now there are parts of the build that require a dotnet in order to be built. Since mono has been added to dotnet/runtime, this places a dependency on building coreclr beforehand. Because mono can also be used as a 'dotnet', the goal of this issue is to track and remove this dependency where applicable.

Here are the spots we know of. Please feel free to correct / add:

• Libraries build
• Coreclr (runtime) tests (probably should include moving them to a shared spot)
• Libraries tests

@jaredpar

[jkotas]

parts of the build that require a dotnet in order to be built.

Could you please share more details on this?

We do support cross-targeting for Linux build. For example, you can build for ARM64 on x64 machine today. dotnet used by the build is the x64 version that comes as a downloaded package, and the dotnet produced by this build is the arm64 version. I do not think we are building x64 dotnet in this mode at all.

Can building for iOS work the same way?

[akoeplinger]

Yeah the goal is to not need coreclr for the iOS build.

I found one test project that relies on the testhost to generate some artifacts:

runtime/src/libraries/Microsoft.XmlSerializer.Generator/tests/Microsoft.XmlSerializer.Generator.Tests.csproj

Line 11 in 58cf146

<GeneratorCommand Condition="'$(TargetsNetCoreApp)' == 'true'">"$(TestHostRootPath)$([System.IO.Path]::GetFileName('$(DotNetTool)'))" --fx-version $(ProductVersion)</GeneratorCommand>

[steveisok]

By dotnet in this instance, I meant System.Private.CoreLib, but wasn't sure if that was everything.

It was easier to be generic ;-)

[jaredpar]

@steveisok

By dotnet in this instance, I meant System.Private.CoreLib, but wasn't sure if that was everything.

There are two versions of System.Private.Corelib that are produced by the build. Do you mean that we need to be able to build mono without buliding the coreclr version of System.Private.Corelib?

[steveisok]

@jaredpar Yeah, ideally. Libraries seems to have a hard dependency on the coreclr build because of SPC. If libraries could use mono's SPC instead for the mono build, that would be ideal.

runtime/eng/liveBuilds.targets

Lines 90 to 136 in 9981b1f

	<Target Name="ResolveCoreCLRFilesFromLocalBuild">
	<Error Condition="!Exists('$(CoreCLRArtifactsPath)')" Text="The CoreCLR artifacts path does not exist '$(CoreCLRArtifactsPath)'. The CoreCLR subset category must be built before building this project." />
	<PropertyGroup>
	<CoreCLRArtifactsPath>$([MSBuild]::NormalizeDirectory('$(CoreCLRArtifactsPath)'))</CoreCLRArtifactsPath>
	<!--
	Even though CoreCLRSharedFrameworkDir is statically initialized, set it again in case the
	value is different after CoreCLRArtifactsPath is normalized.
	-->
	<CoreCLRSharedFrameworkDir>$([MSBuild]::NormalizeDirectory('$(CoreCLRArtifactsPath)','sharedFramework'))</CoreCLRSharedFrameworkDir>
	<CoreCLRCrossTargetComponentDir
	Condition="'$(CoreCLRCrossTargetComponentDirName)' != ''">$([MSBuild]::NormalizeDirectory('$(CoreCLRArtifactsPath)','$(CoreCLRCrossTargetComponentDirName)','sharedFramework'))</CoreCLRCrossTargetComponentDir>
	</PropertyGroup>
	<ItemGroup>
	<CoreCLRFiles Include="$(CoreCLRSharedFrameworkDir)*.*" />
	<CoreCLRCrossTargetFiles Condition="'$(CoreCLRCrossTargetComponentDir)' != ''" Include="$(CoreCLRCrossTargetComponentDir)*.*" IsNative="true" />
	<CoreCLRFiles Include="$(CoreCLRArtifactsPath)Redist/**/*.dll" />
	<CoreCLRFiles>
	<IsNative>true</IsNative>
	</CoreCLRFiles>
	<_systemPrivateCoreLib Include="$(CoreCLRArtifactsPath)System.Private.CoreLib.dll"
	Condition="Exists('$(CoreCLRArtifactsPath)System.Private.CoreLib.dll')" />
	<_systemPrivateCoreLib Include="$(CoreCLRArtifactsPath)IL/System.Private.CoreLib.dll"
	Condition="Exists('$(CoreCLRArtifactsPath)IL/System.Private.CoreLib.dll') and '@(_systemPrivateCoreLib)' == ''" />
	<CoreCLRFiles Include="@(_systemPrivateCoreLib)" />
	<CoreCLRFiles
	Include="
	$(CoreCLRSharedFrameworkDir)PDB/*.pdb;
	$(CoreCLRSharedFrameworkDir)PDB/*.dbg;
	$(CoreCLRSharedFrameworkDir)PDB/*.dwarf" />
	<CoreCLRFiles
	Include="$(CoreCLRArtifactsPath)PDB/System.Private.CoreLib.pdb;" />
	<CoreCLRFiles Condition="Exists('$(CoreCLRArtifactsPath)PDB/System.Private.CoreLib.ni.pdb')"
	Include="$(CoreCLRArtifactsPath)PDB/System.Private.CoreLib.ni.pdb" />
	<CoreCLRCrossTargetFiles Condition="'$(CoreCLRCrossTargetComponentDir)' != ''"
	Include="
	$(CoreCLRCrossTargetComponentDir)PDB/*.pdb;
	$(CoreCLRCrossTargetComponentDir)PDB/*.dbg;
	$(CoreCLRCrossTargetComponentDir)PDB/*.dwarf" />
	<CoreCLRCrossTargetFiles>
	<TargetPath>runtime/$(CoreCLRCrossTargetComponentDirName)_$(TargetArchitecture)/native</TargetPath>
	</CoreCLRCrossTargetFiles>
	</ItemGroup>
	<Error Condition="'@(CoreCLRFiles)' == ''" Text="The CoreCLR subset category must be built before building this project." />
	</Target>

[jaredpar]

Yeah that looks like one of the targets I saw in my earlier PR that needed to be properly conditioned on whether we were building Mono / CoreCLR.

[steveisok]

One other point... If libraries just needs SPC to exist in order to build, it may be faster to default to mono's. No data to support that other than observation.

[jaredpar]

It's unclear. When I was unwinding this a few weeks ago it needed a specific one. All are likely a case by case issue.

[jkotas]

I found one test project that relies on the testhost to generate some artifacts:

This test has a long list of exclusions in SkipTestsOnPlatform, so you can just add to that, and file issue to get it fixed properly.