Skip to content
rninja

← back home · compare

rninja vs sccache

// Compiler-call wrapper cache

sccache and rninja overlap on outcome — fewer compiler runs — but operate at different layers. sccache wraps the compiler call and caches what that one process produced. rninja caches whole ninja actions, which means it can also skip the wrapper invocation entirely. They can also coexist: rninja runs the action; sccache handles the cc compile inside it.

Feature rninja sccache Advantage
Cache scope Whole ninja action (compile, link, codegen) Single compiler invocation rninja
Driver requirement Anything that emits build.ninja Anything that shells a supported compiler sccache
cargo / make builds Not in scope Supported sccache
Skipping a graph edge entirely Yes (action-level hit) No (still invokes the wrapper) rninja
Remote storage async-nng endpoint S3, Redis, GCS, memcached, Azure sccache
Scheduler improvements tokio async executor Out of scope (depends on caller) rninja
Can be combined Yes — sccache inside an rninja action Yes — sccache called by rninja comparable
Drop-in for ninja Yes No (wraps compiler, not build tool) rninja
License MIT Apache-2.0 comparable

// pick rninja when

  • Your build is already driven by ninja (or any tool that emits build.ninja)
  • You want a single executor-layer cache rather than per-compiler wrappers
  • You want to skip whole graph edges, not just the compiler half of them
  • You want the scheduling improvements as well, not only caching

// pick sccache when

  • You drive builds with cargo, make, or another tool that does not produce build.ninja
  • You only need to cache rustc or cc and not other action types in your graph
  • You already operate an sccache S3/Redis backend and the integration is settled
  • You want a single cache that follows the compiler across multiple build systems

Still deciding?

The cheapest experiment is the side-by-side: time sccache target vs time rninja target on your real repo. Numbers settle the argument faster than marketing pages.