Hacker News Reader

Comment by ajross | Hacker News Reader

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

View on HN

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)

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?

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.

Speaking as somebody who works on a reasonably large project,yes, the world needs it.

Null build [^1] with cold cache & make: 40s Null build with cold cache & ninja: 12s Null build with hot cache & make: 20s Null build with hot cache & ninja: < 1s

Ninja saves me 20 seconds every single time I build something. Let's say I kick off about 30-40 builds a day, that's 10-15 minutes each day.

[^1]: I.e. nothing changed

Are your make and ninja configurations 1:1? Note that a null build on the kernel (larger than most "reasonably large" projects) is well under 20 seconds.

Both generated from the same gyp files, yes. And by "reasonably large", I mean about 9.5MLOC, 30K source files excluding headers :)

Edit: Important info here might be that those times are for an OSX build. I haven't measured, but it seems builds on Linux are faster.

Have you ever considered tup? http://gittup.org/tup seems like it is going to be as fast as ninja, without sacrificing anything. (No project where a null make takes more than 0.1 secs myself, so I can't really tell)

> multiple outputs for a target

I just had to figure out how to do this today with GNU make. It was something like this:

  %Parser.c %Parser.h %Lexer.c %Lexer.h %.tokens: %.g
      antlr $<

With the object files required by the main project. Worked like a charm and solved the problem of running antlr multiple times for the produced files during a parallel build.

I'm not sure I completely followed your example, but note that the straightforward syntax for multiple outputs from Make does the wrong thing. Here's a discussion of how to make it do what you really want.

http://www.gnu.org/software/automake/manual/html_node/Multip...

Look at the last paragraph of the linked site:

For completeness it should be noted that GNU make is able to express rules with multiple output files using pattern rules

The problem with this approach (aside from the fact that it's specific to GNU make) is that you need a shared (non-empty) stem in all output files; however, the following workaround appears to work:

    foo bar baz : % : .dummy/../%
    %/../foo %/../bar %/../baz : quux
    	@sleep 2
    	touch foo bar baz

    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.

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.

Reply on news.ycombinator.com