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

Sun Oct 7 20:32:28 PDT 2018

Can we just create a CMAKE variable (eg. LLVM_USE_NINJA_BUILD) that's set
to ON by default, but allow users to turn it OFF at their discretion?

I do know that VS2017 supports CMAKE build integration through Ninja.

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.  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.
>
> ----
>
>
> [1] - https://reviews.llvm.org/D43096
> [2] - https://reviews.llvm.org/D46642
> [3] - https://reviews.llvm.org/D45918
> [4] - https://reviews.llvm.org/D45333
> [5] - https://reviews.llvm.org/D46334
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181007/2616c192/attachment.html>