[llvm-dev] Should we stop supporting building with Visual Studio?

[Alexandre Ganea via llvm-dev]

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

De : Michael Spencer <bigcheesegs at gmail.com>
Envoyé : 11 octobre 2018 18:18
À : Alexandre Ganea <alexandre.ganea at ubisoft.com>
Cc : LLVMDev <llvm-dev at lists.llvm.org>
Objet : Re: [llvm-dev] Should we stop supporting building with Visual Studio?


On Wed, Oct 10, 2018 at 9:04 AM Alexandre Ganea via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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.

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

What benefit would this give us?

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181012/164a9aaf/attachment.html>