sccache is ccache with cloud storage

Mozilla

Last update: Jan 2, 2023

Related tags

Caching sccache

Overview

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 includes support for caching the compilation of C/C++ code, Rust, as well as NVIDIA's CUDA using nvcc.

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)

Installation
Build Requirements
Build
Usage
Storage Options
- Local
- S3
- Redis
- Memcached
- Google Cloud Storage
- Azure
Debugging
Interaction with GNU make jobserver
Known Caveats

Installation

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.

macOS

On macOS sccache can be installed via Homebrew:

brew install sccache

Windows

On Windows, sccache can be installed via scoop:

scoop install sccache

Via cargo

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

Usage

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:

[build]
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 RUSTC_WRAPPER:

export RUSTC_WRAPPER=/path/to/sccache
cargo build

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.

Running sccache --show-stats will print a summary of cache statistics.

Some notes about using sccache with Jenkins are here.

To use sccache with cmake, provide the following command line arguments to cmake 3.4 or newer:

-DCMAKE_C_COMPILER_LAUNCHER=sccache
-DCMAKE_CXX_COMPILER_LAUNCHER=sccache

Build Requirements

sccache is a Rust program. Building it requires cargo (and thus rustc). sccache currently requires Rust 1.43.0. We recommend you install Rust via Rustup.

Build

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]

By default, 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 gcs feature, 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 openssl/vendored feature.

Linux

Build with cargo and use ldd to check that the resulting binary does not depend on OpenSSL anymore.

macOS

Build with cargo and use otool -L to check that the resulting binary does not depend on OpenSSL anymore.

Windows

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.

[target.x86_64-pc-windows-msvc]
rustflags = ["-Ctarget-feature=+crt-static"]

Build with 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 $PATH.

Storage Options

Local

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 SCCACHE_CACHE_SIZE="1G".

S3

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_ACCESS_KEY_ID and 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 SCCACHE_S3_USE_SSL=true.

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.

Redis

Set 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 and 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.

Memcached

Set 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 READ_ONLY or READ_WRITE.

Azure

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.

Debugging

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 RUST_BACKTRACE=1 internally).

SCCACHE_ERROR_LOG=/tmp/sccache_log.txt SCCACHE_LOG=debug sccache

Interaction with GNU `make` jobserver

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.

Known Caveats

General

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 $HOME/.cargo/registry/cache by default.

Rust

Crates that invoke the system linker cannot be cached. This includes bin, dylib, cdylib, and proc-macro crates. You may be able to improve compilation time of large bin crates by converting them to a lib crate with a thin bin wrapper.
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.

More details on Rust caveats

Comments

Hang when building firefox with macOS using sccache

This is a non-deterministic hang that started happening with sccache 0.2.5

What I'm seeing is N (where N is the -j value) sccache processes which are all in this status:

screen shot 2018-01-31 at 10 39 40 am

And the sccache server has these stacks:

