similar to: [LLVMdev] 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!

Wow, this is seriously fast on Windows! I've been using Ninja on Linux/Mac for awhile now, I'm glad to see it working on Windows now. On Wed, Jun 13, 2012 at 5:09 PM, =?utf-8?Q?=C3=93scar_Fuentes?= < ofv at wanadoo.es> wrote: > Nikola Smiljanic <popizdeh at gmail.com> writes: > > > Could somebody please provide more info. What exactly is ninja (I'm > >

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

"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

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

I am building with MinGW and my experience is that "make -jN" either doesn't work (because of problems with different processes updating the same library using ranlib or something like that). And then there's the issue I mentioned in the previous doc. I think Ninja is a gift from some heavenly dimension. Others may disagree. But I think any Windows developer should take a

It is with great sadness that I must tell everyone CMake’s Ninja generator is non-deterministic (https://public.kitware.com/Bug/view.php?id=15968 <https://public.kitware.com/Bug/view.php?id=15968>). I’m not sure if this impacts all versions of CMake, but it certainly impacts all the recent releases. You might ask why this matters? Sadly the non-determinism *does* impact determinism in the

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.

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?

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

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.,

Hi Christoph, It is a good question even though it is obvious :-) No, for the last few days, I have not been able to build Clang with make -j2 or -j4 - the build always fails on a ranlib operation. Also, on Windows, GNU Make seems to be somewhat broken with respect to parallel builds: It doesn't change a thing whether you specify -j2 or -j4 on a quad-core machine (with hyper-threading

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

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

So I manage to get clang's colored output through ninja simply by force (CMAKE_CXX_FLAGS=-fcolor-diagnostics), which isn't ideal (if I were to pipe ninja's output to a file it'd still have color escapes, etc) but it works. But I haven't found a similar solution for FileCheck & I'm wondering has anyone already solved this problem for themselves - if so, how? if not,

Hello there, on a CentOS 6 box, in the need for `meson`, I've installed rh-python36 using yum, then meson and ninja using `pip3.6 install meson ninja`. Later at run-time, while building atk 2.29.1: $ meson --prefix /opt/atk _build $ ninja-build -C _build FAILED: atk/atkmarshal.c /opt/gimp-2.8/bin/glib-genmarshal --prefix atk_marshal --output atk/atkmarshal.c --body ../atk/atkmarshal.list

Hi, The docs state that you can do a "make update" to update all top-level and embedded projects from Subversion. This does not appear to work with Ninja. Ninja just reports the following error: ninja: ERROR: unknown target 'update' FYI. Perhaps somebody is already looking into integrating Ninja better intp the build process. Or, perhaps I am just a too early adopter

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

On Wed, Feb 6, 2013 at 2:53 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 6 February 2013 22:13, Arnaud de Grandmaison <arnaud.adegm at gmail.com> > wrote: >> >> I think we just need to increase coverage. Everything you can do to build >> (even slightly) differently than other bots is good to have. > > > Hi Arnaud, > > I agree building

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 [[[