We (https://github.com/scylladb/scylladb/) are using a ninja-based build system for C++ and Rust code, and using sccache for caching the compilations. Most developers do not use a remote compilation or caching setup - the cache is local and compilations are run on the same machine.
Our developers working interactively are facing an annoying problem: When we interrupt "ninja" with control-C, ninja is killed immediately, but all the ongoing compilations continue to run to completion, in the background. These compilations sometimes linger for several minutes (!), continuing to hog the machine's CPU and memory long after the user interrupted them.
The reason for this problem is sscache's server architecture: An sscache invoked by ninja may connect to some sscache server started earlier and run the build there. A control-C will never reach that other process group, and won't kill the build. Even no server exists, a new one will be started but by default will be run in a separate process group (SCCACHE_NO_DAEMON=1 can be used to avoid that).
It is hard for me to believe that we're the only people who are having this problem, and I wonder if anyone solved it somehow.
I wanted to suggest a command-line option (or environment variable) that simply doesn't use a build server at all - each "sccache" invocation would just work separately (just sharing the cache directory), just as the old "ccache" did. Compilations are run in the foreground, and control-C kills them all.
Or do you have a better suggestion? In scylladb/scylladb#30552 I came up with a rather ugly workaround using SCCACHE_NO_DAEMON=1 (to ensure that the server that does start, is in this process group) and SCCACHE_SERVER_UDS (to avoid using some other build's server), but it's not pretty - both in how it's used, and how it behaves, and I was hoping for something better.
We (https://github.com/scylladb/scylladb/) are using a ninja-based build system for C++ and Rust code, and using sccache for caching the compilations. Most developers do not use a remote compilation or caching setup - the cache is local and compilations are run on the same machine.
Our developers working interactively are facing an annoying problem: When we interrupt "ninja" with control-C, ninja is killed immediately, but all the ongoing compilations continue to run to completion, in the background. These compilations sometimes linger for several minutes (!), continuing to hog the machine's CPU and memory long after the user interrupted them.
The reason for this problem is sscache's server architecture: An sscache invoked by ninja may connect to some sscache server started earlier and run the build there. A control-C will never reach that other process group, and won't kill the build. Even no server exists, a new one will be started but by default will be run in a separate process group (SCCACHE_NO_DAEMON=1 can be used to avoid that).
It is hard for me to believe that we're the only people who are having this problem, and I wonder if anyone solved it somehow.
I wanted to suggest a command-line option (or environment variable) that simply doesn't use a build server at all - each "sccache" invocation would just work separately (just sharing the cache directory), just as the old "ccache" did. Compilations are run in the foreground, and control-C kills them all.
Or do you have a better suggestion? In scylladb/scylladb#30552 I came up with a rather ugly workaround using SCCACHE_NO_DAEMON=1 (to ensure that the server that does start, is in this process group) and SCCACHE_SERVER_UDS (to avoid using some other build's server), but it's not pretty - both in how it's used, and how it behaves, and I was hoping for something better.