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

[Doug Gregor via cfe-dev]

Sent from my iPhone

> On Oct 8, 2018, at 8:09 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> 
>> On Mon, Oct 8, 2018 at 7:42 AM Greg Bedwell <gregbedwell at gmail.com> wrote:
>> Thanks for raising this.
>> 
>> This is a topic I've been interested in for a while too, as I've had to do a few of those lite.site.cfg fix-ups that you mention (in fact I have one sitting unreviewed at https://reviews.llvm.org/D40522 although I've not pinged it in a long time so I'll need to double check that it's still an issue).  There are also other issues.  For example LLVM_ENABLE_ABI_BREAKING_CHECKS is implemented in such a way that by default the value is defined at CMake time based on the value of LLVM_ENABLE_ASSERTIONS which gets confusing with the Visual Studio generator where the value of LLVM_ENABLE_ASSERTIONS does not necessarily correspond to whether assertions are enabled or not.
>> 
>> As I understand it, what you're proposing is to not support building for any configs that return true for GENERATOR_IS_MULTI_CONFIG.  This includes all of the Visual Studio generators, but also the Xcode generator.  I'm not an Xcode user. Does anyone make use of that generator or is it entirely replaced in practice by single-config generators, i.e. Ninja?
> I haven't heard of anyone using the Xcode generated project. 

I’ve been using the Xcode generated project on a daily basis for several years. 

> In fact, LLDB maintains its own hand-created Xcode project precisely because the CMake one is considered "unusable". 

I don’t know where this “unusable” comment came from. My impression is that nobody really tried the generated Xcode project: LLDB had its own hand-maintained Xcode project for a long time, and the CMake build system came later. Workflows didn’t necessarily change when they could have. 

> That said, I don't personally use Xcode or a Mac, so I can't speak for if anyone else might be using the Xcode generator.

There are certainly other users. The Swift Compiler’s build script explicitly supports setting up a usable Xcode project because we recommend it for a decent build/debut experience in the Mac. 

I am strongly against removing support for building within Xcode, because it is my primary development workflow and having a skeleton project + make would be a huge regression. 

  - Doug

>  
>> 
>> We're still using the Visual Studio generators in production at Sony at the moment.  This is largely because until recently they were actually faster than Ninja for us due to the availability of distributed builds on our network.  We've recently patched in support for our system into our private branch of Ninja now so in theory it should be faster/on-par again but we've not yet pulled the trigger on making them the default.  If there's consensus that this is the way forward, then we'll definitely need some time to make the change internally.  I'm only speaking personally in this reply as I'll need to discuss with the rest of the team before we can reach a position, but basically I wouldn't want the conclusion of this thread to be "No dissenting voices, so here's an immediate patch to remove support!"
> There's a patch up right now to add support for /MP.  https://reviews.llvm.org/D52193.  In theory this should also help unless you have your own distributed build system.  I'm curious what was actually faster though.  I've found hitting Ctrl+Shift+B from within Visual Studio to be much slower, but it seems like a lot of that time is going to MSBuild resolving dependencies and stuff.  Like it sometimes takes over 30 seconds before it even starts doing *anything*.
>  
>> 
>> I've not tried the workflow you describe.  I'll try it out in the coming days to see how it works for me.  My main concerns are:
>> 
>> * How far will it raise the barrier of entry to new developers?  My impression is that a lot of students coming to LLVM for the first time, first build out of the box with Visual Studio before later discovering this magical thing called Ninja that will speed things up.  Potentially this could be mitigated with good enough documentation in the getting started guide I expect.
> There's a couple of ways we can mitigate this.  We can print a warning when using the VS generator, and we can update the getting started guide.  But I'm not sure it will raise the barrier of entry much, if at all.  Right now new developers are struggling with building and running even with VS.  Every couple of weeks there's posts about how the test suite wouldn't run, or something is running out of heap space, or they forgot to use -Thost=x64.  
>  
>> 
>> * LLVM's CMake is super-slow on Windows, and we'd need to run it twice whenever there are project changes.  This could be a significant drawback in the proposed workflow but I'll need to try it before I can say that for sure.
> I mentioned this in my response to Aaron, but just to re-iterate here, you only ever need to run CMake on the VS project if you actually want to edit a file that has been added, which is pretty rare.  I have gone several months without re-generating and it works fine.  This is actually a big improvement over the VS-generator-only workflow.  FWIW, my experience is that the Ninja generator is at least twice as fast as the CMake generator.
>  
> _______________________________________________
> 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/cfe-dev/attachments/20181010/5c11dd67/attachment.html>