Call graph:
    2570 Thread_16452   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2570 start  (in libdyld.dylib) + 1  [0x7fff5891b115]
    +   2570 std::rt::lang_start::he4b9f1bb696330b0  (in sccache) + 473  [0x107747159]
    +     2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +       2570 sccache::main::hec24a635d03db32a  (in sccache) + 1851  [0x1075ab48b]
    +         2570 sccache::commands::run_command::he8aa4f8f0b080801  (in sccache) + 18603  [0x10757e81b]
    +           2570 sccache::server::start_server::hc2d7ed9af3080bbd  (in sccache) + 17955  [0x1075a1123]
    +             2570 tokio_core::reactor::Core::poll::h18e3d58b9150d5db  (in sccache) + 339  [0x10770d553]
    +               2570 mio::poll::Poll::poll::h26363de19a6ecc6e  (in sccache) + 1217  [0x107714411]
    +                 2570 kevent  (in libsystem_kernel.dylib) + 10  [0x7fff58a6bec2]
    2570 Thread_16453
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16454
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16455
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16456
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16457
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16458
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16459
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16460
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16461
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16462
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16463
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16464
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16465
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16466
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16467
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16468
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16469
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16470
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 1247  [0x10771da0f]
    +               2570 std::sync::mpsc::blocking::WaitToken::wait::ha9c7a2d821477e73  (in sccache) + 48  [0x10773b0c0]
    +                 2570 std::thread::park::h8b09280e67aa921c  (in sccache) + 263  [0x10772d347]
    +                   2570 _pthread_cond_wait  (in libsystem_pthread.dylib) + 732  [0x7fff58ba7662]
    +                     2570 __psynch_cvwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6acee]
    2570 Thread_16471
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16472
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 std::sys::imp::thread::Thread::new::thread_start::h1c02b1e6c92092ab  (in sccache) + 140  [0x107745dfc]
    +         2570 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h89cc2236e47f719e  (in sccache) + 144  [0x1077216a0]
    +           2570 __rust_maybe_catch_panic  (in sccache) + 31  [0x10774deaf]
    +             2570 std::sys_common::backtrace::__rust_begin_short_backtrace::h5246b622d8fe900d  (in sccache) + 252  [0x10771d62c]
    +               2570 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff58ba4551]
    +                 2570 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff58ba6bfe]
    +                   2570 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff58a6ad1e]
    2570 Thread_16608
    + 2570 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c5d]
    +   2570 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff58ba656d]
    +     2570 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff58ba66c1]
    +       2570 SpotlightQueryThread(void*)  (in DebugSymbols) + 475  [0x7fff45304dfb]
    +         2570 CFRunLoopRun  (in CoreFoundation) + 99  [0x7fff310448f3]
    +           2570 CFRunLoopRunSpecific  (in CoreFoundation) + 483  [0x7fff31005f43]
    +             2570 __CFRunLoopRun  (in CoreFoundation) + 1783  [0x7fff310068c7]
    +               2570 __CFRunLoopServiceMachPort  (in CoreFoundation) + 341  [0x7fff31007575]
    +                 2570 mach_msg  (in libsystem_kernel.dylib) + 60  [0x7fff58a60cdc]
    +                   2570 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff58a617c2]
    2570 Thread_2923358
      2570 start_wqthread  (in libsystem_pthread.dylib) + 13  [0x7fff58ba5c4d]
        2570 _pthread_wqthread  (in libsystem_pthread.dylib) + 1035  [0x7fff58ba606a]
          2570 __workq_kernreturn  (in libsystem_kernel.dylib) + 10  [0x7fff58a6b562]

CC: @alexcrichton, Ted suggested pinging you since this looks possible jobserver related.

opened by alex 31

Windows compiler invocation opens multiple console windows
This was previously reported under #16 and supposedly fixed in this commit and again in #472 (which I presume was included in the 0.2.10 release), but the issue still persists - upon the start of a compilation process (in particular, a cargo invocation), multiple console windows pop up for a split second.

I'm encountering this with the following environment:

sccache version 0.2.11 installed through cargo (it also occured with 0.2.10 and previous versions)

Windows 10 (x64) version 10.0.18362.0

Running the cargo subcommands run, build or install, with the environment variable RUSTC_WRAPPER=sccache set and using the Rust msvc toolchain.

Please let me know if you need more information.
investigation needed
opened by Systemcluster 27
Support FreeBSD as sccache-dist server

FreeBSD support makes use of pot for sandboxing.

Implementation aimed to be minimally invasive, almost all FreeBSD specific parts happen in segregated files.

We've been using this successfully in CI for over a month now, so it appears to be stable enough to be potentially useful to others.

opened by grembo 25
Please provide a new release

#962 was merged 3 months ago and is not yet included in a release. Because of this, Mixxx CI has to build sccache from source which takes 10 minutes. It is caching the sccache binary for subsequent runs, but the first run of each branch has this 10 minute penalty. This could be avoided if we could install sccache from Chocolatey, which requires a new release.

