Skip to content
rninja

Home / Quickstart

From install to a cached build

rninja is a single binary. Install it, run it where you run ninja, and the cache warms itself. Nothing about your build.ninja or generator changes.

1 · Install

Cargo (crates.io)

cargo install rninja

npm

npm install -g rninja-cli

PyPI

pip install rninja-cli

Homebrew

brew install \
  neul-labs/tap/rninja

2 · Run it like ninja

Pass the same flags, or symlink rninja in as ninja so nothing downstream moves.

$ cmake -G Ninja -B out/Release
$ rninja -C out/Release -j8 # same flags as ninja
[1/842] Compiling src/core/arena.cc
[842/842] Linking app cache hit
$ # or drop it in transparently:
$ ln -s $(which rninja) /usr/local/bin/ninja

3 · The flags you already know

-C DIR

Change to DIR before building — same as ninja.

-j N

Run N jobs in parallel through the async scheduler.

-k N

Keep going until N jobs fail, exactly like ninja.

-n

Dry run: print what would build without running it.

-t TOOL

Subtools: clean, compdb, graph, deps, query — plus rninja’s config and stats.

-d MODE

Debug output, including -d explain for why an edge rebuilt.

4 · Share a cache across machines (optional)

Point rninja at an async-nng endpoint to let laptops and CI runners reuse each other's artifacts. Leave it unset and rninja stays local-only.

$ export RNINJA_REMOTE_URL=tcp://cache.internal:5555
$ export RNINJA_CACHE_MODE=read-write
$ rninja -C out -j$(nproc)
[cache] 812/842 actions served from remote
build complete

// see the CI warm-cache use case for a full pipeline.

That's the whole loop.

Curious how the cache decides what is reusable? Read how it works, or see the FAQ.