ninja
Build software projects quickly
TLDR
Build in the current directory
Build in the current directory, executing 4 jobs at a time in parallel
Build a program in a given directory
Show targets (e.g. install and uninstall)
Display help
SYNOPSIS
ninja [options] [targets]
PARAMETERS
-C DIR
Change to DIR before doing anything else. Useful for running Ninja from a different directory than where the build files are located.
-f FILE
Specify the input build file. Defaults to build.ninja in the current directory.
-j N
Run N jobs (commands) in parallel. By default, Ninja determines the optimal number based on available CPU cores. Use 0 for unlimited jobs.
-k N
Keep going until N jobs fail. A value of 0 means keep going forever, ignoring failures until all possible targets are built or attempted.
-t TOOL [args]
Run a subtool. Common tools include clean (to remove build outputs), query (to inspect dependencies), and graph (to visualize the build graph).
-v
Show all command lines run during the build process, making the output more verbose.
-d DEBUG_FLAGS
Enable specific debugging flags for diagnostics, such as explain (to understand why a target is being rebuilt) or deps (to see dependency information).
--version
Print the Ninja build system version.
-h, --help
Display a help message with command-line options.
DESCRIPTION
Ninja is a small, fast build system designed for speed, particularly in large, complex software projects. Unlike traditional build systems like GNU Make, Ninja focuses solely on executing build steps as quickly as possible. It achieves this by using a very simple, low-level build file format (build.ninja) that describes dependencies and commands in a straightforward, declarative way. Ninja is not intended to be used directly by developers to write build rules; instead, it is typically used as a backend for "meta-build systems" like CMake or Meson, which generate the build.ninja files. This separation allows the higher-level system to manage project configuration and platform specifics, while Ninja handles the efficient execution of the actual compilation and linking tasks. Its primary goal is to minimize the time spent in the build system itself during incremental builds, making development cycles faster and more efficient.
CAVEATS
Ninja is primarily a build executor, not a build generator. It expects its low-level build files (build.ninja) to be generated by a higher-level build system like CMake or Meson. Therefore, it's not typically used for writing build rules from scratch, and its own build file format is intentionally simplistic, lacking the scripting capabilities found in tools like GNU Make.
META-BUILD SYSTEM RELATIONSHIP
Ninja is often considered a backend build system. This means it doesn't offer high-level features for configuring projects across different platforms or managing complex build logic. Instead, it relies on front-end "meta-build systems" like CMake or Meson to translate a project's high-level description into the simple, fast-to-parse build.ninja files. This separation of concerns allows developers to use powerful, abstract configuration tools while leveraging Ninja's raw speed for the actual compilation and linking.
SIMPLICITY OF <I>BUILD.NINJA</I>
The build.ninja file format is deliberately simple, lacking features like conditionals, loops, or complex scripting capabilities. This simplicity is a core design choice that enables Ninja to parse build files extremely quickly and efficiently determine what needs to be rebuilt. It focuses purely on defining rules (commands) and builds (inputs, outputs, and the rule to apply), making it highly optimized for machine generation and execution.
HISTORY
Ninja was developed by Evan Martin at Google, primarily to address the increasingly slow build times encountered by the Chromium project, which had grown to an immense size. Traditional build systems like Make were struggling with the scale and complexity, leading to long incremental build cycles. Ninja was designed from the ground up to be incredibly fast, focusing solely on efficient dependency tracking and parallel execution. It was first released in 2011 and quickly gained traction in large-scale software development environments where build efficiency is paramount.