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

Sun Oct 7 21:12:47 PDT 2018

What would the variable do?  Ninja and VS are generators, the only way to
specify them is with the -G option to cmake.  If you use the VS generator,
there's no way I'm aware of to make it use ninja instead of MSBuild when
you hit Ctrl+Shift+B.

That said, type ninja in a command prompt is not a terrible burden, but
even if it is, people can always just create a custom Tool command that
runs ninja in the specified working directory, and bind it to some keyboard
combination so the workflow is almost exactly the same as what they are
using today.

On Sun, Oct 7, 2018 at 8:32 PM Hussien Hussien <clrx01 at gmail.com> wrote:

> 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/lldb-dev/attachments/20181007/a2ea420e/attachment-0001.html>