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

[Zachary Turner via cfe-dev]

I don't think we should drop support for VS as a generator entirely,
because having the IDE to browse code, Intellisense, and launch the
debugger is a huge value add that I don't think anyone (including myself)
would be willing to give up.

For #3 this is true, although if it makes a difference just changing the
active configuration from Debug to Release inside of VS is something that
takes several minutes (or at least it did the last time I tried, which
admittedly was a long time ago).  Anyway, your point still stands, which is
that generating the ninja won't necessarily be faster than generating VS if
you have to generate multiple times.

Since I'm the only one I can think of currently using this workflow that
I've suggested, I'd be interested in seeing if some of the other VS users
could try it out and offer their thoughts.  I personally think that once
people get used to it they would never want to go back, but acknowledge
that it can be a hurdle to untrain the memory muscle.

On Mon, Oct 8, 2018 at 10:13 AM Stella Stamenova <stilis at microsoft.com>
wrote:

> We are also currently using VS for building on Windows. Having spent the
> last few months working with Cmake on both Windows and Linux, I think no
> one on our team would be considerably inconvenienced to switch to using
> ninja on Windows as we already do that on Linux. Having said that, if our
> only workflow was on Windows with VS, it would not be trivial to make the
> switch, so if the decision is to stop support VS for building, part of that
> work will have to be to have clear documentation on how to move from a VS
> build to a ninja build, so that anyone who is not familiar with ninja and
> the difference between the generators would have a place to start.
>
>
>
> That aside, I have a couple of other concerns with the proposed change.
>
>    1. If we support VS as a generator at all, people will expect it to
>    also build and that will probably cause just as many if not more
>    inconveniencies than the current problems with VS as a build tool. I think
>    that if the decision is to drop support for building through VS, then it
>    would be cleaner to stop supporting VS as a generator entirely. This would
>    probably imply to any other generators that support multiple configurations
>    such as Xcode.
>    2. We’d have to drop support for VS as a generator for all projects –
>    llvm, clang, lld, lldb, compiler-rt, etc. I assume that’s what you’re
>    proposing, but I want to make sure. All the projects will probably need
>    their Cmake files not only cleaned up of any xcode/vs related changes, but
>    will need a warning added that these are not supported in case someone
>    tries to build just a subset.
>    3. Anyone who is currently using the VS project to build multiple
>    configurations will end up having to run cmake with ninja multiple times to
>    get any configurations they build (e.g. release and debug). So it doesn’t
>    matter if the cmake generator with ninja is faster than VS on a single run
>    – we have to assume people will have to run it (at least) twice to
>    re-create their current configuration setup.
>
>
>
> That’s not to say that we shouldn’t drop support for VS, but we’ll have to
> make sure that dropping the support actually improves the experience
> instead of making it more complicated for the majority of people who use VS
> to build today.
>
>
>
> Thanks,
>
> -Stella
>
>
>
> *From:* lldb-dev <lldb-dev-bounces at lists.llvm.org> *On Behalf Of *Zachary
> Turner via lldb-dev
> *Sent:* Monday, October 8, 2018 7:45 AM
> *To:* Aaron Ballman <aaron at aaronballman.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev <cfe-dev at lists.llvm.org>;
> LLDB Dev <lldb-dev at lists.llvm.org>
> *Subject:* Re: [lldb-dev] [cfe-dev] Should we stop supporting building
> with Visual Studio?
>
>
>
> Yes i listed 5 steps, but 2 of them (#2 and #5) are exactly what you
> already do.
>
> #1 I only actually do every couple of weeks, which is an improvement over
> building inside VS. when you build inside vs you have to close and reopen
> the solution every time you sync, which is really slow. You don’t actually
> have to regenerate the ide solution unless you need to edit a file that was
> added, which is rare. I’ve gone several months without regenerating the vs
> solution.
>
> #3 is not *that* much different than what we already do. 6 of one, half
> dozen of another.
>
> #4 is the only real diff, if you build from the ide this just works, with
> this workflow there’s 1 extra step. But you only really have to do it the
> first time.
>
> On Mon, Oct 8, 2018 at 7:35 AM Aaron Ballman <aaron at aaronballman.com>
> wrote:
>
> On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > 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.
> >
> > 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:
> >
> > 1) Using MSBuild is slower than Ninja.
> > 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.
> > 3) Even if you do pass -Thost=x64 to CMake, it will apparently still
> fail sometimes.  See this thread for details:
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fcfe-dev%2F2018-October%2F059609.html&data=02%7C01%7CSTILIS%40microsoft.com%7Cd0b09715f08a4f50bf5808d62d2cbe5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636746067541481899&sdata=7u0X3tZVg%2Fb5nwUFaLRx216GlTkinOzz8dc1AjrY9n8%3D&reserved=0>.
> 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.
> > 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
> `${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}` instead.
> >
> > 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:
> >
> > # Support substitution of the tools_dir with user parameters. This is
> > # used when we can't determine the tool dir at configuration time.
> > try:
> >     config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
> >     config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
> > except KeyError:
> >     e = sys.exc_info()[1]
> >     key, = e.args
> >     lit_config.fatal("unable to find %r parameter, use
> '--param=%s=VALUE'" % (key,key))
> >
> > to the file (even though only about 2 people actually understand what
> this does), which has caused problems several times.
> >
> > 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.
> >
> > ----
> >
> > I mentioned earlier that the distinction between not *building* with a
> VS-generated project and not supporting the VS generator is important.
> >
> > 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:
> >
> > 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.
> >
> > 2) Open the VS one.  You have full IDE support.
> >
> > 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.
> >
> > 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>.
> >
> > 5) Hit F5.
> >
> > 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.
> >
> > And we can simplify our CMake logic and lit configuration files as well.
>
> As someone who almost exclusively uses MSVC and not Ninja on Windows,
> I'll have to try this workflow out to see how it works for me in
> practice. Unfortunately, I won't really be able to test it for a few
> weeks.
>
> However, I'm concerned by the idea that we want to drop support for
> building with the standard workflow in a toolchain that's as popular
> as MSVC is. "Here's a simple five-step process to make this
> plausible", while technically feasible, does not sound like a better
> user experience for people trying to get into LLVM development on
> Windows. It's also hard for me to foresee what pain points the
> research teams at my company will have from such a transition (they
> have out-of-tree workflows that have worked fine for them for years
> and this transition will incur expenses to update scripts, etc).
>
> Based on your statements about simplifying cmake, I'm reading "stop
> supporting" as "prevent entirely; do not accept patches retaining that
> support". Is that accurate? If so, what timeline do you envision and
> what kind of transition story is there, especially for out-of-tree
> folks?
>
> ~Aaron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181008/cdebad78/attachment.html>