Making Ninja the only supported CMake Generator on Windows

[jkoritzinsky]

As part of improving performance of local and CI builds, we've enabled using Ninja instead of MSBuild for building CoreCLR as well as the .NET Libraries and .NET Hosts native assets as an optional flag and enabled it in CI.

During the .NET 6 time frame, we plan to move to using Ninja exclusively on Windows and removing the MSBuild generator support from our native build scripts. This will enable a faster build by default, will remove the current confusion in our build scripts where we use two different MSBuild installations during our native builds (.NET CLI MSBuild for the initial build from the root build scripts, Visual Studio MSBuild for the native build), and will enable us to not have our minimum CMake version on Windows dictated by which Visual Studio tools version we use to compile. We'll do this in multiple phases, where generally each phase requires the phases before it to be complete and the last phase requires all of the previous phases to be complete.

• Enable Ninja for the Cross OS DAC builds in CI
• Make Ninja the default generator on Windows. (Requires infrastructure rollout)
  • We'll continue to protect the MSBuild support in CI to ensure we don't horribly break it.
  • MSBuild will still be the recommended generator for editing in VS.
• Enable developing CoreCLR, native libraries, and native hosts with the Visual Studio CMake support.
• Remove the MSBuild support from our build scripts. (Requires infrastructure rollout)

[ghost]

Tagging subscribers to this area: @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

Description:	As part of improving performance of local and CI builds, we've enabled using Ninja instead of MSBuild for building CoreCLR as well as the .NET Libraries and .NET Hosts native assets as an optional flag and enabled it in CI. During the .NET 6 time frame, we plan to move to using Ninja exclusively on Windows and removing the MSBuild generator support from our native build scripts. This will enable a faster build by default, will remove the current confusion in our build scripts where we use two different MSBuild installations during our native builds (.NET CLI MSBuild for the initial build from the root build scripts, Visual Studio MSBuild for the native build), and will enable us to not have our minimum CMake version on Windows dictated by which Visual Studio tools version we use to compile. We'll do this in multiple phases, where generally each phase requires the phases before it to be complete and the last phase requires all of the previous phases to be complete. Enable Ninja for the Cross OS DAC builds in CI Make Ninja the default generator on Windows. (Requires infrastructure rollout) We'll continue to protect the MSBuild support in CI to ensure we don't horribly break it. MSBuild will still be the recommended generator for editing in VS. Enable developing CoreCLR, native libraries, and native hosts with the Visual Studio CMake support. Remove the MSBuild support from our build scripts. (Requires infrastructure rollout)
Author:	jkoritzinsky
Assignees:	-
Labels:	Bottom Up Work, User Story, area-Infrastructure
Milestone:	[object Object]

[ViktorHofer]

@danmosemsft Jeremy labeled this runtime specific infra issue as a "User Story". As we discussed offline, I assume we should not do this for net6 as we are only customer deliverables in the tree?

[danmoseley]

Personally I wouldn't but perhaps @jeffschwMSFT has different guidance? They have Team Epic as an option.

[jkoritzinsky]

According to the last time I talked with Jeff, Runtime was moving from Team Epic to User Story + Bottom Up Work for unparented stories so it doesn't show up on the https://themesof.net page.

[jkoritzinsky]

Looks like Bottom Up Work does show up on the page (there's an option to track it). Let's get some guidance from @jeffschwMSFT for what I should do here.

[danmoseley]

My thinking was that we didn't (yet?) have an ambition for this tree to turn into tracking all our work (although I suspect in future that might be interesting) so in my mind it was just for work contributing to customer visible user stories - I didn't want to ask folks to do lots of wiring up if they already got what they needed from project boards. But I don't have a strong opinion and if it means we can all simplify by eliminating Team Epic then that sounds like a fine thing.

[jeffschwMSFT]

User Story + Bottom Up is our new Team Epic

[danmoseley]

OK, sounds good to me. @ViktorHofer feel free to put infra stuff in the tree labeled as such if you feel it is valuable to you and the infra crew.

[janvorli]

While I am fine with making Ninja the default build engine for native projects on Windows, I don't like removal of support for the msbuild project generator. The generated projects are a very easy way to debug native runtime using visual studio, see what defines / compiler options are set for a specific project using a nice UI, navigating code with the code browser seeing precisely the macro definitions set for the given build, etc.
What is the reason for dropping the msbuild project generator? Is it the fact that to ensure it keeps working we would need to have a lab test using this project generator?

[jkoritzinsky]

We'd only remove the MSBuild generator once we have equivalent development support with the Ninja generator (for example with the CMake for VS support).

If we drop support for the MSBuild scripts, it simplifies our build scripts and ensures that we don't have to bump our minimum CMake version unnecessarily just to get the generator for a new Visual Studio. With the Ninja generator, we can move to a new VS version without having to make significant changes in the build and in build prereqs.

[ViktorHofer]

@jkoritzinsky would it make sense to assign yourself to the issue?

[lateralusX]

We have a couple of downstream repros that depends on Visual Studio SDK's that currently needs the Visual Studio cmake generator with custom cmake toolchains. Only supporting ninja cmake generator would probably cause issue for parts of the native runtime builds (mono, native libs, nativeaot) that targets SDK's like https://learn.microsoft.com/en-us/gaming/gdk/_content/gc/tools-console/gc-tools-toc. Keeping the Visual Studio cmake generator will probably simplify the runtime build targeting SDK's that primarily uses Visual Studio template projects + msbuild with limited or no support for alternative cmake generators like ninja, above is just one example.