Ninja, a small build system with a focus on speed
martine.github.com
Ninja, a small build system with a focus on speed
1–10 of 36 posts
Re: Ninja, a small build system with a focus on speed
#2How is this better than http://industriousone.com/premake ?
Re: Ninja, a small build system with a focus on speed
#3How is this better than http://industriousone.com/premake ?
Wrong question; they're working on different levels of abstraction. Ninja is designed to be a very fast and lightweight tool for doing work based on a dependency graph: actually knowing how to build anything on its own is an explicit non-goal.
Premake, on the other hand is a full-blown build system that can make decisions and knows about how to perform specific code-related tasks, and can then generate rules for other tools to follow. Unless I'm mistaken, Premake could hypothetically output a build.ninja file.
Re: Ninja, a small build system with a focus on speed
#4How is this better than http://industriousone.com/premake ?
It seems to be faster (starts building faster) and gives progress information make lacks. See http://neugierig.org/software/chromium/notes/2011/02/ninja.h... (for motivation) and https://plus.google.com/108996039294665965197/posts/SfhrFAhR... (for benchmarks). TLDR: Firefox takes 14m to fully build with make and a nop build takes 57.9s, Chrome takes 30m with ninja, but a nop build takes only 0.74s.
Re: Ninja, a small build system with a focus on speed
#5How is this better than http://industriousone.com/premake ?
I don't know the design goals of premake but ninja is very very fast at deciding what to build (a no-op build of a large project that might take a traditional make system several seconds, is almost instantaneous with ninja, allegedly).
For those already using CMake--ninja will slot right in.
Are there any large projects using premake? Ninja+gyp is used by Chromium.
Re: Ninja, a small build system with a focus on speed
#6I use tup: http://gittup.org/tup/ but I'd like to hear from the author of Ninja what his opinion is on tup.
Re: Ninja, a small build system with a focus on speed
#7Bravo! Granted, it's yet another make replacement the world really doesn't need. But that said, and unlike all the other attemps, this actually seems to be better than make.
Almost always, these things are junk (Ant, I'm looking at you) which at best implement a subset of make's features in a "pure" way (and thus look good to people who don't understand make but like Java-or-whatever).
This one actually seems to understand what make needs (cleaner variable semantics, multiple outputs for a target) and what parts need to be tossed (all the default rules).
I'm impressed. But I still won't likely use it. The world doesn't need it.
Re: Ninja, a small build system with a focus on speed
#8Ninja is mostly encoding agnostic, as long as the bytes Ninja cares about (like slashes in paths) are ASCII. This means e.g. UTF-8 or ISO-8859-1 input files ought to work.
I was going to say that this is brittle because UTF-8 multi-byte sequences might contain bytes such as 0x2F (forward slash) without actually encoding a slash... but it turns out that's wrong. All bytes in multi-byte sequences always have the high bit set, so you can look for ASCII-7 characters in UTF-8 strings without having to worry about getting false positives. That's a very useful property of UTF-8 I wasn't (consciously) aware of before.
Re: Ninja, a small build system with a focus on speed
#9Bravo! Granted, it's yet another make replacement the world really doesn't need . But that said, and unlike all the other attemps, this actually seems to be better than make. Almost always, these things are junk (Ant, I'm looking at you) which at best implement a subset of make's features in a "pure" way (and thus look good to people who don't understand make but like Java-or-whatever). This one actually seems to und…
yet another make replacement the world really doesn't need
Re: Ninja, a small build system with a focus on speed
#10Anyone has an idea of how this compares to apenwarr's implementation of djb's "redo" concept?
Compared to make, redo is extremely simple, yet more versatile, more robust - and potentially very efficient. djb only released the spec (not working code). apenwarr implemented it in Python, which means it's a lot slower than it could be (which you'd mostly feel on nop builds).