Where other build systems are high-level languages, Ninja aims to be an assembler. - The Ninja build system / Comparison to Make

see also

• The Success and Failure of Ninja / HN - review ninja core design choice
• Samourai - an alternative to ninja

Ninja

Some explicit non-goals:

• convenient syntax for writing build files by hand. You should generate your ninja files using another program. This is how we can sidestep many policy decisions.
• built-in rules. Out of the box, Ninja has no rules for e.g. compiling C code.
• build-time customization of the build. Options belong in the program that generates the ninja files.
• build-time decision-making ability such as conditionals or search paths. Making decisions is slow.

Ninja files are usually automatically generated, for eg:

• Meson generate build.ninja file to compile c++ project.

Tutorial / Doc

Conceptually, build statements describe the dependency graph of your project, while rule statements describe how to generate the files along a given edge of the graph. They appears in a build.ninja file.

A rule has a command and description (the description is just for humans to read so you can tell what it’s doing when it’s building your code)

rule svg2pdf
  command = inkscape $in --export-text-to-path --export-pdf=$out
  description = svg2pdf $in $out

command is required within a rule and passed to sh -c on unix. You can use all the normal shell operators, like && to chain multiple commands,

Syntax for build is build output_file: rule_name input_files.

The output goes in $out in the rule and the input goes in $in.
Here’s one using the svg2pdf rule.

build pdfs/variables.pdf: svg2pdf variables.svg

That’s it! If you put those two things in a file called build.ninja and then run ninja, ninja will run:

inkscape variables.svg --export-text-to-path --export-pdf=pdfs/variables.pdf

And then if you run it again, it won’t run anything (because it can tell that you’ve already built pdfs/variables.pdf and you’re up to date).

History

When we first started porting Chrome away from just Windows, we intended to use Scons to build Chrome on all our platforms. But early on in development I discovered that Scons, despite its admirable goals of correctness and ease of use, was quite slow — it could take 40 seconds from starting Scons before it decided to build some source…

I eventually ported our Linux build to plain Makefiles…

Build performance is a combination of many factors: the build system needs to compute what needs to be done, the compiler takes time to compile files, the linker takes time to link. Each of these can be improved;…

Makefiles got our incremental builds down to a handful (10-20) of seconds…

I thought I’d try making a very simple build system; conceptually very similar to Make, but without hardly any features. And with just some preliminary profiling I got the Chrome build startup to under one second. - Ninja, a new build system