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.cap...@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-...@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-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
