I built my first submission with Visual Studio, but everything I read and watch suggests Ninja, about which I know nothing. Is it okay if I rerun CMake with -G "Ninja" in the same build directory, then just run ninja?
Maybe? I'd usually delete my whole build directory (or create another)
if I were switching that aspect - not sure if they'd effectively be
able to reuse each others artefacts or would get in the way, etc.
Ninja is really good, indeed. The only problem I’ve seen is that LLVM linking step (made massively parallel by Ninja) renders the 8GB RAM system unresponsive due to excessive swapping.
You can reconfigure CMake to use Ninja in an existing build folder, but it will not use the binaries previously built with another tool. Moreover, generated files may clash in an incompatible way, so it’s rather better to cleanup the old build.
Kind regards,
- Dmitry.
сб, 8 авг. 2020 г. в 23:12, Paul C. Anagnostopoulos via llvm-dev <llvm-dev@lists.llvm.org>:
I will delete the build directory and start fresh. Thanks!
Ninja is really good, indeed. The only problem I've seen is that LLVM linking step (made massively parallel by Ninja) renders the 8GB RAM system unresponsive due to excessive swapping.
FWIW, there is a way to limit the number of parallel link jobs in
particular (so compile jobs can still have more parallelism). I don't
recall exactly what it is - I guess some CMake variable.
ninja -hprints help output. Many of Ninja’s flags intentionally match those of Make; e.gninja -C build -j 20changes into thebuilddirectory and runs 20 build commands in parallel.
Neil Nelson
You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs.
Cool, thanks!
вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek@chromium.org>:
You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs.
IMO, a more thorough solution would be switching to LLD (the gold linker might work few years ago, but now even gold will take me nearly 16GB of RAM), usually LLD won’t take you more than 4GB
-Min
Hm, I think this should already be lld, as long as this is on Mac with a “stock” clang toolchain.
вс, 9 авг. 2020 г. в 01:02, Min-Yih Hsu <minyihh@uci.edu>:
Sigh. I ask for your indulgence yet again.
I installed Ninja and deleted my old build tree. When I run CMake now, I'm told that it can't find the compilers and assembler. So, of course, I need to put a compiler toolset on my path. I tried MinGW but was instantly reminded that it doesn't have localtime_s. So I tried to find the Visual Studio binaries and located four different directories. I added what I thought was the correct one to my path. CMake found the compiler, but it failed to compile CMake's test.
Is anyone running Ninja with Visual Studio who might have a suggestion? I can't find anything in "Building LLVM with CMake." I've attached the CMake output below.
Hans Wennborg <hans@chromium.org> provides Windows 32bit and 64bit binaries for the releases.
Sigh. I ask for your indulgence yet again.
I installed Ninja and deleted my old build tree. When I run CMake now, I'm told that it can't find the compilers and assembler. So, of course, I need to put a compiler toolset on my path. I tried MinGW but was instantly reminded that it doesn't have localtime_s. So I tried to find the Visual Studio binaries and located four different directories. I added what I thought was the correct one to my path. CMake found the compiler, but it failed to compile CMake's test.
I /think/ you're probably best using a Visual Studio shell - I /think/
you want to use a command prompt like this:
that sets up everything right in the PATH.
lld does not support Mac system really, on a Mac you’re using the Apple Linker ld64.
In general though with 8 GB you likely want to limit your build to 4 threads (ninja -j 4) anyway.
You are correct, sir. Everything works much better if I run CMake and Ninja from a "developer command prompt." I displayed the path and almost fell off my chair laughing. The road to hell is paved with environment variable entries.
Two questions.
1. Building with Visual Studio created build/release/bin. Building with Ninja created build/bin (no release directory). Does that make sense? (I have -DCMAKE_BUILD_TYPE=Release on the cmake command.)
2. The first build attempt failed because the existing TableGen Language Reference has multiple instances of the production 'SimpleValue', which produces warnings from Sphinx. I fixed that by adding -DSPHINX_WARNINGS_AS_ERRORS:BOOL=OFF to the cmake command. Does the official build do that, too? I searched all the CMakeLists files but didn't find any use of that option.
You are correct, sir. Everything works much better if I run CMake and Ninja from a "developer command prompt." I displayed the path and almost fell off my chair laughing. The road to hell is paved with environment variable entries.
Two questions.
1. Building with Visual Studio created build/release/bin. Building with Ninja created build/bin (no release directory). Does that make sense? (I have -DCMAKE_BUILD_TYPE=Release on the cmake command.)
sounds plausible to me that different build systems may require or
prefer different layouts - though I have no specific knowledge
2. The first build attempt failed because the existing TableGen Language Reference has multiple instances of the production 'SimpleValue', which produces warnings from Sphinx. I fixed that by adding -DSPHINX_WARNINGS_AS_ERRORS:BOOL=OFF to the cmake command. Does the official build do that, too? I searched all the CMakeLists files but didn't find any use of that option.
Not sure. I guess some buildbots probably build with it on/I've
certainly seen some folks commit follow-up/cleanup patches to try to
keep the Sphinx warning-clean.
I ran into the same issue (on Ubuntu) and already filed an issue:
https://bugs.llvm.org/show_bug.cgi?id=47062
Yes. CMake's Visual Studio generators are multiconfig, which means that you specify the build type (Release vs Debug etc) when _building_. Ninja, by default, is single-config (i.e. you specify build type when _configuring_ with CMake).
You can check your generator via CMake's GENERETOR_IS_MULTICONFIG (GENERATOR_IS_MULTI_CONFIG — CMake 3.18.6 Documentation). Also, recently CMake added support for multi-config builds for Ninja: Ninja Multi-Config — CMake 3.18.6 Documentation
-Andrzej
I have separate build directories Ninja Debug and Ninja Release and another “build” directory for Visual Studio.
I build in a Ninja directory. I never build in Visual Studio. My Visual Studio directory is exclusively for project and solution files to make navigating through the code work well in the IDE.
To debug in Visual Studio, I open the project properties for the executable I want to debug and point at the appropriate executable in one of the Ninja directories. Occasionally, it’s worth regenerating the VS projects and solutions to account for new, moved, and removed files. But then you have to remember to update the project properties again.
I have a stupid batch file that lets me (re)create any of my build directories and runs Cmake with the appropriate generators.
A “Visual Studio command prompt” is just a normal command prompt that has executed vcvarsall.bat. That batch file adds a ridiculous number of things to PATH and other environment variables–almost certainly more than is necessary–but I haven’t bothered to figure which bits can be eliminated. I made two shortcuts for launching command prompts that set up their environment (which includes calling vcvarsall.bat) for one particular type of build.
So my general pattern is to browse and edit in Visual Studio, save all, run ninja in one of my customized command prompts, debug in Visual Studio, repeat. I have yet another command prompt set up for git.
There are probably lots of ways to handle LLVM on Windows with Visual Studio. Some of those may be better than mine, but mine has worked well for me for a while.