Should we stop supporting building with Visual Studio?

I'm not sure if that was mentioned, but Ninja could potentially be used inside Visual Studio with a Makefile project type [1].
We're already doing this to compile with Fastbuild inside Visual Studio.

You generate `cmake -G"Visual Studio 15 2017 Win64" ...` in such way that, in Project Properties / General / Project Defaults, "Configuration Type" would be set to "Makefile" for all generated .vcxproj.
For example:

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='FastBuild Debug|x64'" Label="Configuration">
    <ConfigurationType>Makefile</ConfigurationType>
  </PropertyGroup>

Now a "NMake" section replaces all the previous sections in "Project Properties". This is where any batch command(s) can be called for building/rebuild/clean. In this case, we would probably use `ninja -C build_release` for example:

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='FastBuild Debug|x64'">
    <NMakeBuildCommandLine>ninja -C build_debug</NMakeBuildCommandLine>
    <NMakeReBuildCommandLine> ninja -t rebuild -C build_debug</NMakeReBuildCommandLine>
    <NMakeCleanCommandLine>ninja -t clean -C build_debug</NMakeCleanCommandLine>
  </PropertyGroup>

To avoid calling ninja many times for each vcxproj, we also disable the "Build" checkbox in the "Configuration Manager" for all projects but one (say for ALL_BUILD).

The only quirk I see would be for the NMake batch to first call `cmake -G Ninja" with the parameters initially passed to `cmake -G"Visual Studio 15 2017".

This overall scheme would retain the different targets in Visual Studio (Debug, Release, RelWithDebInfo, etc.) by passing a different CMAKE_BUILD_TYPE to the above NMake batch file.

The only thing you're loosing with this is the ability to compile as single .cpp (Ctrl-F7). However, you can get around that by installing the "Clang Power Tools" extension and bind a key for that purpose.

I’m not sure if that was mentioned, but Ninja could potentially be used inside Visual Studio with a Makefile project type [1].
We’re already doing this to compile with Fastbuild inside Visual Studio.

You generate cmake -G"Visual Studio 15 2017 Win64" ... in such way that, in Project Properties / General / Project Defaults, “Configuration Type” would be set to “Makefile” for all generated .vcxproj.
For example:

Makefile

Now a “NMake” section replaces all the previous sections in “Project Properties”. This is where any batch command(s) can be called for building/rebuild/clean. In this case, we would probably use ninja -C build_release for example:

ninja -C build_debug ninja -t rebuild -C build_debug ninja -t clean -C build_debug

To avoid calling ninja many times for each vcxproj, we also disable the “Build” checkbox in the “Configuration Manager” for all projects but one (say for ALL_BUILD).

The only quirk I see would be for the NMake batch to first call cmake -G Ninja" with the parameters initially passed to cmake -G"Visual Studio 15 2017".

This overall scheme would retain the different targets in Visual Studio (Debug, Release, RelWithDebInfo, etc.) by passing a different CMAKE_BUILD_TYPE to the above NMake batch file.

The only thing you’re loosing with this is the ability to compile as single .cpp (Ctrl-F7). However, you can get around that by installing the “Clang Power Tools” extension and bind a key for that purpose.


[1] https://docs.microsoft.com/en-us/cpp/ide/creating-a-makefile-project?view=vs-2017

What benefit would this give us?

  • Michael Spencer

As it stands today, the change proposed by Zachary would bring faster compile times (by using Ninja) inside Visual Studio, and lower OS latency/better responsivity when compiling - especially when working in a CFG-enabled [1] OS like Windows 10.

Currently on Windows, MSBuild is slower than Ninja, and Ninja+Clang is slower is than Ninja+MSVC. Please the comments in https://reviews.llvm.org/D52193 for timings.

On the long term, the RFC above (D52193) would bring everything on par, when compiling locally at least.

Alex.

[1] https://docs.microsoft.com/en-us/windows/desktop/secbp/control-flow-guard

Envoyé : 11 octobre 2018 18:18

As it stands today, the change proposed by Zachary would bring faster compile times (by using Ninja) inside Visual Studio, and lower OS latency/better responsivity when compiling - especially when working in a CFG-enabled [1] OS like Windows 10.

Currently on Windows, MSBuild is slower than Ninja, and Ninja+Clang is slower is than Ninja+MSVC. Please the comments in https://reviews.llvm.org/D52193 for timings.

On the long term, the RFC above (D52193) would bring everything on par, when compiling locally at least.

Alex.

[1] https://docs.microsoft.com/en-us/windows/desktop/secbp/control-flow-guard

Envoyé : 11 octobre 2018 18:18