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?
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