opened by Be-ing 23
Add a Redis cache variant

This patch adds support for using a Redis instance as cache. The cache is used when SCCACHE_REDIS is set to a url that matches redis://[:<passwd>@]<hostname>[:port][/<db>]. The S3 storage options overrule Redis.

For the connection to the Redis a connection pool is used. It is managed by r2d2. The size of the connection pool can be controlled by SCCACHE_REDIS_CONNECTIONS and default to the number of cpus multiplied by 2. I'm not sure that this fallback is a good idea, but I wanted to have SCCACHE_REDIS_CONNECTIONS optional. What do you think?

The current_size method of Storage uses a lua script to sum the individual key sizes. This might not perform well on larger systems. During my tests this was not a problem for ~50k keys - but I limited the cache size to 10Gb.

Everything else is quite straight forward. Some parts are borrowed from the disk and S3 cache implementation. Thanks for that!

opened by flxo 23
Migrate to stable Future trait, async/await and Tokio 0.2 runtime
Builds on #945. Rebased and streamlined version of #946 (thanks to @Marwes and @drahnr for doing most of the work!).

This aims to be a somewhat minimal but complete upgrade to stable Future trait and async/await.

At first I tried to split the changes into respective commits but I quickly found that that e.g. migrating storages leads to reqwest upgrade, which itself causes other places to be upgraded and so on. Rather than artificially setting up boundaries, migrating everything to futures_03 and .compat() everywhere and switching them back in following commits, I figured that this should be probably reviewed as a whole. Let me know if you really prefer to have it split more granularly somehow.

Most notably:

Upgrades tokio to 0.2, which supports stable Futures.

Migrates from futures_03::executor::ThreadPool to regular tokio::runtime::Runtime. Because Tokio-enabled I/O such as tokio v0.2 child processes or timeouts all implicitly now need to be spawned in a Tokio context, rather than creating a custom executor that uses ThreadPool but polls relevant Tokio-related futures in a context of a separately running runtime, we use a single Tokio runtime everywhere configured with at least the same amount of worker threads as before and with enabled blocking feature. This is designed for I/O-bound tasks (rather than CPU-bound ones) and so it fits the existing use case perfectly since we mostly used spawn_fn for operations related to disk I/O.

Updates reqwest to 0.10 (and by extension hyper to 0.13), supporting stable Futures. That's to easily support async/await in regular mode; in distributed compilation we use Tokio runtime now so it's also easier there to use Future-enabled reqwest.

Uses async_trait crate to migrate crucial traits like Storage, Client to async/await. This could be skipped in theory but that's mean sticking Pin<Box<dyn Future<Output = XYZ> + Send + 'lifetime as a return type everywhere, since async fns in traits are not supported yet due to lack of GATs (see here)

Migrates from futures v0.1 chains to async/await whenever possible.

I tried to retain the existing semantics as much as possible and refrain from any non-trivial refactoring to ease the review and to help this land. Let me know if everything is in order and whether you want me to change anything here.
opened by Xanewok 21
Rusoto for S3 communication (with support for public buckets).

Picking up on the work of @Hugal31 in https://github.com/mozilla/sccache/pull/826 with support for s3 buckets, but now with support for public buckets as well (read only mode).

Prior to this fix, the the https://rusoto.github.io/rusoto/rusoto_credential/struct.DefaultCredentialsProvider.html called the https://rusoto.github.io/rusoto/rusoto_credential/struct.ChainProvider.html and would error out if no credentials were found.

Based on this pr https://github.com/rusoto/rusoto/pull/1566 a it seems anonymous mode is a mechanism that is appearing in Rusoto, but is not yet a supported via DefaultCredentialsProvider, or perhaps ever, so using a different S3Client constructor.

It would also be possible to build our own extension of DefaultCredentialsProvider, but an upstream builder might be a better solution.

