The dotnet/runtime repo is now live-live!

[jkoritzinsky]

After a few weeks of infrastructure work resulting in the merge of #494, the dotnet/runtime repository now uses live-built components between the coreclr, libraries, and installer builds. More specifically, the dotnet/runtime build now uses the results of locally building coreclr when building libraries and the results of coreclr and libraries when building installer. As a result, this will change your local workflow. When you pull down changes from the dotnet/runtime repository, we suggest that you build the project from the root build scripts in the Release configuration by running build.cmd -c Release or build.sh -c Release. This will ensure that you likely will not have to do any additional extra local builds to get started. We’ve included some guidance below for the common scenarios for various teams.

Because of the current level of control Arcade provides for configuring individual projects, the default build.sh and build.cmd scripts at the root of the repository build the entire repository in the same configuration. As a result, this workflow is likely not the most common scenario for most users. Here are some suggestions for common patterns across our teams.

CoreCLR workflow

To build the coreclr product build, your current workflow will work as expected. The tests as well as generating Core_Root now require the libraries subset category to also be built in Release. If you build the root build scripts in Release configuration as recommended, then you can build the CoreCLR tests as before. If you want to rebuild the libraries build to enable updating your Core_Root or to build CoreCLR tests against new APIs, you can run libraries.cmd -c Release or libraries.sh -c Release depending on your platform to build the updated libraries.

Libraries workflow

When working on the libraries subset, you likely don’t want to use a debug CoreCLR when testing. So, you should ensure that the CoreCLR subset you are using is a Release CoreCLR. To do so, pass /p:CoreCLRConfiguration=Release as a parameter to the libraries build script to build the libraries subset against your release build of CoreCLR.

Installer workflow

When working on the installer subset, you may want a debug or checked CoreCLR (if you work on the hosting layer), or you may want a release CoreCLR (if you work in the setup area). If you want a CoreCLR configuration that is different than your installer configuration, then pass the CoreCLRConfiguration MSBuild property to your build as the libraries workflow suggests. Additionally, if you want to use a Release version of the libraries build, you can pass the LibrariesConfiguration property in the same manner to select a Debug or Release libraries build. Due to the way that package versions are generated in the build today, building the installer subset will require the libraries subset to have been built the same day.

[davidsh]

Libraries workflow

For those devs working primarily in the libraries, you don't have to build everything with build.cmd/build.sh. I found the following workflow useful:

Windows

src\coreclr\build.cmd -release -skiptests -clang9
libraries.cmd /p:CoreCLRConfiguration=Release

Linux/Mac

src/coreclr/build.sh -release -skiptests -clang9
./libraries.sh /p:CoreCLRConfiguration=Release

[stephentoub]

Can we make libraries.cmd just default to doing that, and then allow flags to suppress/change it?

Also, libraries.cmd doesn't describe what it does. I'd personally prefer build-libraries. cmd. Or just use build.cmd -libraries, or some such thing.

[billwert]

@jkoritzinsky Has this wound up in any of the workflow docs? I didn't see it there but might have missed it.

[danmoseley]

@billwert i don't think so as I needed it, couldn't find it, and didn't know about this issue...

I will update them later this week, although I expect we will iterate a bit more to smooth this out.

[danmoseley]

src\coreclr\build.cmd -release -skiptests -clang9

MSBUILD : error MSB1001: Unknown switch.
Switch: -clang9