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

Wed Oct 10 07:33:57 PDT 2018

So IIUC this all 1 big solution, one component of which is LLVM? How do you
get them all together in 1 big solution?
On Wed, Oct 10, 2018 at 7:16 AM Nicolas Capens <nicolas.capens at gmail.com>
wrote:

> Hi Zachary,
>
> We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android
> (Emulator). Most development takes place in Visual Studio, where it builds
> as part of the rest of the SwiftShader solution. So we care about LLVM
> source files compiling successfully within Visual Studio.
>
> Would it be reasonable to at least ensure that major releases (7.0, 8.0,
> etc.) build with Visual Studio? We don't care much about breakages in
> between releases, and the other issues you listed don't affect us much
> either due to using custom solution/project files.
>
> Thanks for your consideration,
> Nicolas Capens
>
> On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via llvm-dev <
> llvm-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
>>
>>
>> _______________________________________________
>> 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/llvm-dev/attachments/20181010/cf8d5017/attachment.html>