Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ninja, a small build system with a focus on speed

martine.github.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Ninja, a small build system with a focus on speed

#11

Post by ajross »

pestaa wrote: post #9
ajross wrote: post #7

Bravo! 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 Didn't it start exactly like that with CMake? Turns out, the world needed it.

cmake is a replacement for autotools, not make. It generates makefiles as output.

Re: Ninja, a small build system with a focus on speed

#12

Post by pestaa »

ajross wrote: post #11
pestaa wrote: post #9

Earlier quoted context omitted.

yet another make replacement the world really doesn't need Didn't it start exactly like that with CMake? Turns out, the world needed it.

cmake is a replacement for autotools, not make. It generates makefiles as output.

Good point, although if autotools was invented to replace makefiles by generating them, I'd argue CMake was too, even if indirectly.

Re: Ninja, a small build system with a focus on speed

#13

Post by gnok »

pestaa wrote: post #12
ajross wrote: post #11

Earlier quoted context omitted.

cmake is a replacement for autotools, not make. It generates makefiles as output.

Good point, although if autotools was invented to replace makefiles by generating them, I'd argue CMake was too, even if indirectly.

I don't quite think autotools were invented to replace Makefiles. Autoconf and friends _configure_ the build environment by discovering locations of dependencies, feature sets, available compilers and build tools and other build conditions. This information is then used to generate the appropriate Makefile.

Makefiles solve a different problem; which is of local build dependencies, looking for changes, packaging and suchlike.

CMake, as it happens, was written because Autotools were particularly ineffecient at the configuration problem. Make happens to be very efficient.

Re: Ninja, a small build system with a focus on speed

#14

Post by malkia »

Meai wrote: post #6

I use tup: http://gittup.org/tup/ but I'd like to hear from the author of Ninja what his opinion is on tup.

This always comes in three, someone mentions ninja, then comes redo, and lastly tup :)

(Saw in two places, reading mailing lists). LOL, And I'm brewing my own solution for brewing other people's solutions :)

Re: Ninja, a small build system with a focus on speed

#15

Post by zserge »

Ninja is a build system of my dream - minimalistic, clean and simple. I've tried it on some small projects about a year ago, and it seemed very fast and stable.

That days I generated .ninja with shell scripts, so now I'm happy to hear of CMake support. Still sorry that ninja build system is not included in most Linux distros, I believe that would significantly increase its popularity among developers.

Re: Ninja, a small build system with a focus on speed

#17

Post by Ralith »

Meai wrote: post #6

I use tup: http://gittup.org/tup/ but I'd like to hear from the author of Ninja what his opinion is on tup.

I also use and enjoy tup, which has the significant features of automatically constructing most of the dependency graph, and proven optimality and correctness for incremental rebuilds. Not to mention that it's highly usable standalone.

Does Ninja offer any of that? It doesn't seem to, judging from a skim of the docs.

Re: Ninja, a small build system with a focus on speed

#18

Post by emelski »

ajross wrote: post #7

Bravo! 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…

What surprises me is that nobody seems to take the approach of fixing make, as if it is somehow beyond redemption. With a little effort you could address some of the things that people most dislike about make (tabs-vs-spaces, multiple outputs per target). With a little more effort you can have up-to-date checks that don't rely solely on timestamps.

That's the direction we've taken with ElectricAccelerator ( http://www.electric-cloud.com/products/electricaccelerator-d...) -- fix make, rather than cooking up Y.A.M.R. It hasn't (yet) fixed all of the issues with make, but it's hit some of the biggest.

(disclaimer: I'm the architect of ElectricAccelerator)

Re: Ninja, a small build system with a focus on speed

#19

Post by ajross »

emelski wrote: post #18
ajross wrote: post #7

Bravo! 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…

What surprises me is that nobody seems to take the approach of fixing make, as if it is somehow beyond redemption. With a little effort you could address some of the things that people most dislike about make (tabs-vs-spaces, multiple outputs per target). With a little more effort you can have up-to-date checks that don't rely solely on timestamps. That's the direction we've taken with ElectricAccelerator ( http://ww…

I'll definitely take a look. I guess my feeling is that make, like some other tools (C++ comes to mind) happens to be Good Enough for what it does, despite its warts. Lots of new programmers get scared off by its weirdness and never really learn it.

But all you need to do is look at the Linux kernel or Android AOSP build systems (both implemented almost entirely in make) to see what it's capable of. Do we really need something better, given the friction that variant build systems cause?

Re: Ninja, a small build system with a focus on speed

#20

Post by emelski »

ajross wrote: post #19
emelski wrote: post #18

Earlier quoted context omitted.

What surprises me is that nobody seems to take the approach of fixing make, as if it is somehow beyond redemption. With a little effort you could address some of the things that people most dislike about make (tabs-vs-spaces, multiple outputs per target). With a little more effort you can have up-to-date checks that don't rely solely on timestamps. That's the direction we've taken with ElectricAccelerator ( http://ww…

I'll definitely take a look. I guess my feeling is that make, like some other tools (C++ comes to mind) happens to be Good Enough for what it does, despite its warts. Lots of new programmers get scared off by its weirdness and never really learn it. But all you need to do is look at the Linux kernel or Android AOSP build systems (both implemented almost entirely in make) to see what it's capable of. Do we really need…

That's a valid concern. One of our design goals has been 100% compatibility with GNU make, specifically to reduce that friction, so you don't have to fiddle with your makefiles to switch from gmake to ElectricMake (emake). The converse is also true -- you can switch back to gmake if you like. You lose the benefits of emake, but the makefiles still work with gmake.
Post reply on HN