opened by rexhoffman 21
Add -fminimize-whitespace preprocessor flag when Clang >= 14 to increase cache hits
This proof of concept tries to take advantage of the new -fminimize-whitespace preprocessor option in Clang (14.0.0, not released yet). -fminimize-whitespace was added to Clang with the intention to help increase the chance of a cache hit in tools like sccache when only whitespace changes.

To illustrate this change, here are two sample C programs that previously wouldn't trigger a cache hit before this PR, but now do (when using Clang >= 14):

#include <stdio.h> int main() { printf("Hello World!"); return 0; }

#include <stdio.h> int main() {printf("Hello World!");return 0;}

I also added some code to expose the compiler version to the preprocessor. This could be useful if version-dependent features are added to sccache in the future.

Feedback on this is definitely welcome! Note that Clang 14.0.0 is still in progress, so there is no rush to merge in this PR.
opened by InnovativeInventor 20
Improve preprocessor handling such that macros are not expanded.
Fixes #521

This surely deserves a test that checks that there will be no warnings emitted from macro expansions that should be suppressed by the additional flags. If someone provides me some guidance on how to add a test for that, I will be happy to do that.

[x] Make enabling this behaviour explicit via a sccache configuration option.
opened by sigiesec 20

Update clap to v3 1

This is my initial attempt at updating clap to v3.1 (and switching over to the Derive API for it)

I kept the same external Commands for the parsed format and just used intermediate values internally. To keep the separation cleaner this involved changing parse() to be infallible where the error displaying and exiting early is now done internally within parse()

sccache appears to be fine and tests pass with cargo test for it. sccache-dist is compiling and from a surface level check things seem to be fine, but the tests for it don't pass for me on main or this branch. This PR is marked as a draft until that gets sorted out. Below is an example of the error I get:

---- test_dist_nobuilder stdout ----
thread 'test_dist_nobuilder' panicked at 'called `Result::unwrap()` on an `Err` value: AddrParseError(())', tests/harness/mod.rs:488:42
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
LOGS == (exit status: 0) ==
> sccache_dist_test_scheduler_314eee14-4948-4e30-abf4-685adf5e766a <:
## STDOUT


## STDERR
/sccache-dist: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /sccache-dist)
/sccache-dist: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /sccache-dist)
/sccache-dist: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /sccache-dist)
/sccache-dist: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /sccache-dist)
/sccache-dist: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /sccache-dist)

====
OUTPUTS == (exit status: 1) ==
> sccache_dist_test_scheduler_314eee14-4948-4e30-abf4-685adf5e766a <:
## STDOUT


## STDERR
Error response from daemon: Cannot kill container: sccache_dist_test_scheduler_314eee14-4948-4e30-abf4-685adf5e766a: Container 3681cd393c6d9e3a7a50674313ac76356f3496b3688785250c5a5dc75a06360d is not running

====
OUTPUTS == (exit status: 0) ==
> sccache_dist_test_scheduler_314eee14-4948-4e30-abf4-685adf5e766a <:
## STDOUT
sccache_dist_test_scheduler_314eee14-4948-4e30-abf4-685adf5e766a


## STDERR

====


failures:
    test_dist_nobuilder

Also just for comparison here is a comparison of the new and old help messages

sccache old

sccache 0.2.15

USAGE:
    sccache [FLAGS] [OPTIONS] [cmd]...

FLAGS:
        --dist-auth       authenticate for distributed compilation
        --dist-status     show status of the distributed client
    -h, --help            Prints help information
    -s, --show-stats      show cache statistics
        --start-server    start background server
        --stop-server     stop background server
    -V, --version         Prints version information
    -z, --zero-stats      zero statistics counters

OPTIONS:
        --package-toolchain <executable> <out>    package toolchain for distributed compilation
        --stats-format <stats-format>
            set output format of statistics [default: text]  [possible values: text, json]


ARGS:
    <cmd>...

Enabled features:
    S3:        true
    Redis:     true
    Memcached: true
    GCS:       true
    Azure:     true

sccache new

sccache 0.2.16-alpha.0

USAGE:
    sccache [OPTIONS] [--] [CMD]...

