shared ccache bits ...

Development
1

Hi all,

  Been wrestling with trying to get a shared ccache between my (several) live work-directories to try to reduce CPU melting action.

  I got this far:

  https://gerrit.collaboraoffice.com/c/online/+/4416

  Tried with CCACHE_NODIRECT=true make - and got some encouraging matching hashes across different top-levels, but ... still no ccache hits; weird.

  For debugging:

  CCACHE_DEBUGDIR=/tmp/mono2-cc CCACHE_DEBUG=1 make

  Has the nice benefit of putting the .ccache-foo files in a single place that can be compared reasonably easily - but I still get:

[2026-06-13T08:16:10.375895 6471 ] Result key: eb03sg1nqsh4v1kqitssoq7aq23rs7l24
[2026-06-13T08:16:10.379477 6471 ] Stored eb03sg1nqsh4v1kqitssoq7aq23rs7l24 in local storage (...cache/ccache/e/b/03sg1nqsh4v1kqitssoq7aq23rs7l24R)
...
[2026-06-13T08:16:10.379614 6471 ] Result: cache_miss
[2026-06-13T08:16:10.379615 6471 ] Result: local_storage_miss
[2026-06-13T08:16:10.379615 6471 ] Result: local_storage_write

  I wonder - does anyone else have experience of trying to do this? of course ccache -s shows similar lack of hitting.

  I was thinking it may (may) help my local builds improve - it might help CI go faster.

  Thoughts ?

    Michael.

2

Locally I'm using multiple git worktrees of debugging versions and a
shared ccache cache apparently successfully.

I put all of those at the same level under the same dir. Call that
$repos

My config is:

ccache --set-config "base_dir=$repos"
ccache --set-config "hash_dir=false"
ccache --set-config "compiler_check=content"

so that gives me a ~/.config/ccache/ccache.conf of:

max_size = 50G
base_dir = /home/caolan/repos
hash_dir = false
compiler_check = content

For everything under that "repos" base_dir then ccache relative-izes
the build, so existing "monorepo-X" ccache entries can serve a new
"monorepo-Y" throwaway git worktree. The new "build" is then about 2
minutes for an up to date to date ccache

There's been some recent changes merged to make this work, concat-deps
and fix ups of "../../" style includes that otherwise defeat this, so
the repo has to be up to date or there are mysterious build failures.

wrt debugging: https://gerrit.collaboraoffice.com/c/online/+/3998 is
yet to be reviewed/merged to make the *debugging* of that build safe in
the face of a build using a ccache entry from a deleted worktree. With
that applied then gdb has to be launched from the root of the source
you want it to use for display (though this is scriptable in
~/.config/gdb/gdbinit so you don't have to think about it)

I've gotten a little bit carried away with this and have a cronjob that
builds a dedicated "clean" worktree nightly so the ccache should have
fresh "main" results in it if/when I rebase my personal worktrees.

3

Locally I'm using multiple git worktrees of debugging versions and a
shared ccache cache apparently successfully.

  Ah - just trying to build that into the code itself :slight_smile:

For everything under that "repos" base_dir then ccache relative-izes
the build, so existing "monorepo-X" ccache entries can serve a new
"monorepo-Y" throwaway git worktree. The new "build" is then about 2
minutes for an up to date to date ccache

  Yep - my machine goes from one and a half hours to four and a half minutes with this for all builds.

  I had to push a VPATH addition to the Makefile rules to ensure that 'make' in sub-directories didn't fall foul of the relative paths.

  So I think:

  https://gerrit.collaboraoffice.com/c/online/+/4416

  Is ready for review there :slight_smile:

There's been some recent changes merged to make this work, concat-deps
and fix ups of "../../" style includes that otherwise defeat this, so
the repo has to be up to date or there are mysterious build failures.

  The relative deps seem to need the VPATH.

wrt debugging: https://gerrit.collaboraoffice.com/c/online/+/3998 is
yet to be reviewed/merged to make the *debugging* of that build safe

  Looks sensible to me; +2

I've gotten a little bit carried away with this and have a cronjob that
builds a dedicated "clean" worktree nightly so the ccache should have
fresh "main" results in it if/when I rebase my personal worktrees.

  Heh :slight_smile: seems even more 31337 to me; of course I only dip in and out of development; but sounds great.

  Thanks !

    Michael.