Compilation cache of C/C++, rust, CUDA, clang

I don’t know if someone already know about this mozilla project but i feel it’s could be a helpful addition to the tool used in aux. It’s an alternative to ccache with some additional features.

little extract of the readme on the git :

" 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, and clang.

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.

sccache is also available as a GitHub Actions to facilitate the deployment using GitHub Actions cache."

6 Likes

How would this work with aux? IINM, even a cache would have to be pulled into /nix/store/ (are we going to call it /aux/store?). Even if the build input were garbage collected, wouldn’t it still be in the derivation inputs? And if it’s in the derivation inputs, how would it be recreated to have a reproducible build?

1 Like

Well the idea would be to have something like what possible with the current ccache CCache - NixOS Wiki but it’s would be nice to have it’s better integrated than current ccache ? As for reproducible build it’s shouldn’t affect them since it’s speed up part of compilation by reusing what already been build so should not change the result, in a way if the build is the same the cache should only speed up the compilation without changing the result.

I see :thinking: Do you understand how it works with nix? I’d be grateful for a short overview. I’m not concerned about the output, there’s no doubt it will be the same, but just how it works in general and together with nix.

My assumption was that the cache would be declared in the buildInputs of mkDerivation, but that doesn’t seem to be the case? Is the cache stored outside /nix/store (e.g /var/cache/ccache) and checked during the build phase? That kinda would surprise me, because I thought builds happened in a sandboxxed environment into which the build inputs were (hard?) linked, but I might be wrong. And if it’s not local maybe it’s over a unix socket or some HTTP server? But I’m not sure if network access is granted when building, nor whether it can be denied to have “pure” builds.

Do you have any insights?

We cannot change to /aux/store since we are no longer forking nix unless we want to patch nix, which seems like a wasted effort in my opion.

Probably for another discussion, but maybe lix could make “branding” possible. I know nix allows passing all kinds of variables, parameters, and even config values to change the locations of things, but in my experience they haven’t been tested well or maybe even at all. For example, theoretically, you should be able to install nix in a stand-alone manner and the installation script allows setting where the path to the store, but it flat out doesn’t work.

But if the community decides it’s not a path they/we want to take and nobody signs up to do it, asking lix might even be pointless.

1 Like

the cache could be fetched as part of the input of the build ? i will try to make a simple package and see how it’s could work, i was just wondering if that was something worth pursuing by getting opinion from people that are more experimented with the inner working of nix build.

2 Likes