ARGS:
    <CMD>...

OPTIONS:
        --dist-auth
            authenticate for distributed compilation

        --dist-status
            show status of the distributed client

    -h, --help
            Print help information

        --package-toolchain <PACKAGE_TOOLCHAIN> <PACKAGE_TOOLCHAIN>
            package toolchain for distributed compilation

    -s, --show-stats
            show cache statistics

        --start-server
            start background server

        --stats-format <STATS_FORMAT>
            set output format of statistics [default: text] [possible values: text, json]

        --stop-server
            stop background server

    -V, --version
            Print version information

    -z, --zero-stats
            zero statistic counters

Enabled features:
    S3:        true
    Redis:     true
    Memcached: true
    GCS:       true
    Azure:     true

sccache-dist old

sccache 0.2.15

USAGE:
    sccache-dist [SUBCOMMAND]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    auth
    help         Prints this message or the help of the given subcommand(s)
    scheduler
    server

sccache-dist new

sccache 0.2.16-alpha.0

USAGE:
    sccache-dist <SUBCOMMAND>

OPTIONS:
    -h, --help       Print help information
    -V, --version    Print version information

SUBCOMMANDS:
    auth
    help         Print this message or the help of the given subcommand(s)
    scheduler
    server

So sccache's is a bit more spaced out and has different headings. I can set custom headings for arguments to be under if we want that to match. I tried setting the output to be more compact too, but I think the line --package-toolchain may be overriding that. Other than that things are pretty much all the same aside from color with the new output and more parsing being enforced by clap instead of bubbled up by sccache

opened by LovecraftianHorror 19

Silent fails building brave on windows with sccache

Here at www.brave.com we build our product on OSX and linux with sccache support. On windows setting the env for logging to trace seems to get us no extra logging. Also it seems as though all the calls are not supported

browser-laptop-bootstrap>type npm-debug.log.2956940901 D:\browser-laptop-bootstrap>sccache -s Max cache size 10 GiB Cache size 0 bytes Cache location Local disk: "C:\\Users\\posix4e\\AppData\\Local\\Mozilla\\sccache" Compile requests 657 Compile requests executed 0 Cache hits 0 Cache misses 0 Forced recaches 0 Cache read errors 0 Cache write errors 0 Compilation failures 0 Cache errors 0 Successful compilations which could not be cached 0 Non-cacheable calls 0 Non-compilation calls 0 Unsupported compiler calls 657 Average cache write 0.000 s Average cache read miss 0.000 s Average cache read hit 0.000 s

How do i begin to debug this?

opened by posix4e 19
sccache doesn't handle "--"

https://github.com/rust-lang/cc-rs/commit/fcb8df5efa81a90115c5bc05c8c0a7c615c8afd9 added "--" to the command line emitted for clang-cl when compiling through the cc-rs crate, and sccache doesn't handle it, so it passes it to the preprocessor without considering its effect, and every argument that comes after it on the preprocessor command line is considered as a file name, which, when they are originally flags, well, don't match any actual file, and then the preprocessor fails.

opened by glandium 0
Monitor config file for changes

It'd be awesome if the local daemon process would either reload or terminate once config change is detected. That would avoid any state / behabior mismatch due to a remaining live process. https://crates.io/crates/notify could be a cross platform lib being the building block needed.
enhancement

opened by drahnr 0

GitHub Actions cache is surprisingly slow

I was excited to see the introduction of the GitHub Actions cache backend. However, when I tried it on a test branch, the results were surprisingly slow.

See the initial run at https://github.com/indygreg/apple-platform-rs/actions/runs/3723171428/jobs/6314513850. Here, a build job took ~1 hour. (It normally takes ~10m.) The Stop sccache step displays sccache server stats. This particular job shows 44 cache errors. Unsure if that is possibly the cause of problems?

