similar to: [LLVMdev] [cfe-dev] Ninja build available for Visual Studio users

A tiny question (I hardly know what Ninja is, but am looking forward to trying it out): Does the changes also work with MinGW builds? I've got a Windows buildbot slave that does nothing but building LLVM+Clang using MinGW64 all day, every day. Or, is it only for Visual Studio? 2012/6/13 Justin Holewinski <justin.holewinski at gmail.com> > Wow, this is seriously fast on Windows!

Building LLVM with Visual Studio is a bit of a pain because the available methods are slow and doesn't make good use of multiprocessor systems. >From now on it is possible to build LLVM+Clang with the usual cmake method but using Ninja, an ultra-fast tool that knows how to take advantage of the availabe execution threads. Ultra-fast is no exageration: with a warm cache, a no-op build of

Hi, Ninja is being mentioned more and more frequently on this list, but I don't think anybody has introduced it formally. Ninja is, briefly put, a super-fast replacement for GNU Make, nmake, and all the other make tools out there. For those of you who are a bit reluctant to waste time on Ninja or don't know what it is, I can strongly urge you to download it from

Hi, I was trying Ninja to build the LLVM sources. I am using cmake version 2.8.8, latest ninja from git and latest LLVM from git. Here's what I tried: $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=... /path/to/src $ ninja $ ninja install The installation aborted with the message below: CMake Error at utils/TableGen/cmake_install.cmake:36 (FILE): file INSTALL cannot

Christoph Erhardt <christoph at sicherha.de> writes: > Hi Mikael, > >> My Clang build used to take 59:29 minutes using MinGW Makefiles. With >> Ninja, it takes 18:43 minutes! That's a speed up of factor three. > sorry for asking the obvious question: Are you comparing against a > parallel "make -j<n>"? :-) I'm pretty sure he isn't.

"Sahasrabuddhe, Sameer" <Sameer.Sahasrabuddhe at amd.com> writes: > I was trying Ninja to build the LLVM sources. I am using cmake version > 2.8.8, latest ninja from git and latest LLVM from git. As cmake and ninja development is not coordinated, it is not a good idea to mix versions of them separated by several months. Nor is a good idea to use a development version of

Just posted this fix on ninja's github page, but figured I'd share it with a larger audience. Every time I run cmake && ninja in a new build directory, ninja will rerun cmake because the entry for build.ninja in .ninja_log is older than the timestamp on CMakeCache.txt, even if the timestamps on the actual file isn't older. The following patch fixes the problem, i.e.,

Nope. An easy solution (both here and for clang) is for ninja to set an environment variable (`NINJA_ISATTY`?), and add some magic to LLVM's "isatty" to return true if it sees it. (for matters of correctness, it would actually be best if ninja sets the environment variable only when *it's* stdout/stderr isatty (also taking into account this environment variable), so that

On Sat, Aug 8, 2020 at 2:22 PM Dmitry Mikushin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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

You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs. On Sat, Aug 8, 2020 at 3:00 PM Neil Nelson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > https://ninja-build.org/manual.html > > ninja -h prints help output. Many of Ninja’s flags intentionally match > those of Make; e.g ninja -C build -j 20 changes into the build directory >

This afternoon I did a clean build of llvm using ninja and MSVC 2015 on Windows 10. I saw something curious and wondered if any of the ninja or CMake experts out there can explain/fix it. [2663/3121] Linking CXX shared library bin\LTO.dll Creating library lib\LTO.dll and object lib\LTO.exp Creating library lib\LTO.dll and object lib\LTO.exp [3120/3121] Running the LLVM regression tests [[[

(resend to the list) And of course, just as I say that, my next ninja build shows the line only once. On reflection I am less sure that the lack of a [N/M] line means they are from the same invocation. Surely ninja could spawn two links, which then independently report "Creating library" after ninja emits the [N/M] lines. --paulr From: llvm-dev [mailto:llvm-dev-bounces at

Since there's no "[2663/3121] " line between the two messages, the two lines are from the same link.exe invocation. I don't know why link.exe thinks it needs to print this line twice, ninja doesn't have anything to do with it. On Mon, Nov 19, 2018 at 6:57 PM <paul.robinson at sony.com> wrote: > I'm more concerned about seeing the message come out twice, which

> On Aug 8, 2020, at 3:32 PM, Dmitry Mikushin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Cool, thanks! > > вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek at chromium.org <mailto:phosek at 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

On further thought, I assume this issue actually hits everyone - it's not just Ninja getting in the way, but lit as well. (which also means we'd probably need to fix both Ninja and lit to resolve this issue - but everyone should at least be a little invested in fixing lit). On Sun, Jan 6, 2013 at 12:18 AM, Sean Silva <silvas at purdue.edu> wrote: > Nope. An easy solution (both

Do you still see this if you use lld-link for linking? The "corrupt obj file" is something we saw on chrome's bots every now and then before we switched to lld. On Mon, Nov 19, 2018 at 5:27 PM Zachary Turner <zturner at google.com> wrote: > +Nico Weber <thakis at google.com> > > On Mon, Nov 19, 2018 at 12:25 PM via llvm-dev <llvm-dev at lists.llvm.org>

This is useful for developer who uses multicore builder. https://cmake.org/cmake/help/v3.9/release/3.9.html#other-changes - The Ninja <https://cmake.org/cmake/help/v3.9/generator/Ninja.html#generator:Ninja> generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on

Folks, I am using a two-stagesimple build like this one: make -G Ninja -DCLANG_ENABLE_BOOTSTRAP=ON ../src ninja stage2-check-all Stage 1 gets built, and when looking at rules.ninja in the stage2-bins I see: rule CXX_COMPILER_AnalysisTests depfile = $DEP_FILE deps = gcc command = <stage1 build dir>./bin/clang++ $DEFINES $INCLUDES $FLAGS -MMD -MT $out -MF $DEP_FILE -o $out -c $in

On Fri, Jul 21, 2017 at 1:16 AM Reid Kleckner <rnk at google.com> wrote: > This is great news! Do we know who contributed the changes to cut the > extra library dependencies? > > Do you think we should remove ENABLE_OBJLIB to simplify our CMake files in > the near future? It seems to me that anyone who cares about highly parallel > build throughput can upgrade CMake to get

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?