Make the cross-component build just another invocation of the build-runtime script #67108
Conversation
…untime script (Windows side)
…uilding the cross-arch tools.
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
ghost
assigned …ctures (like armv6)
… for cmd-calling-cmd semantics.
|
Tagging subscribers to this area: @hoyosjs Issue DetailsSimplify the CoreCLR build scripts by making the "cross component" builds be separate invocations of the script instead of having the builds included in the build-runtime script. With this change, each This PR also updates our native build scripts to use the same terminology as the CMake scripts for architecture/OS (switch to Build/Host/Target OS/Arch terminology) for an easier understanding of what's going on. This is a UX change for people who directly use the
|
When building cross-dac builds, we still end up running restore on runtime-prereqs.proj and runtime.proj, so we end up overridding the NuGet-generated MSBuild files, causing weird failures in CI.
|
@hoyosjs for review cc: @dotnet/dotnet-diag for visibility on changes to how the cross-OS DAC builds invoke the build-runtime script. |
There was a problem hiding this comment.
LGTM.
Seems like there should be a section in https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/README.md (or https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/cross-building.md, or somewhere similar) that talks about how to build the cross components. It looks like before it "just happened" (although I normally disabled it in my inner loop work), but now the commands to do it look non-obvious and "hidden" in YML file.
| @@ -106,7 +106,7 @@ jobs: | |||
| - script: $(Build.SourcesDirectory)/src/coreclr/build-runtime$(scriptExt) $(buildConfig) $(archType) $(crossArg) -ci $(compilerArg) -component alljits -component spmi | |||
| displayName: Build CoreCLR JIT | |||
| - ${{ if eq(parameters.osGroup, 'windows') }}: | |||
| - script: set __TestIntermediateDir=int&&$(Build.SourcesDirectory)/src/coreclr/build-runtime$(scriptExt) $(buildConfig) $(archType) -ci -component alljits -component spmi | |||
| - script: $(Build.SourcesDirectory)/src/coreclr/build-runtime$(scriptExt) $(buildConfig) $(archType) -ci -component alljits -component spmi | |||
There was a problem hiding this comment.
I'm glad you did this, but I thought we only did it because we ended up with larger-than-MAX_PATH paths if we didn't, in the CI. Maybe that's fixed?
There was a problem hiding this comment.
When we separated out the test build script from the regular CoreCLR runtime build script, we removed the last usages of this environment variable.
I think we require long-paths to be enabled now, so we don't hit any issues in CI with larger-than-MAX_PATH paths.
|
I'll make sure to add some docs about this for people who want to run the |
|
I've added some docs to the cross-building document about building the cross-targeting tools. |
| PgoInstrument=false; | ||
| NoPgoOptimize=true; | ||
| CrossBuild=false; | ||
| CMakeArgs=$(CMakeArgs) -DCLR_CROSS_COMPONENTS_BUILD=1" |
There was a problem hiding this comment.
Is CLR_CROSS_COMPONENTS_BUILD cmake def something that's better to add in the cmd or in runtime.proj? I don't see it being a thing for the subset infrastructure. I think it's also missing in the cross-building part of the docs.
There was a problem hiding this comment.
I think adding it out here is okay (I'd like to get rid of it, but I don't want to fight CMake for that). I'll update the docs.
|
Windows test failure is #48798. iOS and tvOS failures are due to a networking issue pulling down the provisioning profile. I'd link the issue number, but I can't seem to find it. |
Simplify the CoreCLR build scripts by making the "cross component" builds be separate invocations of the script instead of having the builds included in the build-runtime script. With this change, each
build-runtime.cmd/shruns one build (excluding theallcommand on the Windows script).This PR also updates our native build scripts to use the same terminology as the CMake scripts for architecture/OS (switch to Build/Host/Target OS/Arch terminology) for an easier understanding of what's going on.
This is a UX change for people who directly use the
build-runtimescript, so it should wait for an infra rollout to be merged.