forked from dotnet/runtime
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove run.exe and config.json (dotnet/coreclr#21608)
This moves us one step away from buildtools and towards arcade. This replaces run.sh and run.cmd (and all invocations) with "dotnet.sh msbuild" and "msbuild.cmd". - I'm using these wrapper scripts for now instead of those in eng/common in order to retain the very helpful "Running <command>" output in the build logs. - I'm using msbuild.cmd instead of dotnet.sh to match the current behavior that uses desktop msbuild on windows, instead of dotnet. All of the arguments that used to be implicitly generated by run.exe and config.json are now explicit, resulting in longer (but easier to copy+paste) commands. Some of these arguments are likely unnecessary, but in this change my goal is just to match the run.exe behavior. Later, I would like to go through and clean up parameters that don't need to be passed in every invocation. I might also consider moving more of the common arguments out into variables in a later change. Some of the wrapper scripts now have limited support for parsing "-Argument=Value" style parameters, to support our existing buildpipeline infrastructure, since I thought this was easier to test than changing our buildpipeline definitions. We can remove that parsing logic once we stop using buildpipeline (which has happened at this point). Some subtle parts of the change: * Add msbuild.cmd This simulates the behavior of Tools\msbuild.cmd, which calls desktop msbuild. * Fix BuildOS processing in package build and publish Previously, config.json had its own processing that would set OSName. Instead, we now pass it in explicitly where it's needed (building packages), or not at all (publishing them). * Handle "=" in publish-packages.cmd and other scripts This seems necessary to properly handle the azure access token * Set __BuildOS in PublishPackages Required for cases where the build OS isn't detected during the build such as freebsd. * Use dotnet msbuild in runtest.py This prevents us from having to deal with different quote escape behavior on windows and linux. Previously, arguments like fileloggerparameters and the logger were given quotes to escape semicolons in the argument. On unix, this prevented the argument from being split up by bash. On windows, it seems that the run.cmd/run.exe tools would prevent the extra quotes from being passed to msbuild.exe (desktop msbuild would choke on the quotes if they were passed along). Unlike desktop msbuild, dotnet msbuild is able to parse the quoted strings, so we simply psas the quoted arguments directly to it on windows. We may be able to do the same on unix. * Fix build-test.sh problem with BuildOS When copying native files during the unix test build, we rely on __BuildOS being set. Fixing the import order and always setting __BuildOS fixes this. We should eventually fix the inconsistent use of BuildOS vs __BuildOS. Commit migrated from dotnet/coreclr@1b43bd8
- Loading branch information
Showing
20 changed files
with
507 additions
and
979 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.