sccache - Shared Compilation Cache
sccache is a ccache-like compiler caching tool. It is used as a compiler wrapper and avoids compilation when possible, storing cached results either on local disk or in one of several cloud storage backends.
sccache also provides icecream-style distributed compilation (automatic packaging of local toolchains) for all supported compilers (including Rust). The distributed compilation system includes several security features that icecream lacks such as authentication, transport layer encryption, and sandboxed compiler execution on build servers. See the distributed quickstart guide for more information.
Table of Contents (ToC)
- Build Requirements
- Storage Options
- Interaction with GNU
- Known Caveats
There are prebuilt x86-64 binaries available for Windows, Linux (a portable binary compiled against musl), and macOS on the releases page. Several package managers also include sccache packages, you can install the latest release from source using cargo, or build directly from a source checkout.
On macOS sccache can be installed via Homebrew:
brew install sccache
On Windows, sccache can be installed via scoop:
scoop install sccache
If you have a Rust toolchain installed you can install sccache using cargo. Note that this will compile sccache from source which is fairly resource-intensive. For CI purposes you should use prebuilt binary packages.
cargo install sccache
Running sccache is like running ccache: prefix your compilation commands with it, like so:
sccache gcc -o foo.o -c foo.c
If you want to use sccache for caching Rust builds you can define
build.rustc-wrapper in the cargo configuration file. For example, you can set it globally in
$HOME/.cargo/config by adding:
rustc-wrapper = "/path/to/sccache"
Note that you need to use cargo 1.40 or newer for this to work.
Alternatively you can use the environment variable
sccache supports gcc, clang, MSVC, rustc, NVCC, and Wind River's diab compiler.
If you don't specify otherwise, sccache will use a local disk cache.
sccache works using a client-server model, where the server runs locally on the same machine as the client. The client-server model allows the server to be more efficient by keeping some state in memory. The sccache command will spawn a server process if one is not already running, or you can run
sccache --start-server to start the background server process without performing any compilation.
You can run
sccache --stop-server to terminate the server. It will also terminate after (by default) 10 minutes of inactivity.
sccache --show-stats will print a summary of cache statistics.
To use sccache with cmake, provide the following command line arguments to cmake 3.4 or newer:
If you are building sccache for non-development purposes make sure you use
cargo build --release to get optimized binaries:
cargo build --release [--no-default-features --features=s3|redis|gcs|memcached|azure]
sccache builds with support for all storage backends, but individual backends may be disabled by resetting the list of features and enabling all the other backends. Refer the Cargo Documentation for details on how to select features with Cargo.
Building portable binaries
When building with the
sccache will depend on OpenSSL, which can be an annoyance if you want to distribute portable binaries. It is possible to statically link against OpenSSL using the
cargo and use
ldd to check that the resulting binary does not depend on OpenSSL anymore.
cargo and use
otool -L to check that the resulting binary does not depend on OpenSSL anymore.
On Windows, the binary might also depend on a few MSVC CRT DLLs that are not available on older Windows versions.
It is possible to statically link against the CRT using a
.cargo/config file with the following contents.
rustflags = ["-Ctarget-feature=+crt-static"]
cargo and use
dumpbin /dependents to check that the resulting binary does not depend on MSVC CRT DLLs anymore.
When statically linking with OpenSSL, you will need Perl available in your
sccache defaults to using local disk storage. You can set the
SCCACHE_DIR environment variable to change the disk cache location. By default it will use a sensible location for the current platform:
~/.cache/sccache on Linux,
%LOCALAPPDATA%\Mozilla\sccache on Windows, and
~/Library/Caches/Mozilla.sccache on MacOS.
The default cache size is 10 gigabytes. To change this, set
SCCACHE_CACHE_SIZE, for example
If you want to use S3 storage for the sccache cache, you need to set the
SCCACHE_BUCKET environment variable to the name of the S3 bucket to use.
You can use
AWS_SECRET_ACCESS_KEY to set the S3 credentials. Alternately, you can set
AWS_IAM_CREDENTIALS_URL to a URL that returns credentials in the format supported by the EC2 metadata service, and credentials will be fetched from that location as needed. In the absence of either of these options, credentials for the instance's IAM role will be fetched from the EC2 metadata service directly.
If you need to override the default endpoint you can set
SCCACHE_ENDPOINT. To connect to a minio storage for example you can set
SCCACHE_ENDPOINT=<ip>:<port>. If your endpoint requires TLS, set
You can also define a prefix that will be prepended to the keys of all cache objects created and read within the S3 bucket, effectively creating a scope. To do that use the
SCCACHE_S3_KEY_PREFIX environment variable. This can be useful when sharing a bucket with another application.
SCCACHE_REDIS to a Redis url in format
redis://[:<passwd>@]<hostname>[:port][/<db>] to store the cache in a Redis instance. Redis can be configured as a LRU (least recently used) cache with a fixed maximum cache size. Set
maxmemory-policy according to the Redis documentation. The
allkeys-lru policy which discards the least recently accessed or modified key fits well for the sccache use case.
SCCACHE_MEMCACHED to a Memcached url in format
tcp://<hostname>:<port> ... to store the cache in a Memcached instance.
Google Cloud Storage
To use Google Cloud Storage, you need to set the
SCCACHE_GCS_BUCKET environment variable to the name of the GCS bucket. If you're using authentication, either set
SCCACHE_GCS_KEY_PATH to the location of your JSON service account credentials or
SCCACHE_GCS_CREDENTIALS_URL with a URL that returns the oauth token. By default, SCCACHE on GCS will be read-only. To change this, set
SCCACHE_GCS_RW_MODE to either
To use Azure Blob Storage, you'll need your Azure connection string and an existing Blob Storage container name. Set the
SCCACHE_AZURE_CONNECTION_STRING environment variable to your connection string, and
SCCACHE_AZURE_BLOB_CONTAINER to the name of the container to use. Note that sccache will not create the container for you - you'll need to do that yourself.
Important: The environment variables are only taken into account when the server starts, i.e. only on the first run.
Overwriting the cache
In situations where the cache contains broken build artifacts, it can be necessary to overwrite the contents in the cache. That can be achieved by setting the
SCCACHE_RECACHE environment variable.
You can run the server manually in foreground mode by running
SCCACHE_START_SERVER=1 SCCACHE_NO_DAEMON=1 sccache, and send logging to stderr by setting the
SCCACHE_LOG environment variable for example
SCCACHE_LOG=debug SCCACHE_START_SERVER=1 SCCACHE_NO_DAEMON=1 sccache
Alternately, you can set the
SCCACHE_ERROR_LOG environment variable to a path and set
SCCACHE_LOG to get the server process to redirect its logging there (including the output of unhandled panics, since the server sets
SCCACHE_ERROR_LOG=/tmp/sccache_log.txt SCCACHE_LOG=debug sccache
Interaction with GNU
sccache provides support for a GNU make jobserver. When the server is started from a process that provides a jobserver, sccache will use that jobserver and provide it to any processes it spawns. (If you are running sccache from a GNU make recipe, you will need to prefix the command with
+ to get this behavior.) If the sccache server is started without a jobserver present it will create its own with the number of slots equal to the number of available CPU cores.
This is most useful when using sccache for Rust compilation, as rustc supports using a jobserver for parallel codegen, so this ensures that rustc will not overwhelm the system with codegen tasks. Cargo implements its own jobserver (see the information on
NUM_JOBS in the cargo documentation) for rustc to use, so using sccache for Rust compilation in cargo via
RUSTC_WRAPPER should do the right thing automatically.
- Absolute paths to files must match to get a cache hit. This means that even if you are using a shared cache, everyone will have to build at the same absolute path (i.e. not in
$HOME) in order to benefit each other. In Rust this includes the source for third party crates which are stored in
- Crates that invoke the system linker cannot be cached. This includes
proc-macrocrates. You may be able to improve compilation time of large
bincrates by converting them to a
libcrate with a thin
- Incrementally compiled crates cannot be cached. By default, in the debug profile Cargo will use incremental compilation for workspace members and path dependencies. You can disable incremental compilation.