Replace sccache with ccache across CI workflows and build system - #3418
Replace sccache with ccache across CI workflows and build system#3418Lestropie wants to merge 1 commit into
Conversation
The project's CI previously used Mozilla's sccache for compiler caching. All workflows and the CMake compiler-cache module have been migrated to ccache instead, using the hendrikmuhs/ccache-action on Linux and macOS, and a manual actions/cache restore on Windows where ccache is installed via the MSYS2 package manager. Corresponding environment variables were updated from SCCACHE_* to CCACHE_* equivalents. The CMake helper was also fixed to search only the explicitly requested tool rather than the full list of candidates, preventing a stray sccache binary on a runner from silently taking precedence over ccache. The README was updated to drop the sccache recommendation. Generated-by: Claude Opus 4.8 <noreply@anthropic.com>
|
clang-tidy review says "All clean, LGTM! 👍" |
|
My initial implementation of compiler caching for the CI was indeed using I think switching to ccache is not a bad idea. As you pointed out, the major disavantage is that it will lead to an "all or nothing" caching strategy, but given that GitHub provides 10Gb (for 7 days) I don't think that limit will be hit easily (you'll probably need dozens of PRs or more to get there). I think before deciding it might be worth clearing the cache, trigger this PR and monitor the overall cache usage (perhaps running a small post build step that calls One additional benefit of using ccache in CI is that it should be faster (see here). |
| find_program(CACHE_BINARY NAMES ${CACHE_OPTION_VALUES}) | ||
| # Honour the requested tool only, so selection is deterministic and a stray | ||
| # sccache on a runner image can never be picked in preference to ccache. | ||
| find_program(CACHE_BINARY NAMES ${CACHE_OPTION}) |
There was a problem hiding this comment.
I missed this when writing this code, but I think CACHE_BINARY here should use NO_CACHE because if the developer changes CACHE_OPTION, this also needs updating.
2 participants
Hoping to catch an opinion from @daljit46.
I've had multiple PRs where I've had to wipe the whole GitHub Action cache because of compilation failures where the build cache and the precompiled headers get tangled:
Example CI build failure from #3414
Looking online, it seems that
sccachedoes not officially support PCH, and they are known to not play together particularly well. Indeed a55d6fd in #2877 disabled PCH on the Mac compilation check because this issue had already manifested in that environment.A primary selling point of
sccacheis cloud-based synchronisation of build artifacts across machines. However ifccacheis embedded in a dedicated GitHub Action, and we are only interested in sharing of build artifacts across CI runs, then that advantage seems to mostly disappear.sccachesupports more than C++ but we don't need that. Finally,sccachestores per-compiled-object artifacts, whereas withccacheone is restricted to the whole tarball; it is not yet clear to me the extent to which this may be problematic, potentially to a reasonable extent when there's a large number of PRs open. Could pay for a little more Action artifact storage if it would help.If the loss of per-compiled-object caching on GitHub is not a deal-breaker, then it would seem overall that
ccacheis a better choice thansccache. But curious to know if this was already factored in to the original decision process, whether I'm overlooking something, or getting the proportional weighting of priorities wrong.Would an alternative option be to rely exclusively on
sccachefor CI Actions, disabling PCH, and use PCH exclusively as a local compilation speedup mechanism?