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

[Chris Bieneman via llvm-dev]

I think the question is, what is the benefit of not supporting Visual Studio. Because Zachary’s workflow is valid and working today regardless of whether or not the build system supports building with Visual Studio.

It is also worth noting that the title of the thread is a bit misleading, because not supporting Visual Studio also means not supporting Xcode, and as I pointed out I’m pretty sure we would always need some degree of build support (up through header generation) to get some IDE features working correctly.

It seems to me that there have been enough dissenting voices to Zachary’s proposal that we can probably close this discussion and continue supporting IDE builds.

-Chris

> On Oct 12, 2018, at 11:00 AM, Alexandre Ganea via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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> 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 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181012/a5790b21/attachment.html>