Use our local-built instances of tools from Microsoft.DotNet.BuildTools.CoreClr instead of using the package.#24347
Conversation
…ls.CoreClr instead of using the package.
|
@mikem8361 I was looking at one of @vancem's old PRs in this area (#17004) and he commented that we should look at moving to the Linux way of generating the DAC information so we can move off all of these tools that support the Windows method. Any chance you have some insight on to why that wasn't done or if we should do it? |
|
Looks like we need to figure out a way to build these tools targetting the host architecture instead of the target architecture. That might explain why this was never done. |
|
We have talked about doing what we do in Linux with the DAC table which doesn't require these tools but we really never have any time to do this work. It could introduce race conditions on when the DAC table is available (it did on Linux) made the change some what risky. I don't know all the reasons or problems with building and using the tools in coreclr like this PR is doing. I only had experience with the Linux mechanism. |
…ross-building and import the targets into the cross-build.
|
The diff in build.cmd looks pretty ugly. What I did there was move the cross-native build before the native build (and added a few extra CMake defines). |
|
@BruceForstall the _il_relthread-race test timed out on the Linux arm64 checked run. |
|
As this change is Windows-only I'm going to merge this in. |
Ugh. I recently disable it, but only under GCStress: #24174 |
…ls.CoreClr instead of using the package. (dotnet/coreclr#24347) * Use our local-built instances of tools from Microsoft.DotNet.BuildTools.CoreClr instead of using the package. * Fix const-correctness in InjectResource. * Build cross-arch native components before building native components for target arch. * Build InjectResource and GenClrDebugResource for the host arch when cross-building and import the targets into the cross-build. * install(EXPORT) in the directory where the target is created Commit migrated from dotnet/coreclr@1ffcf98
5 participants
Three years ago we moved the all of the sources for the tools in Microsoft.DotNet.BuildTools.CoreClr into the coreclr repo. For most of the tools, we never actually hooked up our CMake build to build the tools locally and use them.
This PR changes our build to use the local tool builds and removes our dependency on the Microsoft.DotNet.BuildTools.CoreClr package.