<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="FR-CA" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Currently on Windows, MSBuild is slower than Ninja, and Ninja+Clang is slower is than Ninja+MSVC. Please the comments
in <a href="https://reviews.llvm.org/D52193">https://reviews.llvm.org/D52193</a> for timings.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">On the long term, the RFC above (D52193) would bring everything on par, when compiling locally at least.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Alex.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">[1]
<a href="https://docs.microsoft.com/en-us/windows/desktop/secbp/control-flow-guard">
https://docs.microsoft.com/en-us/windows/desktop/secbp/control-flow-guard</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif">De :</span></b><span lang="EN-CA" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Michael Spencer <bigcheesegs@gmail.com>
<br>
<b>Envoyé :</b> 11 octobre 2018 18:18<br>
<b>À :</b> Alexandre Ganea <alexandre.ganea@ubisoft.com><br>
<b>Cc :</b> LLVMDev <llvm-dev@lists.llvm.org><br>
<b>Objet :</b> Re: [llvm-dev] Should we stop supporting building with Visual Studio?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-CA"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-CA"><br clear="all">
<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal">On Wed, Oct 10, 2018 at 9:04 AM Alexandre Ganea via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">I'm not sure if that was mentioned, but Ninja could potentially be used inside Visual Studio with a Makefile project type [1].<br>
We're already doing this to compile with Fastbuild inside Visual Studio.<br>
<br>
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.
<br>
For example:<br>
<br>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='FastBuild Debug|x64'" Label="Configuration"><br>
<ConfigurationType>Makefile</ConfigurationType><br>
</PropertyGroup><br>
<br>
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:
<br>
<br>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='FastBuild Debug|x64'"><br>
<NMakeBuildCommandLine>ninja -C build_debug</NMakeBuildCommandLine><br>
<NMakeReBuildCommandLine> ninja -t rebuild -C build_debug</NMakeReBuildCommandLine><br>
<NMakeCleanCommandLine>ninja -t clean -C build_debug</NMakeCleanCommandLine><br>
</PropertyGroup><br>
<br>
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).
<br>
<br>
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".
<br>
<br>
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.
<br>
<br>
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.<br>
<br>
--------------------<br>
[1] <a href="https://docs.microsoft.com/en-us/cpp/ide/creating-a-makefile-project?view=vs-2017" target="_blank">
https://docs.microsoft.com/en-us/cpp/ide/creating-a-makefile-project?view=vs-2017</a>
<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What benefit would this give us? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Michael Spencer <o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>