boulder: Add CCACHE_BASEDIR to improve cache hit rates #473
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ccache resolves absolute paths to source files and uses that path as part of the cache key. In practice this means that changing the build directory invalidates all builds using a previous build directory, and given that the source archive name typically ends up being part of the build path (for instance
/mason/build/x86_64/llvm-project-20.1.4.src.tar.xz/
) the end result is that updating the version of a package is enough to invalidate all ccache entries from a previous version.To fix this we can use the CCACHE_BASEDIR environmental variable. If set ccache will strip the value of it from the cache key (for instance
/mason/build/x86_64/llvm-project-20.1.4.src.tar.xz/src/foo.c
with aCCACHE_BASEDIR=/mason/build/x86_64/llvm-project-20.1.4.src.tar.xz/
will be stored assrc/foo.c
) which means that ccache entries can persist between version updates. Given that ccache already hashes the file contents as part of the cache key this shouldn't cause any issues and should improve cache hit rates quite a bit.Also while we're at it add macro definitions for the zsh, fish, and elvish shell completions directories since that's a trivial change not really deserving of a separate PR.