I did another CI run where I cranked up logging to debug and printed the log file after the build. See e.g. https://github.com/indygreg/apple-platform-rs/actions/runs/3723354206/jobs/6314814370 for a slow build. Interestingly, some of the jobs in this run were fast! See https://github.com/indygreg/apple-platform-rs/actions/runs/3723354206/jobs/6314814955 for a fast one. Spot checking the logs, I think there is a positive correlation between the cache errors count and job time.

Poking around the logs, I see occurrences of DEBUG sccache::compiler::compiler] [aws_http]: Cache write error: Cache service responded with 429 Too Many Requests: {"$id":"1","innerException":null,"message":"Request was blocked due to exceeding usage of resource 'Count' in namespace ''.","typeName":"Microsoft.TeamFoundation.Framework.Server.RequestBlockedException, Microsoft.TeamFoundation.Framework.Server","typeKey":"RequestBlockedException","errorCode":0,"eventId":3000}. So I guess my project is too big to use GitHub Actions cache???

More worrisome though is that some of the cache writes take 10+s. e.g.

2022-12-18T05:13:25.3938134Z [2022-12-18T05:08:46Z DEBUG hyper::client::pool] reuse idle connection for ("https", artifactcache.actions.githubusercontent.com)
2022-12-18T05:13:25.3938390Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::io] flushed 2318 bytes
2022-12-18T05:13:25.3938682Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::io] parsed 18 headers
2022-12-18T05:13:25.3939035Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::conn] incoming body is chunked encoding
2022-12-18T05:13:25.3939330Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::decode] incoming chunked header: 0x3 (3 bytes)
2022-12-18T05:13:25.3939686Z [2022-12-18T05:08:46Z WARN  reqwest_retry::middleware] Retry attempt #1. Sleeping 53.097849ms before the next attempt
2022-12-18T05:13:25.3940103Z [2022-12-18T05:08:46Z DEBUG hyper::client::pool] reuse idle connection for ("https", artifactcache.actions.githubusercontent.com)
2022-12-18T05:13:25.3940353Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::io] flushed 2318 bytes
2022-12-18T05:13:25.3940598Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::io] parsed 18 headers
2022-12-18T05:13:25.3940878Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::conn] incoming body is chunked encoding
2022-12-18T05:13:25.3941175Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::decode] incoming chunked header: 0x3 (3 bytes)
2022-12-18T05:13:25.3941508Z [2022-12-18T05:08:46Z INFO  reqwest_tracing::reqwest_otel_span_builder] HTTP request; otel.status_code="ERROR"
2022-12-18T05:13:25.3941845Z [2022-12-18T05:08:46Z INFO  reqwest_tracing::reqwest_otel_span_builder] HTTP request; http.status_code=429
2022-12-18T05:13:25.3942174Z [2022-12-18T05:08:46Z INFO  reqwest_tracing::reqwest_otel_span_builder] HTTP request; http.user_agent=""
2022-12-18T05:13:25.3942478Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::decode] incoming chunked header: 0x138 (312 bytes)
2022-12-18T05:13:25.3942793Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::conn] incoming body completed
2022-12-18T05:13:25.3943218Z [2022-12-18T05:08:46Z DEBUG hyper::client::pool] pooling idle connection for ("https", artifactcache.actions.githubusercontent.com)
2022-12-18T05:13:25.3944403Z [2022-12-18T05:08:46Z DEBUG sccache::compiler::compiler] [aws_sdk_s3]: Cache write error: Cache service responded with 429 Too Many Requests: {"$id":"1","innerException":null,"message":"Request was blocked due to exceeding usage of resource 'Count' in namespace ''.","typeName":"Microsoft.TeamFoundation.Framework.Server.RequestBlockedException, Microsoft.TeamFoundation.Framework.Server","typeKey":"RequestBlockedException","errorCode":0,"eventId":3000}
2022-12-18T05:13:25.3944708Z [2022-12-18T05:08:46Z DEBUG sccache::server] [aws_sdk_s3]: Cache write finished in 21.388 s
2022-12-18T05:13:25.3945012Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::decode] incoming chunked header: 0x138 (312 bytes)
2022-12-18T05:13:25.3945338Z [2022-12-18T05:08:46Z DEBUG hyper::proto::h1::decode] incoming chunked header: 0x138 (312 bytes)

