|0.2.7||Jul 12, 2018|
|0.2.6||Mar 12, 2018|
|0.2.5||Jan 30, 2018|
|0.2.2||Oct 25, 2017|
|0.1.0||Dec 16, 2016|
#8 in Build Utils
290 downloads per month
Sccache is a ccache-like tool. It is used as a compiler wrapper and avoids compilation when possible, storing a cache in a remote storage using the Amazon Simple Cloud Storage Service (S3) API, the Google Cloud Storage (GCS) API, or Redis.
Sccache now includes experimental Rust support.
It works as a client-server. The client spawns a server if one is not running already, and sends the wrapped command line as a request to the server, which then does the work and returns stdout/stderr for the job. The client-server model allows the server to be more efficient in its handling of the remote storage.
Sccache can also be used with local storage instead of remote.
- Build Requirements
- Storage Options
- Interaction with GNU
- Known Caveats
Sccache is a Rust program. Building it requires
cargo (and thus
rustc). sccache currently requires Rust 1.27.
We recommend you install Rust via Rustup. The generated binaries can be built so that they are very portable. By default
sccache supports a local disk cache. To build
sccache with support for
Redis cache backends, add
--features=all or select a specific feature by passing
redis. Refer the Cargo Documentation for details.
$ cargo build [--features=all|redis|s3|gcs] [--release]
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 steps below before building with
You will need to download and build OpenSSL with
-fPIC in order to statically link against it.
./config -fPIC --prefix=/usr/local --openssldir=/usr/local/ssl make make install export OPENSSL_LIB_DIR=/usr/local/lib export OPENSSL_INCLUDE_DIR=/usr/local/include export OPENSSL_STATIC=yes
cargo and use
ldd to check that the resulting binary does not depend on OpenSSL anymore.
Just setting the below environment variable will enable static linking.
cargo and use
otool -L to check that the resulting binary does not depend on OpenSSL anymore.
On Windows it is fairly straight forward to just ship the required
libssl DLLs with
sccache.exe, but 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.
[target.x86_64-pc-windows-msvc] rustflags = ["-Ctarget-feature=+crt-static"]
cargo and use
dumpbin /dependents to check that the resulting binary does not depend on MSVC CRT DLLs anymore.
In order to statically link against both the CRT and OpenSSL, you will need to build OpenSSL with a statically linked CRT, which is left as an exercise for the reader. Generally it is simpler to just ship the OpenSSL DLLs.
$ cargo install
Running sccache is like running ccache: wrap your compilation commands with it, like so:
$ sccache gcc -o foo.o -c foo.c
or use it with rust, like so:
$ RUSTC_WRAPPER=[path to sccache] cargo build
Sccache (tries to) support gcc, clang and MSVC. If you don't specify otherwise, sccache will use a local disk cache.
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 terminate after 10 minutes of inactivity.
sccache --show-stats will print a summary of cache statistics.
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/sccache on OS X.
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 and 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_REDIS to a Redis url in format
redis://[:<passwd>@]<hostname>[:port][/<db>] to store the cache in a Redis instance.
SCCACHE_MEMCACHED to a Memcached url in format
tcp://<hostname>:<port> ... to store the cache in a Memcached instance.
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, set
SCCACHE_GCS_KEY_PATH to the location of your JSON service account credentials.
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
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, so only on the first run.
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
RUST_LOG environment variable, the format of which is described in more detail in the env_logger documentation.
Alternately, you can set the
SCCACHE_ERROR_LOG environment variable to a path and set
RUST_LOG to get the server process to redirect its logging there (including the output of unhandled panics, since the server sets
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.
(and possible future improvements)
- Sccache doesn't try to be smart about the command line arguments it uses when computing a key for a given compilation result (like skipping preprocessor-specific arguments)
- It doesn't support all kinds of compiler flags, and is certainly broken with a few of them. Really only the flags used during Firefox builds have been tested.
- It doesn't support ccache's direct mode.
- It doesn't support an option like
- unix daemonize 0.2.3
- windows kernel32-sys 0.2.2
- windows mio-named-pipes 0.1
- unix tokio-uds 0.1
- windows winapi 0.2
- atty 0.2.6
- base64 0.9.0
- bincode 0.9
- byteorder 1.0
- clap 2.23.0
- directories 0.8.4
- env_logger 0.4
- error-chain 0.11
- filetime 0.1
- futures 0.1.11
- futures-cpupool 0.1
- jobserver 0.1
- lazy_static 1.0.0
- libc 0.2.10
- local-encoding 0.2.0
- log 0.3.6
- lru-disk-cache 0.2.0
- native-tls 0.1
- num_cpus 1.0
- number_prefix 0.2.5
- regex 0.2
- retry 0.4.0
- ring 0.12.1
- serde 1.0
- serde_derive 1.0
- serde_json 1.0
- strip-ansi-escapes 0.1
- tempdir 0.3.4
- tempfile 2.1.5
- time 0.1.35
- tokio-core 0.1.6
- tokio-io 0.1
- tokio-process 0.1
- tokio-proto 0.1
- tokio-serde-bincode 0.1
- tokio-service 0.1
- tokio-tls 0.1
- which 1.0
- zip =0.2.3
- azure? gcs? s3 chrono 0.3
- azure? gcs? s3 hyper 0.11
- azure? gcs? s3 hyper-tls 0.1
- gcs? jsonwebtoken 4.0
- memcached? memcached-rs 0.1
- gcs? openssl 0.9
- all? all-windows? redis 0.8.0
- azure? s3 rust-crypto 0.2.36
- gcs? url 1.0