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

Ninja: A simple way to do builds

jvns.ca

Post reply on HN
Print view View original

11–20 of 92 posts

Re: Ninja: A simple way to do builds

#11

Post by grive »

I've only worked on one project (https://www.dpdk.org/) using meson+ninja. Overall it seems to be an improvement, barring the make idiosyncrasies that needs to be forgotten.

That being said, if the project had used make properly from the beginning (i.e. avoid recursive calls), it would not have been plagued by such latency for incremental builds. But then, make should not have made it so easy to fall for such mistake.

I'm still not a fan of having two steps (meson + ninja), but I guess it's always needed for multi-platform projects.

I'm wondering if there is a make rewrite project that tried to make the recursive make antipattern less painful? Maybe trying to recognize sub-calls and avoid creating a sub-process? I guess it would take creating a small internal shell with only make as a builtin command...

Re: Ninja: A simple way to do builds

#12

Post by inglor »

I don't know I did a few things in Chromium and admittedly it's a really big project BUT ninja and autoninja get really cryptic and complex pretty fast.

To be fair it's better than make or the older gyp setup BUT for non trivial workloads ninja is pretty fast but leaves a lot to be desired in terms of DX.

Re: Ninja: A simple way to do builds

#13

Post by chrismorgan »

For comparison, here’s a makefile for the trivial example (though you’ll have to fix the indentation):

  all: $(patsubst ${things_to_convert},%.svg,%.pdf)

  %.pdf: %.svg
      inkscape $
${things_to_convert} is left undefined, as in the source article. It might be something like $(wildcard [STAR].svg) or $(shell find src -name '[STAR].svg'). [Turn each [STAR] into *; HN formatting idiosyncrasies are in play.]

I like makefiles in substantial part because there’s a very high probability of Make already being installed. I’m comfortable enough with them that I didn’t need to look anything up to write any of what I wrote above. It’s a bit of a pity about the sigils; though would people really find $first_prerequisite and $target better than $< and $@? No idea. Ninja uses $in and $out, but it’s simpler in a way that lets it reasonably get away with that. Make, on the other hand, is complex in a way that is pretty powerful if you know what you’re doing, but generally more manual (e.g. Ninja looks like it tracks dependencies roughly automatically, whereas dependencies are manual in Make, as many have found to their sorrow) and it makes it fairly easy to shoot yourself in the foot if you do the wrong thing, which is easy to do if you’re not expert, which not many are.

Re: Ninja: A simple way to do builds

#14

Post by desine »

I've been compiling some libraries and projects on my raspberry pi, and I've been having to invoke meson and ninja quite a bit. If nothing else, they've been getting it right on the first try more often than the cmake && make projects. That may be biased though, with newer/more active projects using newer build systems supporting newer hardware.

Anyways, it's been enough that I'm looking into it, but still working (hacking? copy/pasting?) in make

Re: Ninja: A simple way to do builds

#15

Post by jorams »

hinkley wrote: post #10

> for filename in things_to_convert: Undeclared variables and random indentation levels. Is it safe to assume these examples are abridged? Or is it a case of magic?

Since the comment above that line says this:

> # some for loop with every file I need to build

It's safe to say that it's not a complete example. That said, the indentation levels are not random. These are multiline strings.

Re: Ninja: A simple way to do builds

#16

Post by bla3 »

AtlasBarfed wrote: post #7
flohofwoe wrote: post #5

Earlier quoted context omitted.

Ninja hasn't been created for small one-liners like in this blog post, but for massive C++ builds with tens- or hundreds-of-thousands of source files arranged in a complex dependency tree. Figuring out quickly what needs to be rebuilt for massive builds like this isn't trivial, but that's essentially the one important thing that ninja does. Also see: https://ninja-build.org/manual.html#_design_goals

... What mechanism is used to perform incremental builds? It is referenced in the article and unexplained from what I can tell. What enables "quickly" for you to determine what needs to be built? Make simply compares timestamps I believe. ... What mechanisms/tricks speed up builds? Or is it just the "simplicity" that is the BFD? Edit: It sure would have been helpful if somewhere was stated: "the build system of Chrom…

http://www.aosabook.org/en/posa/ninja.html is a book chapter in why ninja is fast.

Re: Ninja: A simple way to do builds

#17

Post by patrec »

chrismorgan wrote: post #13

For comparison, here’s a makefile for the trivial example (though you’ll have to fix the indentation): all: $(patsubst ${things_to_convert},%.svg,%.pdf) %.pdf: %.svg inkscape $ ${things_to_convert} is left undefined, as in the source article. It might be something like $(wildcard [STAR].svg) or $(shell find src -name '[STAR].svg'). [Turn each [STAR] into *; HN formatting idiosyncrasies are in play.] I like makefiles…

You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them wherever I go.

Make is everywhere, but apart from UX issues such as the dumb syntax or the different flavors you'll encounter, the fundamental problem with it is that it just can't build things properly (the existence of make clean is the dead give away here). That's fine for trivial stuff, but for real work you really owe it to yourself (and society at large) to use a build system which can correctly build things.

Some examples applying to the above:

- if your paths have white space in them, you are generally fucked

- if your change your Makefile, nothing will be rebuilt

- if inkscape writes out a partial file because full disk and you fix the problem, the partial svg will no be rebuilt

- if you install a new version of inkscape nothing will be rebuilt

Re: Ninja: A simple way to do builds

#19

Post by dan00 »

patrec wrote: post #17
chrismorgan wrote: post #13

For comparison, here’s a makefile for the trivial example (though you’ll have to fix the indentation): all: $(patsubst ${things_to_convert},%.svg,%.pdf) %.pdf: %.svg inkscape $ ${things_to_convert} is left undefined, as in the source article. It might be something like $(wildcard [STAR].svg) or $(shell find src -name '[STAR].svg'). [Turn each [STAR] into *; HN formatting idiosyncrasies are in play.] I like makefiles…

You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them wherever I go. Make is everywhere, but apart from UX issues such as the dumb syntax or the different flavors you'll encounter, the fundamental problem with it is that it just can't build things properly (the existence of make clean is the dead give away here). That's…

> - if your paths have white space in them, you are generally fucked

Paths containing ':' are also fun. That make doesn't handle paths - and most likely other things - as a unit, but just substitutes their string representation into the makefile, is just asking for trouble.

Re: Ninja: A simple way to do builds

#20

Post by jhasse »

grive wrote: post #11

I've only worked on one project ( https://www.dpdk.org/ ) using meson+ninja. Overall it seems to be an improvement, barring the make idiosyncrasies that needs to be forgotten. That being said, if the project had used make properly from the beginning (i.e. avoid recursive calls), it would not have been plagued by such latency for incremental builds. But then, make should not have made it so easy to fall for such mista…

There are other things in make that could be improved. If your rewrite fixes those, too, I'm wondering why not use Ninja at that point?
Post reply on HN