[cfe-dev] [llvm-dev] Should we stop supporting building with Visual Studio?
Zachary Turner via cfe-dev
cfe-dev at lists.llvm.org
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/cfe-dev/attachments/20181010/cf8d5017/attachment.html>
More information about the cfe-dev
mailing list