Update docs for building runtime with local Roslyn#80725
Conversation
docs/contributing/Building, Debugging, and Testing on Windows.md
Outdated
Show resolved
Hide resolved
docs/contributing/Building, Debugging, and Testing on Windows.md
Outdated
Show resolved
Hide resolved
docs/contributing/Building, Debugging, and Testing on Windows.md
Outdated
Show resolved
Hide resolved
docs/contributing/Building, Debugging, and Testing on Windows.md
Outdated
Show resolved
Hide resolved
| - add `<RestoreAdditionalProjectSources><PATH-TO-YOUR-ROSLYN-ENLISTMENT>\artifacts\packages\Debug\Shipping\</RestoreAdditionalProjectSources>` using the local path to your `roslyn` repo to `Directory.Build.props` | ||
| - add `<UsingToolMicrosoftNetCompilers>true</UsingToolMicrosoftNetCompilers>` and `<MicrosoftNetCompilersToolsetVersion>4.1.0-dev</MicrosoftNetCompilersToolsetVersion>` with the package version you just packed (look in above artifacts folder) to `eng/Versions.props` | ||
| 1. Make sure that you can build the `runtime` repo as baseline (run `build.cmd libs+libs.tests`, which should be sufficient to build all C# code, installing any prerequisites if prompted to, and perhaps `git clean -xdf` and `build.cmd -restore` initially - see [runtime repo documentation](https://github.com/dotnet/runtime/blob/main/docs/workflow/README.md) for specific prerequisites and build instructions) | ||
| 2. `build.cmd -pack -c Release` on your `roslyn` repo |
There was a problem hiding this comment.
Why change the default? I thought it's useful to get the Debug build if I don't do anything special
There was a problem hiding this comment.
My experience has been that I am most interested in knowing whether a functional break has occurred. But, there have always been debug assertion failures, which slow down the process of finding out about the functional breaks.
I do think it's useful to know about the assertion failures, but, I think it's less likely that the developer is doing the build to discover if there are new assertion failures due to some change. I think a more proactive approach will be needed in order to keep a handle on assertion failures when building the runtime libraries.
There was a problem hiding this comment.
Sounds good. Already approved. Feel free to merge
Adjusting the docs for building the runtime with local Roslyn. Attempting to improve clarity and indicate conditions when using a release mode or debug mode compiler is more preferable. @jcouv for review.