[ccache] Migrating to ccache 4: a "drop-in replacement"?

Steffen Dettmer steffen.dettmer at gmail.com
Thu Dec 3 10:28:03 UTC 2020


Hi,

in short:
Is upgrading to ccache 4 a "drop-in replacement" even if sharing
the cache directory with still running ccache 3 versions?


in detail:
I consider upgrading to ccache 4 with or without sharing the
cache directory with older ccache (~3.7.7). Sharing the directory
could ease migration for users of course.

The new ccache version would be automatically deployed to the
users and used by all recent software branches, but the old
ccache would still be used by older branches (toolchain tool
versions are "pinned" for better reproducibility). On some
servers, the cache directory is shared across users.

ccache version 4.0 introduces a new cache directory structure [1]:

> The cache directory structure has changed compared to previous
> versions (more details below). This means that ccache 4.0 will
> not share cache results with earlier versions. It is however safe
> to run ccache 4.0 and earlier versions against the same cache
> directory: cache bookkeeping, statistics and cleanup are backward
> compatible, with the minor exception that some statistics
> counters incremented by ccache 4.0 won’t be visible when
> running ccache -s with an older version.

About the cache directory structure, I didn't find "more details
below", but the description seems to be clear that sharing the
cache directory wouldn't be any problem, even cleanup should
work: it is backward compatible. If I understand correctly, this
means as long as the new ccache version runs from time to time,
it will cleanup both old and new files and avoid ccache directory
grow (much) beyond max_size. That sounds great! Does it really
make new versions a "plug-in replacement"? That would be so cool!

Also config file location has changed to match the expectations
on Poetterings laptop [2] (SCNR), but release notes tell that if
~/.ccache/ccache.conf exists, it will be used (release notes are
not clear for me if only as fallack or in any case when it
exists). Also CCACHE_CONFIGPATH could be set to point to it if
needed, but it is not needed.

So in short: I would not need to change anything at all. Just
deploy it.

Is this correct?

Sorry for the long mail, but using ccache in detail can be quite
complex and I try to avoid missing an important detail.

Steffen




In case it helps our configuration:

  $ grep -v '^#' ~/.ccache/ccache.conf
  max_size = 0
  cache_dir=/...shared_local_path.../tmp/ccache
  hard_link=false
  umask=002

(only our Jenkins account runs with max_size = 50G to have a
central place to set the size)

cmake wrapper script example (it depends on the build):

  #!/bin/bash
  # Xcode generator doesn't include the compiler as the first arg:
  [ "$1" = "/.../i586-pc-linux-gnu/gcc-4.4.3/usr/bin/i586-pc-linux-gnu-g++"
] && shift

  # "Convert" cmake variable to an env (but keep present values) to allow
shared caches
  : ${CCACHE_BASEDIR="/.../sdettmer/work/xyz-src"}
  : ${CCACHE_CPP2="set"}
  # : ${CCACHE_NODIRECT="set"}
  export CCACHE_BASEDIR CCACHE_CPP2 CCACHE_NODIRECT
  unset GCC_COLORS
  { "/.../bin/ccache" "/.../gcc-4.4.3/usr/bin/i586-pc-linux-gnu-g++" "$@"
2>&1 1>&3 3>&-  | sed "s|^\(In file included from \)\?\.\./|\1$(pwd)/../|"
; exit ${PIPESTATUS[0]} ; } 3>&1 1>&2

NB: Our reference system is "Devuan 2.0 ASCII", a Debian fork without
SystemD.


[1] https://ccache.dev/releasenotes.html#_ccache_4_0
[2]
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html


More information about the ccache mailing list