similar to: [LLVMdev] Ninja (make replacement)

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>"? :-) Best regards, Christoph

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

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.

On Sun, Jun 17, 2012 at 7:30 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > 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 >

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!

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

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

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

Mikael, Thanks for working on. My gross comments... - Canonical URL of LLVM project is; http://llvm.org/ , not www.llvm.org. - "test-suite and cygwin" could be split out. It would be special thing. - Memory/storage requirements would be moved to "A.B Debugging". Less memory would be enough without debug build. - Python (x64 binary) is available, too. I am using. Python

Yes, sorry, the LLVM CMake documentation :-) I don't think I am duplicating a large chunk; I am continuously trying to shave off extraneous and redundant stuff off my Windows-specific document. I just managed to shave off about six lines or so because I don't like the huge introduction and explanation of what MinGW is. Now that the document covers Ninja, there's even more reason for

Mikael Lyngvig <mikael at lyngvig.org> writes: [snip] > Yes, I am quite familiar with the CMake documentation, but why are you > asking? That's not the cmake documentation, that's the LLVM cmake documentation: a short document that tries to explain everything you need to know about cmake to build LLVM. I had the impression that you were duplicating a large chunk of the info

Oh, didn't realize that there already is a semi-official build of CMake with Ninja support. I am trying it out right now and it seems very promising. So I'll change the document to use Ninja instead of "MinGW Makefiles". No need to waste energy on MinGW and MSYS Makefiles when Ninja outdoes them both. I thought people would have to build CMake themselves, something I'd

Thank you so much for your hard work! LLVM/Clang is in need of motivated Windows developers willing to put in the time to make the LLVM/Clang experience better on Windows :) Quick note on the reST: instead of using a construct like: **Notice:** If you only want to build 32-bit programs, you do **not** need to install MinGW64. Prefer to use the reStructuredText "admonitions" <

As for memory/storage, I think you want these presented as early as possible so people don't go setting up a box only to find out, half a week later, that they can never do what they intended to do (build Clang in debug mode). The reason I use 32-bit Python is that it is what you need, if you want to make a Windows buildbot slave because the Win32 bindings are needed and I don't think

On Sat, Nov 16, 2013 at 9:15 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > http://llvm.lyngvig.org/Articles/How-to-Setup-an-Arch-Linux-Buildbot-for-LLVM > Notice: You only need Ninja for the test build; none of the official LLVM builders use Ninja as far as I know. My buildbots use ninja. > Please notice that you must specify the absolute path to ninja, otherwise CMake

I would like it to always be lowered, I don't want it. On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com>wrote: > You don't have memcpy or want it to always lower it? > > -eric > > On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > Christoph, > > > > Yes, you are correct on the lifetime

Thanks for spotting those errors! Fixed. If you feel that this doc should be part of the LLVM documentation, perhaps in a revised form, just let me know. I am willing to convert it into reST and also to go through a peer review, but I simply cannot spend hundreds of hours munging about, rewriting, and retesting over and over as I am already busy on other documentation and other sub-projects.

It wouldn't take me more than an hour or two to do the format conversion. It is rather trivial, actually. Just say the word and I'm on to it like a starving bee. I guess I should get used to using the Sphinx layout; I'm simply more familiar with the format I use on my own websites. Have you guys ever considered making a less formal wiki for LLVM documentation - a place where tiny

On Sun, Nov 17, 2013 at 12:53 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Thanks for spotting those errors! Fixed. > > If you feel that this doc should be part of the LLVM documentation, > perhaps in a revised form, just let me know. I am willing to convert it > into reST and also to go through a peer review, but I simply cannot spend > hundreds of hours munging