I’d love to have a system wide build cache as compile times are lengthy even with a Ryzen 9 5950X.
Currently the NIX documentation for CCache specifies that relevant packages should be declared but I’m clueless how to properly do this globally as I’m still new to NIX.
This depends on what it is you’re building. If you’re building an entire NixOS closure because you’re modifying stdenv (or something close to it) anyways, you would use the ccacheStdenv by default via Nixpkgs’ config.replaceStdenv argument. See https://github.com/NixOS/nixpkgs/blob/e24c4f8cbbf4b03999c0b1d4d48b148e75ace1b5/pkgs/top-level/all-packages.nix#L17670-L17672
This will, of course, result in a world rebuild.
If you only build a few leaf packages as part of a NixOS closure, use the ccache module and declare their attribute names in programs.ccache.packageNames.
What I’d like is something in the middle: keep the normal stdenv for my nixos system, but benefits ccache when hacking on nixpkgs, especially when invoking nixpkgs-review or git bisect run nix-build .... Is that possible? So far I couldn’t make nix-build use ccache…
Not possible currently.
What I have thought of in this regard though is that the Nixpkgs stdenv could include and enable ccache by default but only if the ccache path is present in the sandbox and has correct permissions.
This way, ccache is off by default but enables itself with no modification of the drv if you as the user opt to add ccache impurely into the sandbox.
That would be awesome!
For instance, I have started a git bisect over the last 4 weeks on pythonPackages.cartopy 12hrs ago and it is still running, recompiling things like cmake and glibc (and so all the rest) at nearly every iteration. I don’t expect every c and c++ files to have changed in that timeframe, so I think ccache could help tremendously there.
Btw if you’re bisecting on any branch other than staging, always use --first-parent.
That will reduce bisect granularity to the PR level but that’s usually more than good enough. More importantly though, this will also reduce the staging-next merge into a step between two revisions that are both cached.
If you do a regular bisect, you’ll hit staging commits quite often and nothing is cached on staging; requiring a full rebuild.
(If the PR has multiple commits you need the exact commit you can always start another bisect inside the PR.)