<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:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:56.7pt 42.5pt 56.7pt 85.05pt;}
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="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Have anyone had any experience with VS native CMake integration? You don’t need to employ all the described hacks when you can just trigger Ninja build from VS itself. I’ve used CMake + Ninja from VS on a couple smaller projects without
any problems. It was very smooth. But it might not be the case for something as big and complicated as LLVM. I remember trying to use CMake project about a year ago but in the end I’ve decided to stick with .sln . I don’t recall whether there were some show
stopping bugs, if it was generally worse experience or something else. Also, the situation has probably changed for the better since then. If not, perhaps that’s something LLVM could improve from its side.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org]
<b>On Behalf Of </b>Nicolas Capens via llvm-dev<br>
<b>Sent:</b> Wednesday, October 10, 2018 17:16<br>
<b>To:</b> zturner@google.com<br>
<b>Cc:</b> llvm-dev@lists.llvm.org; cfe-dev@lists.llvm.org; lldb-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] Should we stop supporting building with Visual Studio?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hi Zachary,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android (Emulator). Most development takes place in Visual Studio, where it builds as part of the rest of the SwiftShader solution. So we care about LLVM source files compiling
successfully within Visual Studio.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Would it be reasonable to at least ensure that major releases (7.0, 8.0, etc.) build with Visual Studio? We don't care much about breakages in between releases, and the other issues you listed don't affect us much either due to using custom
solution/project files.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks for your consideration,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Nicolas Capens<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">This has been on my mind for quite some time, but recently it's been popping up more and more seeing some of the issues people have run into.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Before people get the wrong idea, let me make one thing clear. **I am not proposing we stop supporting the CMake Visual Studio generator. I am only proposing we stop supporting actually compiling with the generated project**. Yes the
distinction is important, and I'll elaborate more on why later. First though, here are some of the issues with the VS generator:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1) Using MSBuild is slower than Ninja.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) Unless you remember to pass -Thost=x64 on the command line, you won't be able to successfully build. We can (and have) updated the documentation to indicate this, but it's not intuitive and still bites people because for some reason
this is not the default.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:#212121">3) Even if you do pass -Thost=x64 to CMake, it will apparently still fail sometimes. See this thread for details: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_cfe-2Ddev_2018-2DOctober_059609.html&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=vPuaNrzhkslLUCf7x4H7aU8nS2ikPK2qjbgroDOP-nM&s=St9hLhS5w07cXg4vWEp_FdukmJgBC7EFgvJWUBC--6s&e=" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html</a>.
It seems the parallel build scheduler does not do a good job and can bring a machine down. This is not the first time though, every couple of months there's a thread about how building or running tests from within VS doesn't work.</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">4) Supporting it is a continuous source of errors and mistakes when writing tests. The VS generator outputs a project which can build Debug / Release with a single project. This means that `CMAKE_BUILD_TYPE=Debug` is a no-op on this generator.
The reason this matters for the test suite is because `${CMAKE_CURRENT_BINARY_DIR}` isn't sufficient to identify the location of the binaries. You need `<span style="font-size:10.0pt;color:#212121">${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}` instead.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">There is a continuous source of problems in our CMake [1, 2, 3, 4, 5]. It also affects tests, and every time someone adds a new lit site configuration, they have to remember to add this magic block of code:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:#212121"># Support substitution of the tools_dir with user parameters. This is</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121"># used when we can't determine the tool dir at configuration time.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">try:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121"> config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121"> config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">except KeyError:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121"> e = sys.exc_info()[1]</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121"> key, = e.args</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121"> lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % (key,key))</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">to the file (even though only about 2 people actually understand what this does), which has caused problems several times.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">5) VSCode and Visual Studio both support opening CMake projects directly now, which bypasses MSBuild. I don't know how well Visual Studio supports LLVM's CMake, but the last time I tried it with VSCode on Linux
it worked fine.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">----<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">I mentioned earlier that the distinction between not *building* with a VS-generated project and not supporting the VS generator is important.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">I don't want to speak for everyone, but I believe that *most* people use the VS generator because they want IDE support for their projects. They want to be able to browse code, hit F5 to debug, F9 to set breakpoints,
etc. They don't necessarily care that Ctrl+Shift+B is how the code is generated versus some other incantation. I'm asserting that it's possible to still have all the things people actually want from the VS generator without actually building from inside
of VS. In fact, I've been doing this for several years. The workflow is:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">1) Run CMake twice, generating to separate output directories. Once using -G "Visual Studio 15 2017" and once using -G Ninja, each to different directories.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">2) Open the VS one. You have full IDE support.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">3) Instead of hitting Ctrl+Shift+B to build, have a command prompt window open and type ninja. Wait for it to complete. If you want to you can make a custom tool command in Visual Studio so that you can access
this from a keyboard shortcut.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">4) When you want to debug, set your startup project (as you normally would), right click and hit properties, go to Debugging, change Command from $(TargetPath) to <type the full path to bin/foo.exe of the program
you want to debug>.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">5) Hit F5.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">In short, with only 2 simple additional steps (run CMake an extra time, and type a path into a window), people can have the exact workflow they are used to, plus faster builds, minus all of the problems and complexities
associated with building from within VS.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">And we can simplify our CMake logic and lit configuration files as well.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">----</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:#212121"><br>
[1] - <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D43096&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=vPuaNrzhkslLUCf7x4H7aU8nS2ikPK2qjbgroDOP-nM&s=K1WR3WJM8sVBja_2q4oATeYsvnE6evI9AaWOjRsffXA&e=" target="_blank">https://reviews.llvm.org/D43096</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">[2] - <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D46642&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=vPuaNrzhkslLUCf7x4H7aU8nS2ikPK2qjbgroDOP-nM&s=WhN9-3TMktr71sGvBAhjYubw3IFFA5Iqn-mebFxOR-g&e=" target="_blank">https://reviews.llvm.org/D46642</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">[3] - <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D45918&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=vPuaNrzhkslLUCf7x4H7aU8nS2ikPK2qjbgroDOP-nM&s=l-zWEIFIEf5gYqfknJ4q072C7eTSr3MzXzkBeVbUlIg&e=" target="_blank">https://reviews.llvm.org/D45918</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">[4] - <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D45333&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=vPuaNrzhkslLUCf7x4H7aU8nS2ikPK2qjbgroDOP-nM&s=vMYozkIGbTXknMzPd-OyGwbO4CO5sZ4uKvDfoRONdkQ&e=" target="_blank">https://reviews.llvm.org/D45333</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">[5] - <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D46334&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=vPuaNrzhkslLUCf7x4H7aU8nS2ikPK2qjbgroDOP-nM&s=gM1McgMb8P97yKAR2x_0wBZHDDwoEH2FeA0LsKaCBRw&e=" target="_blank">https://reviews.llvm.org/D46334</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=vPuaNrzhkslLUCf7x4H7aU8nS2ikPK2qjbgroDOP-nM&s=DnL2VFRMSkSNqttrH8neiAw8yx6ZLwrB4woPj5mj8Sw&e=" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>