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

[Zachary Turner via lldb-dev]

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.  In fact, LLDB
maintains its own hand-created Xcode project precisely because the CMake
one is considered "unusable".  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.


>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20181008/e5595f3a/attachment-0001.html>