And

2022-12-18T05:13:25.3908847Z [2022-12-18T05:08:38Z DEBUG hyper::client::pool] pooling idle connection for ("https", artifactcache.actions.githubusercontent.com)
2022-12-18T05:13:25.3909181Z [2022-12-18T05:08:38Z INFO  reqwest_tracing::reqwest_otel_span_builder] HTTP request; http.status_code=204
2022-12-18T05:13:25.3909491Z [2022-12-18T05:08:38Z INFO  reqwest_tracing::reqwest_otel_span_builder] HTTP request; http.user_agent=""
2022-12-18T05:13:25.3909910Z [2022-12-18T05:08:38Z DEBUG sccache::compiler::compiler] [aws_config]: Stored in cache successfully!
2022-12-18T05:13:25.3910204Z [2022-12-18T05:08:38Z DEBUG sccache::server] [aws_config]: Cache write finished in 13.018 s
2022-12-18T05:13:25.3910535Z [2022-12-18T05:08:45Z DEBUG sccache::compiler::compiler] [aws_sdk_s3]: Compiled in 21.388 s, storing in cache
2022-12-18T05:13:25.3910931Z [2022-12-18T05:08:46Z INFO  gha_toolkit::cache] put; version="5c35548282b30b97a2314eadc6fc42b9b7585a12c4f9efa527ac2e48739babe0"
2022-12-18T05:13:25.3911660Z [2022-12-18T05:08:46Z INFO  gha_toolkit::cache] reserve; key="sccache-ubuntu-22.04-x86_64-unknown-linux-gnu-1.62.1-0300a5abb7bd36eb7e4aa0b971d5e94866c6e140" version="7c4ed3dc414c5c2d030ec00d8394e733c5dfeff8cdbae21becc2144de0bb9570" cache_size=21844888
2022-12-18T05:13:25.3912483Z [2022-12-18T05:08:46Z INFO  reqwest_tracing::reqwest_otel_span_builder] HTTP request; http.method=POST http.scheme=https http.host=artifactcache.actions.githubusercontent.com net.host.port=0 otel.kind="client" otel.name=POST /LNWNXsg1z0Qt0Mn41fuRdbA1YzcaL5Z2Wf2AYmEQiLGLuQCklb/_apis/artifactcache/caches

I'm not sure how to interpret these logs. But multi-second values for Cache write finished in seem wrong: I would expect a cache write to effectively be an HTTP request and for inserts to take dozens to hundreds of milliseconds. But maybe the GitHub Actions cache latency is just really high?

I'm unsure what actions are needed for this issue. I'm unsure if there's any code-level bugs. Maybe GitHub Actions cache is just prohibitively slow? Maybe this slowness/behavior should be documented?

opened by indygreg 15

Print warning message by `println` instead of `warn` to avoid missing

https://github.com/mozilla/sccache/blob/ad97f69c1adeb12c18eafea3a364e7708b166536/src/config.rs#L538-L545

We print warning message by warn here, which could be missed if RUST_LOG is not set or been set to ERROR. It's better to use println instead.

opened by Xuanwo 0
Tracking issues of storage connectors migration
This issue is used to track the overall progress of storage connectors migration. We expect to migrate all of them before releasing 0.4.0.

This issue will close https://github.com/mozilla/sccache/issues/1404

Tasks

[x] s3

[x] azure (azblob)

[x] gcs (wait for https://github.com/mozilla/sccache/pull/1494)

[x] ~~fs~~ (we need to port the lru cache first, should in another issue.)

[x] https://github.com/mozilla/sccache/pull/1509

[x] gha (wait for https://github.com/mozilla/sccache/pull/1528)

[ ] Memcached (wait for https://github.com/mozilla/sccache/pull/1532)
opened by Xuanwo 0