1CCACHE(1) CCACHE(1)
2
6 ccache - a fast C/C++ compiler cache
7
9 ccache [options]
10 ccache compiler [compiler options]
11 compiler [compiler options] (via symbolic link)
12
14 Ccache is a compiler cache. It speeds up recompilation by caching the
15 result of previous compilations and detecting when the same compilation
16 is being done again.
17 Ccache has been carefully written to always produce exactly the same
19 compiler output that you would get without the cache. The only way you
20 should be able to tell that you are using ccache is the speed.
21 Currently known exceptions to this goal are listed under Caveats. If
22 you discover an undocumented case where ccache changes the output of
23 your compiler, please let us know.
24
26 There are two ways to use ccache. You can either prefix your
27 compilation commands with ccache or you can let ccache masquerade as
28 the compiler by creating a symbolic link (named as the compiler) to
29 ccache. The first method is most convenient if you just want to try out
30 ccache or wish to use it for some specific projects. The second method
31 is most useful for when you wish to use ccache for all your
32 compilations.
33 To use the first method, just make sure that ccache is in your PATH.
35 To use the symlinks method, do something like this:
37 cp ccache /usr/local/bin/
39 ln -s ccache /usr/local/bin/gcc
40 ln -s ccache /usr/local/bin/g++
41 ln -s ccache /usr/local/bin/cc
42 ln -s ccache /usr/local/bin/c++
43 And so forth. This will work as long as the directory with symlinks
45 comes before the path to the compiler (which is usually in /usr/bin).
46 After installing you may wish to run “which gcc” to make sure that the
47 correct link is being used.
48 Warning
50 The technique of letting ccache masquerade as the compiler works
51 well, but currently doesn’t interact well with other tools that do
52 the same thing. See [_using_ccache_with_other_compiler_wrappers].
53 Warning
55 Use a symbolic links for masquerading, not hard links.
56
58 These command line options only apply when you invoke ccache as
59 “ccache”. When invoked as a compiler (via a symlink as described in the
60 previous section), the normal compiler options apply and you should
61 refer to the compiler’s documentation.
62 Common options
64 -c, --cleanup
65 Clean up the cache by removing old cached files until the specified
66 file number and cache size limits are not exceeded. This also
67 recalculates the cache file count and size totals. Normally, there
68 is no need to initiate cleanup manually as ccache keeps the cache
69 below the specified limits at runtime and keeps statistics up to
70 date on each compilation. Forcing a cleanup is mostly useful if you
71 manually modify the cache contents or believe that the cache size
72 statistics may be inaccurate.
73 -C, --clear
75 Clear the entire cache, removing all cached files, but keeping the
76 configuration file.
77 --config-path PATH
79 Let the command line options operate on configuration file PATH
80 instead of the default. Using this option has the same effect as
81 setting the environment variable CCACHE_CONFIGPATH temporarily.
82 -d, --dir PATH
84 Let the command line options operate on cache directory PATH
85 instead of the default. For example, to show statistics for a cache
86 directory at /shared/ccache you can run ccache -d /shared/ccache
87 -s. Using this option has the same effect as setting the
88 environment variable CCACHE_DIR temporarily.
89 --evict-namespace NAMESPACE
91 Remove files created in the given namespace from the cache.
92 --evict-older-than AGE
94 Remove files older than AGE from the cache. AGE should be an
95 unsigned integer with a d (days) or s (seconds) suffix. If combined
96 with --evict-namespace, only remove old files within that
97 namespace.
98 -h, --help
100 Print a summary of command line options.
101 -F NUM, --max-files NUM
103 Set the maximum number of files allowed in the cache to NUM. Use 0
104 for no limit. The value is stored in a configuration file in the
105 cache directory and applies to all future compilations.
106 -M SIZE, --max-size SIZE
108 Set the maximum size of the files stored in the cache. SIZE should
109 be a number followed by an optional suffix: k, M, G, T (decimal),
110 Ki, Mi, Gi or Ti (binary). The default suffix is G. Use 0 for no
111 limit. The value is stored in a configuration file in the cache
112 directory and applies to all future compilations.
113 -X LEVEL, --recompress LEVEL
115 Recompress the cache to level LEVEL using the Zstandard algorithm.
116 The level can be an integer, with the same semantics as the
117 compression_level configuration option), or the special value
118 uncompressed for no compression. See [_cache_compression] for more
119 information. This can potentionally take a long time since all
120 files in the cache need to be visited. Only files that are
121 currently compressed with a different level than LEVEL will be
122 recompressed.
123 -o KEY=VALUE, --set-config KEY=VALUE
125 Set configuration option KEY to VALUE. See [_configuration] for
126 more information.
127 -x, --show-compression
129 Print cache compression statistics. See [_cache_compression] for
130 more information. This can potentionally take a long time since all
131 files in the cache need to be visited.
132 -p, --show-config
134 Print current configuration options and from where they originate
135 (environment variable, configuration file or compile-time default)
136 in human-readable format.
137 --show-log-stats
139 Print statistics counters from the stats log in human-readable
140 format. See stats_log. Use -v/--verbose once or twice for more
141 details.
142 -s, --show-stats
144 Print a summary of configuration and statistics counters in
145 human-readable format. Use -v/--verbose once or twice for more
146 details.
147 -v, --verbose
149 Increase verbosity. The option can be given multiple times.
150 -V, --version
152 Print version and copyright information.
153 -z, --zero-stats
155 Zero the cache statistics (but not the configuration options).
156 Options for secondary storage
158 --trim-dir PATH
159 Remove old files from directory PATH until it is at most the size
160 specified by --trim-max-size.
161 Warning
163 Don’t use this option to trim the primary cache. To trim the
164 primary cache directory to a certain size, use
165 CCACHE_MAXSIZE=SIZE ccache -c.
166 --trim-max-size SIZE
168 Specify the maximum size for --trim-dir. SIZE should be a number
169 followed by an optional suffix: k, M, G, T (decimal), Ki, Mi, Gi or
170 Ti (binary). The default suffix is G.
171 --trim-method METHOD
173 Specify the method to trim a directory with --trim-dir. Possible
174 values are:
175 atime
177 LRU (least recently used) using the file access timestamp. This
178 is the default.
179 mtime
181 LRU (least recently used) using the file modification
182 timestamp.
183 Options for scripting or debugging
185 --checksum-file PATH
186 Print the checksum (128 bit XXH3) of the file at PATH (- for
187 standard input).
188 --dump-manifest PATH
190 Dump manifest file at PATH (- for standard input) in text format to
191 standard output. This is only useful when debugging ccache and its
192 behavior.
193 --dump-result PATH
195 Dump result file at PATH (- for standard input) in text format to
196 standard output. This is only useful when debugging ccache and its
197 behavior.
198 --extract-result PATH
200 Extract data stored in the result file at PATH (- for standard
201 input). The data will be written to ccache-result.* files in to the
202 current working directory. This is only useful when debugging
203 ccache and its behavior.
204 -k KEY, --get-config KEY
206 Print the value of configuration option KEY. See [_configuration]
207 for more information.
208 --hash-file PATH
210 Print the hash (160 bit BLAKE3) of the file at PATH (- for standard
211 input). This is only useful when debugging ccache and its behavior.
212 --print-stats
214 Print statistics counter IDs and corresponding values in
215 machine-parsable (tab-separated) format.
216 Extra options
218 When run as a compiler, ccache usually just takes the same command line
219 options as the compiler you are using. The only exception to this is
220 the option --ccache-skip. That option can be used to tell ccache to
221 avoid interpreting the next option in any way and to pass it along to
222 the compiler as-is.
223 Note
225 --ccache-skip currently only tells ccache not to interpret the next
226 option as a special compiler option — the option will still be
227 included in the direct mode hash.
228 The reason this can be important is that ccache does need to parse the
230 command line and determine what is an input filename and what is a
231 compiler option, as it needs the input filename to determine the name
232 of the resulting object file (among other things). The heuristic ccache
233 uses when parsing the command line is that any argument that exists as
234 a file is treated as an input file name. By using --ccache-skip you can
235 force an option to not be treated as an input file name and instead be
236 passed along to the compiler as a command line option.
237 Another case where --ccache-skip can be useful is if ccache interprets
239 an option specially but shouldn’t, since the option has another meaning
240 for your compiler than what ccache thinks.
241
243 Ccache’s default behavior can be overridden by options in configuration
244 files, which in turn can be overridden by environment variables with
245 names starting with CCACHE_. Ccache normally reads configuration from
246 two files: first a system-level configuration file and secondly a
247 cache-specific configuration file. The priorities of configuration
248 options are as follows (where 1 is highest):
249 1. Environment variables.
251 2. The primary (cache-specific) configuration file (see below).
253 3. The secondary (system-wide read-only) configuration file
255 <sysconfdir>/ccache.conf (typically /etc/ccache.conf or
256 /usr/local/etc/ccache.conf).
257 4. Compile-time defaults.
259 As a special case, if the the environment variable CCACHE_CONFIGPATH is
261 set it specifies the primary configuration file and the secondary
262 (system-wide) configuration file won’t be read.
263 Location of the primary configuration file
265 The location of the primary (cache-specific) configuration is
266 determined like this:
267 1. If CCACHE_CONFIGPATH is set, use that path.
269 2. Otherwise, if the environment variable CCACHE_DIR is set then use
271 $CCACHE_DIR/ccache.conf.
272 3. Otherwise, if cache_dir is set in the secondary (system-wide)
274 configuration file then use <cache_dir>/ccache.conf.
275 4. Otherwise, if there is a legacy $HOME/.ccache directory then use
277 $HOME/.ccache/ccache.conf.
278 5. Otherwise, if XDG_CONFIG_HOME is set then use
280 $XDG_CONFIG_HOME/ccache/ccache.conf.
281 6. Otherwise, use %APPDATA%/ccache/ccache.conf (Windows),
283 $HOME/Library/Preferences/ccache/ccache.conf (macOS) or
284 $HOME/.config/ccache/ccache.conf (other systems).
285 Configuration file syntax
287 Configuration files are in a simple “key = value” format, one option
288 per line. Lines starting with a hash sign are comments. Blank lines are
289 ignored, as is whitespace surrounding keys and values. Example:
290 # Set maximum cache size to 10 GB:
292 max_size = 10G
293 Boolean values
295 Some configuration options are boolean values (i.e. truth values). In a
296 configuration file, such values must be set to the string true or
297 false. For the corresponding environment variables, the semantics are a
298 bit different:
299 • A set environment variable means “true” (even if set to the empty
301 string).
302 • The following case-insensitive negative values are considered an
304 error (instead of surprising the user): 0, false, disable and no.
305 • An unset environment variable means “false”.
307 Each boolean environment variable also has a negated form starting with
309 CCACHE_NO. For example, CCACHE_COMPRESS can be set to force compression
310 and CCACHE_NOCOMPRESS can be set to force no compression.
311 Configuration options
313 Below is a list of available configuration options. The corresponding
314 environment variable name is indicated in parentheses after each
315 configuration option key.
316 absolute_paths_in_stderr (CCACHE_ABSSTDERR)
318 This option specifies whether ccache should rewrite relative paths
319 in the compiler’s standard error output to absolute paths. This can
320 be useful if you use base_dir with a build system (e.g. CMake with
321 the "Unix Makefiles" generator) that executes the compiler in a
322 different working directory, which makes relative paths in compiler
323 errors or warnings incorrect. The default is false.
324 base_dir (CCACHE_BASEDIR)
326 This option should be an absolute path to a directory. If set,
327 ccache will rewrite absolute paths into paths relative to the
328 current working directory, but only absolute paths that begin with
329 base_dir. Cache results can then be shared for compilations in
330 different directories even if the project uses absolute paths in
331 the compiler command line. See also the discussion under
332 [_compiling_in_different_directories]. If set to the empty string
333 (which is the default), no rewriting is done.
334 A typical path to use as base_dir is your home directory or another
336 directory that is a parent of your project directories. Don’t use /
337 as the base directory since that will make ccache also rewrite
338 paths to system header files, which typically is contraproductive.
339 For example, say that Alice’s current working directory is
341 /home/alice/project1/build and that she compiles like this:
342 ccache gcc -I/usr/include/example -I/home/alice/project2/include -c /home/alice/project1/src/example.c
344 Here is what ccache will actually execute for different base_dir
346 values:
347 # Current working directory: /home/alice/project1/build
349 # With base_dir = /:
351 gcc -I../../../../usr/include/example -I../../project2/include -c ../src/example.c
352 # With base_dir = /home or /home/alice:
354 gcc -I/usr/include/example -I../../project2/include -c ../src/example.c
355 # With base_dir = /home/alice/project1 or /home/alice/project1/src:
357 gcc -I/usr/include/example -I/home/alice/project2/include -c ../src/example.c
358 If Bob has put project1 and project2 in /home/bob/stuff and both
360 users have set base_dir to /home or /home/$USER, then Bob will get
361 a cache hit (if they share ccache directory) since the actual
362 command line will be identical to that of Alice:
363 # Current working directory: /home/bob/stuff/project1/build
365 # With base_dir = /home or /home/bob:
367 gcc -I/usr/include/example -I../../project2/include -c ../src/example.c
368 Without base_dir there will be a cache miss since the absolute
370 paths will differ. With base_dir set to / there will be a cache
371 miss since the relative path to /usr/include/example will be
372 different. With base_dir set to /home/bob/stuff/project1 there will
373 a cache miss since the path to project2 will be a different
374 absolute path.
375 cache_dir (CCACHE_DIR)
377 This option specifies where ccache will keep its cached compiler
378 outputs. The default is $XDG_CACHE_HOME/ccache if XDG_CACHE_HOME is
379 set, otherwise $HOME/.cache/ccache. Exception: If the legacy
380 directory $HOME/.ccache exists then that directory is the default.
381 See also [_location_of_the_primary_configuration_file].
383 If you want to use another CCACHE_DIR value temporarily for one
385 ccache invocation you can use the -d/--dir command line option
386 instead.
387 compiler (CCACHE_COMPILER or (deprecated) CCACHE_CC)
389 This option can be used to force the name of the compiler to use.
390 If set to the empty string (which is the default), ccache works it
391 out from the command line.
392 compiler_check (CCACHE_COMPILERCHECK)
394 By default, ccache includes the modification time (“mtime”) and
395 size of the compiler in the hash to ensure that results retrieved
396 from the cache are accurate. This option can be used to select
397 another strategy. Possible values are:
398 content
400 Hash the content of the compiler binary. This makes ccache very
401 slightly slower compared to mtime, but makes it cope better
402 with compiler upgrades during a build bootstrapping process.
403 mtime
405 Hash the compiler’s mtime and size, which is fast. This is the
406 default.
407 none
409 Don’t hash anything. This may be good for situations where you
410 can safely use the cached results even though the compiler’s
411 mtime or size has changed (e.g. if the compiler is built as
412 part of your build system and the compiler’s source has not
413 changed, or if the compiler only has changes that don’t affect
414 code generation). You should only use none if you know what you
415 are doing.
416 string:value
418 Hash value. This can for instance be a compiler revision number
419 or another string that the build system generates to identify
420 the compiler.
421 a command string
423 Hash the standard output and standard error output of the
424 specified command. The string will be split on whitespace to
425 find out the command and arguments to run. No other
426 interpretation of the command string will be done, except that
427 the special word %compiler% will be replaced with the path to
428 the compiler. Several commands can be specified with semicolon
429 as separator. Examples:
430 %compiler% -v
432 %compiler% -dumpmachine; %compiler% -dumpversion
434 You should make sure that the specified command is as fast as
436 possible since it will be run once for each ccache invocation.
437 Identifying the compiler using a command is useful if you want
439 to avoid cache misses when the compiler has been rebuilt but
440 not changed.
441 Another case is when the compiler (as seen by ccache) actually
443 isn’t the real compiler but another compiler wrapper — in that
444 case, the default mtime method will hash the mtime and size of
445 the other compiler wrapper, which means that ccache won’t be
446 able to detect a compiler upgrade. Using a suitable command to
447 identify the compiler is thus safer, but it’s also slower, so
448 you should consider continue using the mtime method in
449 combination with the prefix_command option if possible. See
450 [_using_ccache_with_other_compiler_wrappers].
451 compiler_type (CCACHE_COMPILERTYPE)
453 Ccache normally guesses the compiler type based on the compiler
454 name. The compiler_type option lets you force a compiler type. This
455 can be useful if the compiler has a non-standard name but is
456 actually one of the known compiler types. Possible values are:
457 auto
459 Guess one of the types below based on the compiler name
460 (following symlinks). This is the default.
461 clang
463 Clang-based compiler.
464 gcc
466 GCC-based compiler.
467 nvcc
469 NVCC (CUDA) compiler.
470 other
472 Any compiler other than the known types.
473 pump
475 distcc’s “pump” script.
476 compression (CCACHE_COMPRESS or CCACHE_NOCOMPRESS, see
478 [_boolean_values] above)
479 If true, ccache will compress data it puts in the cache. However,
480 this option has no effect on how files are retrieved from the
481 cache; compressed and uncompressed results will still be usable
482 regardless of this option. The default is true.
483 Compression is done using the Zstandard algorithm. The algorithm is
485 fast enough that there should be little reason to turn off
486 compression to gain performance. One exception is if the cache is
487 located on a compressed file system, in which case the compression
488 performed by ccache of course is redundant.
489 Compression will be disabled if file cloning (the file_clone
491 option) or hard linking (the hard_link option) is enabled.
492 compression_level (CCACHE_COMPRESSLEVEL)
494 This option determines the level at which ccache will compress
495 object files using the real-time compression algorithm Zstandard.
496 It only has effect if compression is enabled (which it is by
497 default). Zstandard is extremely fast for decompression and very
498 fast for compression for lower compression levels. The default is
499 0.
500 Semantics of compression_level:
502 > 0
504 A positive value corresponds to normal Zstandard compression
505 levels. Lower levels (e.g. 1) mean faster compression but worse
506 compression ratio. Higher levels (e.g. 19) mean slower
507 compression but better compression ratio. The maximum possible
508 value depends on the libzstd version, but at least up to 19 is
509 available for all versions. Decompression speed is essentially
510 the same for all levels. As a rule of thumb, use level 5 or
511 lower since higher levels may slow down compilations
512 noticeably. Higher levels are however useful when recompressing
513 the cache with command line option -X/--recompress.
514 < 0
516 A negative value corresponds to Zstandard’s “ultra-fast”
517 compression levels, which are even faster than level 1 but with
518 less good compression ratios. For instance, level -3
519 corresponds to --fast=3 for the zstd command line tool. In
520 practice, there is little use for levels lower than -5 or so.
521 0 (default)
523 The value 0 means that ccache will choose a suitable level,
524 currently 1.
525 See the Zstandard documentation <http://zstd.net> for more
527 information.
528 cpp_extension (CCACHE_EXTENSION)
530 This option can be used to force a certain extension for the
531 intermediate preprocessed file. The default is to automatically
532 determine the extension to use for intermediate preprocessor files
533 based on the type of file being compiled, but that sometimes
534 doesn’t work. For example, when using the “aCC” compiler on HP-UX,
535 set the cpp extension to i.
536 debug (CCACHE_DEBUG or CCACHE_NODEBUG, see [_boolean_values] above)
538 If true, enable the debug mode. The debug mode creates per-object
539 debug files that are helpful when debugging unexpected cache
540 misses. Note however that ccache performance will be reduced
541 slightly. See [_cache_debugging] for more information. The default
542 is false.
543 debug_dir (CCACHE_DEBUGDIR)
545 Specifies where to write per-object debug files if the debug mode
546 is enabled. If set to the empty string, the files will be written
547 next to the object file. If set to a directory, the debug files
548 will be written with full absolute paths in that directory,
549 creating it if needed. The default is the empty string.
550 For example, if debug_dir is set to /example, the current working
552 directory is /home/user and the object file is build/output.o then
553 the debug log will be written to
554 /example/home/user/build/output.o.ccache-log. See also
555 [_cache_debugging].
556 depend_mode (CCACHE_DEPEND or CCACHE_NODEPEND, see [_boolean_values]
558 above)
559 If true, the depend mode will be used. The default is false. See
560 [_the_depend_mode].
561 direct_mode (CCACHE_DIRECT or CCACHE_NODIRECT, see [_boolean_values]
563 above)
564 If true, the direct mode will be used. The default is true. See
565 [_the_direct_mode].
566 disable (CCACHE_DISABLE or CCACHE_NODISABLE, see [_boolean_values]
568 above)
569 When true, ccache will just call the real compiler, bypassing the
570 cache completely. The default is false.
571 extra_files_to_hash (CCACHE_EXTRAFILES)
573 This option is a list of paths to files that ccache will include in
574 the the hash sum that identifies the build. The list separator is
575 semicolon on Windows systems and colon on other systems.
576 file_clone (CCACHE_FILECLONE or CCACHE_NOFILECLONE, see
578 [_boolean_values] above)
579 If true, ccache will attempt to use file cloning (also known as
580 “copy on write”, “CoW” or “reflinks”) to store and fetch cached
581 compiler results. file_clone has priority over hard_link. The
582 default is false.
583 Files stored by cloning cannot be compressed, so the cache size
585 will likely be significantly larger if this option is enabled.
586 However, performance may be improved depending on the use case.
587 Unlike the hard_link option, file_clone is completely safe to use,
589 but not all file systems support the feature. For such file
590 systems, ccache will fall back to use plain copying (or hard links
591 if hard_link is enabled).
592 hard_link (CCACHE_HARDLINK or CCACHE_NOHARDLINK, see [_boolean_values]
594 above)
595 If true, ccache will attempt to use hard links to store and fetch
596 cached object files. The default is false.
597 Files stored via hard links cannot be compressed, so the cache size
599 will likely be significantly larger if this option is enabled.
600 However, performance may be improved depending on the use case.
601 Warning
603 Do not enable this option unless you are aware of these
604 caveats:
605 • If the resulting file is modified, the file in the cache will
607 also be modified since they share content, which corrupts the
608 cache entry. As of version 4.0, ccache makes stored and fetched
609 object files read-only as a safety measure guard. Furthermore,
610 a simple integrity check is made for cached object files by
611 verifying that their sizes are correct. This means that
612 mistakes like strip file.o or echo >file.o will be detected
613 even if the object file is made writeable, but a modification
614 that doesn’t change the file size will not.
615 • Programs that don’t expect that files from two different
617 identical compilations are hard links to each other can fail.
618 • Programs that rely on modification times (like make) can be
620 confused if several users (or one user with several build
621 trees) use the same cache directory. The reason for this is
622 that the object files share i-nodes and therefore modification
623 times. If file.o is in build tree A (hard-linked from the
624 cache) and file.o then is produced by ccache in build tree B by
625 hard-linking from the cache, the modification timestamp will be
626 updated for file.o in build tree A as well. This can retrigger
627 relinking in build tree A even though nothing really has
628 changed.
629 hash_dir (CCACHE_HASHDIR or CCACHE_NOHASHDIR, see [_boolean_values]
631 above)
632 If true (which is the default), ccache will include the current
633 working directory (CWD) in the hash that is used to distinguish two
634 compilations when generating debug info (compiler option -g with
635 variations). Exception: The CWD will not be included in the hash if
636 base_dir is set (and matches the CWD) and the compiler option
637 -fdebug-prefix-map is used. See also the discussion under
638 [_compiling_in_different_directories].
639 The reason for including the CWD in the hash by default is to
641 prevent a problem with the storage of the current working directory
642 in the debug info of an object file, which can lead ccache to
643 return a cached object file that has the working directory in the
644 debug info set incorrectly.
645 You can disable this option to get cache hits when compiling the
647 same source code in different directories if you don’t mind that
648 CWD in the debug info might be incorrect.
649 ignore_headers_in_manifest (CCACHE_IGNOREHEADERS)
651 This option is a list of paths to files (or directories with
652 headers) that ccache will not include in the manifest list that
653 makes up the direct mode. Note that this can cause stale cache hits
654 if those headers do indeed change. The list separator is semicolon
655 on Windows systems and colon on other systems.
656 ignore_options (CCACHE_IGNOREOPTIONS)
658 This option is a space-delimited list of compiler options that
659 ccache will exclude from the hash. Excluding a compiler option from
660 the hash can be useful when you know it doesn’t affect the result
661 (but ccache doesn’t know that), or when it does and you don’t care.
662 If a compiler option in the list is suffixed with an asterisk (*)
663 it will be matched as a prefix. For example, -fmessage-length=*
664 will match both -fmessage-length=20 and -fmessage-length=70.
665 inode_cache (CCACHE_INODECACHE or CCACHE_NOINODECACHE, see
667 [_boolean_values] above)
668 If true, enables caching of source file hashes based on device,
669 inode and timestamps. This will reduce the time spent on hashing
670 included files as the result can be resused between compilations.
671 The feature is still experimental and thus off by default. It is
673 currently not available on Windows.
674 The feature requires temporary_dir to be located on a local
676 filesystem.
677 keep_comments_cpp (CCACHE_COMMENTS or CCACHE_NOCOMMENTS, see
679 [_boolean_values] above)
680 If true, ccache will not discard the comments before hashing
681 preprocessor output. This can be used to check documentation with
682 -Wdocumentation.
683 limit_multiple (CCACHE_LIMIT_MULTIPLE)
685 Sets the limit when cleaning up. Files are deleted (in LRU order)
686 until the levels are below the limit. The default is 0.8 (= 80%).
687 See [_automatic_cleanup] for more information.
688 log_file (CCACHE_LOGFILE)
690 If set to a file path, ccache will write information on what it is
691 doing to the specified file. This is useful for tracking down
692 problems.
693 If set to syslog, ccache will log using syslog() instead of to a
695 file. If you use rsyslogd, you can add something like this to
696 /etc/rsyslog.conf or a file in /etc/rsyslog.d:
697 # log ccache to file
699 :programname, isequal, "ccache" /var/log/ccache
700 # remove from syslog
701 & ~
702 max_files (CCACHE_MAXFILES)
704 This option specifies the maximum number of files to keep in the
705 cache. Use 0 for no limit (which is the default). See also
706 [_cache_size_management].
707 max_size (CCACHE_MAXSIZE)
709 This option specifies the maximum size of the cache. Use 0 for no
710 limit. The default value is 5G. Available suffixes: k, M, G, T
711 (decimal) and Ki, Mi, Gi, Ti (binary). The default suffix is G. See
712 also [_cache_size_management].
713 namespace (CCACHE_NAMESPACE)
715 If set, the namespace string will be added to the hashed data
716 for each compilation. This will make the associated cache entries
717 logically separate from cache entries with other namespaces, but
718 they will still share the same storage space. Cache entries can
719 also be selectively removed from the primary cache with the command
720 line option --evict-namespace, potentially in combination with
721 --evict-older-than. . For instance, if you use the same primary
722 cache for several disparate projects, you can use a unique
723 namespace string for each one. This allows you to remove cache
724 entries that belong to a certain project if stop working with that
725 project.
726 path (CCACHE_PATH)
728 If set, ccache will search directories in this list when looking
729 for the real compiler. The list separator is semicolon on Windows
730 systems and colon on other systems. If not set, ccache will look
731 for the first executable matching the compiler name in the normal
732 PATH that isn’t a symbolic link to ccache itself.
733 pch_external_checksum (CCACHE_PCH_EXTSUM or CCACHE_NOPCH_EXTSUM, see
735 [_boolean_values] above)
736 When this option is set, and ccache finds a precompiled header
737 file, ccache will look for a file with the extension “.sum” added
738 (e.g. “pre.h.gch.sum”), and if found, it will hash this file
739 instead of the precompiled header itself to work around the
740 performance penalty of hashing very large files.
741 prefix_command (CCACHE_PREFIX)
743 This option adds a list of prefixes (separated by space) to the
744 command line that ccache uses when invoking the compiler. See also
745 [_using_ccache_with_other_compiler_wrappers].
746 prefix_command_cpp (CCACHE_PREFIX_CPP)
748 This option adds a list of prefixes (separated by space) to the
749 command line that ccache uses when invoking the preprocessor.
750 read_only (CCACHE_READONLY or CCACHE_NOREADONLY, see [_boolean_values]
752 above)
753 If true, ccache will attempt to use existing cached results, but it
754 will not add new results to any cache backend. Statistics counters
755 will still be updated, though, unless the stats option is set to
756 false.
757 If you are using this because your ccache directory is read-only,
759 you need to set temporary_dir since ccache will fail to create
760 temporary files otherwise. You may also want to set stats to false
761 make ccache not even try to update stats files.
762 read_only_direct (CCACHE_READONLY_DIRECT or CCACHE_NOREADONLY_DIRECT,
764 see [_boolean_values] above)
765 Just like read_only except that ccache will only try to retrieve
766 results from the cache using the direct mode, not the preprocessor
767 mode. See documentation for read_only regarding using a read-only
768 ccache directory.
769 recache (CCACHE_RECACHE or CCACHE_NORECACHE, see [_boolean_values]
771 above)
772 If true, ccache will not use any previously stored result. New
773 results will still be cached, possibly overwriting any pre-existing
774 results.
775 reshare (CCACHE_RESHARE or CCACHE_NORESHARE, see [_boolean_values]
777 above)
778 If true, ccache will write results to secondary storage even for
779 primary storage cache hits. The default is false.
780 run_second_cpp (CCACHE_CPP2 or CCACHE_NOCPP2, see [_boolean_values]
782 above)
783 If true, ccache will first run the preprocessor to preprocess the
784 source code (see [_the_preprocessor_mode]) and then on a cache miss
785 run the compiler on the source code to get hold of the object file.
786 This is the default.
787 If false, ccache will first run preprocessor to preprocess the
789 source code and then on a cache miss run the compiler on the
790 preprocessed source code instead of the original source code. This
791 makes cache misses slightly faster since the source code only has
792 to be preprocessed once. The downside is that some compilers won’t
793 produce the same result (for instance diagnostics warnings) when
794 compiling preprocessed source code.
795 A solution to the above mentioned downside is to set run_second_cpp
797 to false and pass -fdirectives-only (for GCC) or -frewrite-includes
798 (for Clang) to the compiler. This will cause the compiler to leave
799 the macros and other preprocessor information, and only process the
800 #include directives. When run in this way, the preprocessor
801 arguments will be passed to the compiler since it still has to do
802 some preprocessing (like macros).
803 secondary_storage (CCACHE_SECONDARY_STORAGE)
805 This option specifies one or several storage backends (separated by
806 space) to query after the primary cache storage. See
807 [_secondary_storage_backends] for documentation of syntax and
808 available backends.
809 Examples:
811 • file:/shared/nfs/directory
813 • file:///shared/nfs/one|read-only file:///shared/nfs/two
815 • http://example.com/cache
817 • redis://example.com
819 sloppiness (CCACHE_SLOPPINESS)
821 By default, ccache tries to give as few false cache hits as
822 possible. However, in certain situations it’s possible that you
823 know things that ccache can’t take for granted. This option makes
824 it possible to tell ccache to relax some checks in order to
825 increase the hit rate. The value should be a comma-separated string
826 with one or several of the following values:
827 clang_index_store
829 Ignore the Clang compiler option -index-store-path and its
830 argument when computing the manifest hash. This is useful if
831 you use Xcode, which uses an index store path derived from the
832 local project path. Note that the index store won’t be updated
833 correctly on cache hits if you enable this sloppiness.
834 file_stat_matches
836 Ccache normally examines a file’s contents to determine whether
837 it matches the cached version. With this sloppiness set, ccache
838 will consider a file as matching its cached version if the
839 mtimes and ctimes match.
840 file_stat_matches_ctime
842 Ignore ctimes when file_stat_matches is enabled. This can be
843 useful when backdating files' mtimes in a controlled way.
844 include_file_ctime
846 By default, ccache will not cache a file if it includes a
847 header whose ctime is too new. This sloppiness disables that
848 check. See also [_handling_of_newly_created_header_files].
849 include_file_mtime
851 By default, ccache will not cache a file if it includes a
852 header whose mtime is too new. This sloppiness disables that
853 check. See also [_handling_of_newly_created_header_files].
854 ivfsoverlay
856 Ignore the Clang compiler option -ivfsoverlay and its argument.
857 This is useful if you use Xcode, which uses a virtual file
858 system (VFS) for things like combining Objective-C and Swift
859 code.
860 locale
862 Ccache includes the environment variables LANG, LC_ALL,
863 LC_CTYPE and LC_MESSAGES in the hash by default since they may
864 affect localization of compiler warning messages. Set this
865 sloppiness to tell ccache not to do that.
866 pch_defines
868 Be sloppy about #define directives when precompiling a header
869 file. See [_precompiled_headers] for more information.
870 modules
872 By default, ccache will not cache compilations if -fmodules is
873 used since it cannot hash the state of compiler’s internal
874 representation of relevant modules. This sloppiness allows
875 caching in such a case. See [_c_modules] for more information.
876 system_headers
878 By default, ccache will also include all system headers in the
879 manifest. With this sloppiness set, ccache will only include
880 system headers in the hash but not add the system header files
881 to the list of include files.
882 time_macros
884 Ignore __DATE__, __TIME__ and __TIMESTAMP__ being present in
885 the source code.
886 See the discussion under [_troubleshooting] for more information.
888 stats (CCACHE_STATS or CCACHE_NOSTATS, see [_boolean_values] above)
890 If true, ccache will update the statistics counters on each
891 compilation. The default is true.
892 stats_log (CCACHE_STATSLOG)
894 If set to a file path, ccache will write statistics counter updates
895 to the specified file. This is useful for getting statistics for
896 individual builds. To show a summary of the current stats log, use
897 ccache --show-log-stats.
898 Note
900 Lines in the stats log starting with a hash sign (#) are
901 comments.
902 temporary_dir (CCACHE_TEMPDIR)
904 This option specifies where ccache will put temporary files. The
905 default is /run/user/<UID>/ccache-tmp if /run/user/<UID> exists,
906 otherwise <cache_dir>/tmp.
907 Note
909 In previous versions of ccache, CCACHE_TEMPDIR had to be on the
910 same filesystem as the CCACHE_DIR path, but this requirement
911 has been relaxed.
912 umask (CCACHE_UMASK)
914 This option (an octal integer) specifies the umask for files and
915 directories in the cache directory. This is mostly useful when you
916 wish to share your cache with other users.
917
919 The secondary_storage option lets you configure ccache to use one or
920 several other storage backends in addition to the primary cache storage
921 located in cache_dir. Note that cache statistics counters will still be
922 kept in the primary cache directory — secondary storage backends only
923 store cache results and manifests.
924 A secondary storage backend is specified with a URL, optionally
926 followed by a pipe (|) and a pipe-separated list of attributes. An
927 attribute is key=value or just key as a short form of key=true.
928 Attribute values must be percent-encoded
929 <https://en.wikipedia.org/wiki/Percent-encoding> if they contain
930 percent, pipe or space characters.
931 Attributes for all backends
933 These optional attributes are available for all secondary storage
934 backends:
935 • read-only: If true, only read from this backend, don’t write. The
937 default is false.
938 • shards: A comma-separated list of names for sharding (partitioning)
940 the cache entries using Rendezvous hashing
941 <https://en.wikipedia.org/wiki/Rendezvous_hashing>, typically to
942 spread the cache over a server cluster. When set, the storage URL
943 must contain an asterisk (*), which will be replaced by one of the
944 shard names to form a real URL. A shard name can optionally have an
945 appended weight within parentheses to indicate how much of the key
946 space should be associated with that shard. A shard with weight w
947 will contain w/S of the cache, where S is the sum of all shard
948 weights. A weight could for instance be set to represent the
949 available memory for a memory cache on a specific server. The
950 default weight is 1.
951 Examples:
953 • redis://cache-*.example.com|shards=a(3),b(1),c(1.5) will put
955 55% (3/5.5) of the cache on redis://cache-a.example.com, 18%
956 (1/5.5) on redis://cache-b.example.com and 27% (1.5/5.5) on
957 redis://cache-c.example.com.
958 • http://example.com/*|shards=alpha,beta will put 50% of the
960 cache on http://example.com/alpha and 50% on
961 http://example.com/beta.
962 • share-hits: If true, write hits for this backend to primary
964 storage. The default is true.
965 Storage interaction
967 The table below describes the interaction between primary and secondary
968 storage on cache hits and misses:
969 ┌────────────────┬───────────────────┬─────────────────────┐
971 │ │ │ │
972 │Primary storage │ Secondary storage │ What happens │
973 ├────────────────┼───────────────────┼─────────────────────┤
974 │ │ │ │
975 │miss │ miss │ Compile, write to │
976 │ │ │ primary, write to │
977 │ │ │ secondary[1] │
978 ├────────────────┼───────────────────┼─────────────────────┤
979 │ │ │ │
980 │miss │ hit │ Read from │
981 │ │ │ secondary, write to │
982 │ │ │ primary[2] │
983 ├────────────────┼───────────────────┼─────────────────────┤
984 │ │ │ │
985 │hit │ - │ Read from primary, │
986 │ │ │ don’t write to │
987 │ │ │ secondary[3] │
988 └────────────────┴───────────────────┴─────────────────────┘
989 [1] Unless secondary storage has attribute read-only=true.
991 [2] Unless secondary storage has attribute share-hits=false.
992 [3] Unless primary storage is set to share its cache hits with the
993 reshare option.
994 File storage backend
996 URL format: file:DIRECTORY or file://DIRECTORY
997 This backend stores data as separate files in a directory structure
999 below DIRECTORY (an absolute path), similar (but not identical) to the
1000 primary cache storage. A typical use case for this backend would be
1001 sharing a cache on an NFS directory.
1002 Important
1004 ccache will not perform any cleanup of the storage — that has to be
1005 done by other means, for instance by running ccache --trim-dir
1006 periodically.
1007 Examples:
1009 • file:/shared/nfs/directory
1011 • file:///shared/nfs/directory|umask=002|update-mtime=true
1013 Optional attributes:
1015 • layout: How to store file under the cache directory. Available
1017 values:
1018 • flat: Store all files directly under the cache directory.
1020 • subdirs: Store files in 256 subdirectories of the cache
1022 directory.
1023 The default is subdirs.
1025 • umask: This attribute (an octal integer) overrides the umask to use
1027 for files and directories in the cache directory.
1028 • update-mtime: If true, update the modification time (mtime) of
1030 cache entries that are read. The default is false.
1031 HTTP storage backend
1033 URL format: http://HOST[:PORT][/PATH]
1034 This backend stores data in an HTTP-compatible server. The required
1036 HTTP methods are GET, PUT and DELETE.
1037 Important
1039 ccache will not perform any cleanup of the storage — that has to be
1040 done by other means, for instance by running ccache --trim-dir
1041 periodically.
1042 Note
1044 HTTPS is not supported.
1045 Tip
1047 See How to set up HTTP storage
1048 <https://ccache.dev/howto/http-storage.html> for hints on how to
1049 set up an HTTP server for use with ccache.
1050 Examples:
1052 • http://localhost
1054 • http://someusername:p4ssw0rd@example.com/cache/
1056 • http://localhost:8080|layout=bazel|connect-timeout=50
1058 Optional attributes:
1060 • connect-timeout: Timeout (in ms) for network connection. The
1062 default is 100.
1063 • keep-alive: If true, keep the HTTP connection to the storage server
1065 open to avoid reconnects. The default is false.
1066 Note
1068 Connection keep-alive is disabled by default because with the
1069 current HTTP implementation uploads to the remote end might
1070 fail in case the server closes the connection due to a
1071 keep-alive timeout. If the general case with short compilation
1072 times should be accelerated or the server is configured with a
1073 long-enough timeout, then connection keep-alive could be
1074 enabled.
1075 • layout: How to map key names to the path part of the URL. Available
1077 values:
1078 • bazel: Store values in a format compatible with the Bazel HTTP
1080 caching protocol. More specifically, the entries will be stored
1081 as 64 hex digits under the /ac/ part of the cache.
1082 Note
1084 You may have to disable verification of action cache values
1085 in the server for this to work since ccache entries are not
1086 valid action result metadata values.
1087 • flat: Append the key directly to the path part of the URL (with
1089 a leading slash if needed).
1090 • subdirs: Append the first two characters of the key to the URL
1092 (with a leading slash if needed), followed by a slash and the
1093 rest of the key. This divides the entries into 256 buckets.
1094 The default is subdirs.
1096 • operation-timeout: Timeout (in ms) for HTTP requests. The default
1098 is 10000.
1099 Redis storage backend
1101 URL format: redis://[[USERNAME:]PASSWORD@]HOST[:PORT][/DBNUMBER]
1102 This backend stores data in a Redis <https://redis.io> (or
1104 Redis-compatible) server. There are implementations for both
1105 memory-based and disk-based storage. PORT defaults to 6379 and DBNUMBER
1106 defaults to 0.
1107 Note
1109 ccache will not perform any cleanup of the Redis storage, but you
1110 can configure LRU eviction <https://redis.io/topics/lru-cache>.
1111 Tip
1113 See How to set up Redis
1114 <https://ccache.dev/howto/redis-storage.html> storage" for hints
1115 on setting up a Redis server for use with ccache.
1116 Tip
1118 You can set up a cluster of Redis servers using the shards
1119 attribute described in [_secondary_storage_backends].
1120 Examples:
1122 • redis://localhost
1124 • redis://p4ssw0rd@cache.example.com:6379/0|connect-timeout=50
1126 Optional attributes:
1128 • connect-timeout: Timeout (in ms) for network connection. The
1130 default is 100.
1131 • operation-timeout: Timeout (in ms) for Redis commands. The default
1133 is 10000.
1134
1136 By default, ccache has a 5 GB limit on the total size of files in the
1137 cache and no limit on the number of files. You can set different limits
1138 using the command line options -M/--max-size and -F/--max-files. Use
1139 the -s/--show-stats option to see the cache size and the currently
1140 configured limits (in addition to other various statistics).
1141 Cleanup can be triggered in two different ways: automatic and manual.
1143 Automatic cleanup
1145 Ccache maintains counters for various statistics about the cache,
1146 including the size and number of all cached files. In order to improve
1147 performance and reduce issues with concurrent ccache invocations, there
1148 is one statistics file for each of the sixteen subdirectories in the
1149 cache.
1150 After a new compilation result has been written to the cache, ccache
1152 will update the size and file number statistics for the subdirectory
1153 (one of sixteen) to which the result was written. Then, if the size
1154 counter for said subdirectory is greater than max_size / 16 or the file
1155 number counter is greater than max_files / 16, automatic cleanup is
1156 triggered.
1157 When automatic cleanup is triggered for a subdirectory in the cache,
1159 ccache will:
1160 1. Count all files in the subdirectory and compute their aggregated
1162 size.
1163 2. Remove files in LRU (least recently used) order until the size is
1165 at most limit_multiple * max_size / 16 and the number of files is
1166 at most limit_multiple * max_files / 16, where limit_multiple,
1167 max_size and max_files are configuration options.
1168 3. Set the size and file number counters to match the files that were
1170 kept.
1171 The reason for removing more files than just those needed to not exceed
1173 the max limits is that a cleanup is a fairly slow operation, so it
1174 would not be a good idea to trigger it often, like after each cache
1175 miss.
1176 Manual cleanup
1178 You can run ccache -c/--cleanup to force cleanup of the whole cache,
1179 i.e. all of the sixteen subdirectories. This will recalculate the
1180 statistics counters and make sure that the configuration options
1181 max_size and max_files are not exceeded. Note that limit_multiple is
1182 not taken into account for manual cleanup.
1183
1185 Ccache will by default compress all data it puts into the cache using
1186 the compression algorithm Zstandard <http://zstd.net> (zstd) using
1187 compression level 1. The algorithm is fast enough that there should be
1188 little reason to turn off compression to gain performance. One
1189 exception is if the cache is located on a compressed file system, in
1190 which case the compression performed by ccache of course is redundant.
1191 See the documentation for the configuration options compression and
1192 compression_level for more information.
1193 You can use the command line option -x/--show-compression to print
1195 information related to compression. Example:
1196 Total data: 14.8 GB (16.0 GB disk blocks)
1198 Compressed data: 11.3 GB (30.6% of original size)
1199 Original size: 36.9 GB
1200 Compression ratio: 3.267 x (69.4% space savings)
1201 Incompressible data: 3.5 GB
1202 Notes:
1204 • The “disk blocks” size is the cache size when taking disk block
1206 size into account. This value should match the “Cache size” value
1207 from “ccache --show-stats”. The other size numbers refer to actual
1208 content sizes.
1209 • “Compressed data” refers to result and manifest files stored in the
1211 cache.
1212 • “Incompressible data” refers to files that are always stored
1214 uncompressed (triggered by enabling file_clone or hard_link) or
1215 unknown files (for instance files created by older ccache
1216 versions).
1217 • The compression ratio is affected by compression_level.
1219 The cache data can also be recompressed to another compression level
1221 (or made uncompressed) with the command line option -X/--recompress. If
1222 you choose to disable compression by default or to use a low
1223 compression level, you can (re)compress newly cached data with a higher
1224 compression level after the build or at another time when there are
1225 more CPU cycles available, for instance every night. Full recompression
1226 potentially takes a lot of time, but only files that are currently
1227 compressed with a different level than the target level will be
1228 recompressed.
1229
1231 ccache --show-stats shows a summary of statistics, including cache
1232 size, cleanups (number of performed cleanups, either implicitly due to
1233 a cache size limit being reached or due to explicit ccache -c calls),
1234 overall hit rate, hit rate for direct/preprocessed modes and hit rate
1235 for primary and secondary storage.
1236 The summary also includes counters called “Errors” and “Uncacheable”,
1238 which are sums of more detailed counters. To see those detailed
1239 counters, use the -v/--verbose flag. The verbose mode can show the
1240 following counters:
1241 ┌───────────────────────────┬────────────────────────────┐
1243 │ │ │
1244 │Counter │ Description │
1245 ├───────────────────────────┼────────────────────────────┤
1246 │ │ │
1247 │Autoconf compile/link │ Uncacheable compilation or │
1248 │ │ linking by an Autoconf │
1249 │ │ test. │
1250 ├───────────────────────────┼────────────────────────────┤
1251 │ │ │
1252 │Bad compiler arguments │ Malformed compiler │
1253 │ │ argument, e.g. missing a │
1254 │ │ value for a compiler │
1255 │ │ option that requires an │
1256 │ │ argument or failure to │
1257 │ │ read a file specified by a │
1258 │ │ compiler option argument. │
1259 ├───────────────────────────┼────────────────────────────┤
1260 │ │ │
1261 │Called for linking │ The compiler was called │
1262 │ │ for linking, not │
1263 │ │ compiling. Ccache only │
1264 │ │ supports compilation of a │
1265 │ │ single file, i.e. calling │
1266 │ │ the compiler with the -c │
1267 │ │ option to produce a single │
1268 │ │ object file from a single │
1269 │ │ source file. │
1270 ├───────────────────────────┼────────────────────────────┤
1271 │ │ │
1272 │Called for preprocessing │ The compiler was called │
1273 │ │ for preprocessing, not │
1274 │ │ compiling. │
1275 ├───────────────────────────┼────────────────────────────┤
1276 │ │ │
1277 │Could not use modules │ Preconditions for using │
1278 │ │ [_c_modules] were not │
1279 │ │ fulfilled. │
1280 ├───────────────────────────┼────────────────────────────┤
1281 │ │ │
1282 │Could not use precompiled │ Preconditions for using │
1283 │header │ precompiled headers were │
1284 │ │ not fulfilled. │
1285 ├───────────────────────────┼────────────────────────────┤
1286 │ │ │
1287 │Could not write to output │ The output path specified │
1288 │file │ with -o is not a file │
1289 │ │ (e.g. a directory or a │
1290 │ │ device node). │
1291 ├───────────────────────────┼────────────────────────────┤
1292 │ │ │
1293 │Compilation failed │ The compilation failed. No │
1294 │ │ result stored in the │
1295 │ │ cache. │
1296 ├───────────────────────────┼────────────────────────────┤
1297 │ │ │
1298 │Compiler check failed │ A compiler check program │
1299 │ │ specified by │
1300 │ │ compiler_check │
1301 │ │ (CCACHE_COMPILERCHECK) │
1302 │ │ failed. │
1303 ├───────────────────────────┼────────────────────────────┤
1304 │ │ │
1305 │Compiler produced empty │ The compiler’s output file │
1306 │output │ (typically an object file) │
1307 │ │ was empty after │
1308 │ │ compilation. │
1309 ├───────────────────────────┼────────────────────────────┤
1310 │ │ │
1311 │Compiler produced no │ The compiler’s output file │
1312 │output │ (typically an object file) │
1313 │ │ was missing after │
1314 │ │ compilation. │
1315 ├───────────────────────────┼────────────────────────────┤
1316 │ │ │
1317 │Compiler produced stdout │ The compiler wrote data to │
1318 │ │ standard output. This is │
1319 │ │ something that compilers │
1320 │ │ normally never do, so │
1321 │ │ ccache is not designed to │
1322 │ │ store such output in the │
1323 │ │ cache. │
1324 ├───────────────────────────┼────────────────────────────┤
1325 │ │ │
1326 │Could not find the │ The compiler to execute │
1327 │compiler │ could not be found. │
1328 ├───────────────────────────┼────────────────────────────┤
1329 │ │ │
1330 │Error hashing extra file │ Failure reading a file │
1331 │ │ specified by │
1332 │ │ extra_files_to_hash │
1333 │ │ (CCACHE_EXTRAFILES). │
1334 ├───────────────────────────┼────────────────────────────┤
1335 │ │ │
1336 │Forced recache │ CCACHE_RECACHE was used to │
1337 │ │ overwrite an existing │
1338 │ │ result. │
1339 ├───────────────────────────┼────────────────────────────┤
1340 │ │ │
1341 │Internal error │ Unexpected failure, e.g. │
1342 │ │ due to problems │
1343 │ │ reading/writing the cache. │
1344 ├───────────────────────────┼────────────────────────────┤
1345 │ │ │
1346 │Missing cache file │ A file was unexpectedly │
1347 │ │ missing from the cache. │
1348 │ │ This only happens in rare │
1349 │ │ situations, e.g. if one │
1350 │ │ ccache instance is about │
1351 │ │ to get a file from the │
1352 │ │ cache while another │
1353 │ │ instance removed the file │
1354 │ │ as part of cache cleanup. │
1355 ├───────────────────────────┼────────────────────────────┤
1356 │ │ │
1357 │Multiple source files │ The compiler was called to │
1358 │ │ compile multiple source │
1359 │ │ files in one go. This is │
1360 │ │ not supported by ccache. │
1361 ├───────────────────────────┼────────────────────────────┤
1362 │ │ │
1363 │No input file │ No input file was │
1364 │ │ specified to the compiler. │
1365 ├───────────────────────────┼────────────────────────────┤
1366 │ │ │
1367 │Output to stdout │ The compiler was │
1368 │ │ instructed to write its │
1369 │ │ output to standard output │
1370 │ │ using -o -. This is not │
1371 │ │ supported by ccache. │
1372 ├───────────────────────────┼────────────────────────────┤
1373 │ │ │
1374 │Preprocessing failed │ Preprocessing the source │
1375 │ │ code using the compiler’s │
1376 │ │ -E option failed. │
1377 ├───────────────────────────┼────────────────────────────┤
1378 │ │ │
1379 │Unsupported code directive │ Code like the assembler │
1380 │ │ .incbin directive was │
1381 │ │ found. This is not │
1382 │ │ supported by ccache. │
1383 ├───────────────────────────┼────────────────────────────┤
1384 │ │ │
1385 │Unsupported compiler │ A compiler option not │
1386 │option │ supported by ccache was │
1387 │ │ found. │
1388 ├───────────────────────────┼────────────────────────────┤
1389 │ │ │
1390 │Unsupported source │ A source language e.g. │
1391 │language │ specified with -x was │
1392 │ │ unsupported by ccache. │
1393 └───────────────────────────┴────────────────────────────┘
1394
1396 The basic idea is to detect when you are compiling exactly the same
1397 code a second time and reuse the previously produced output. The
1398 detection is done by hashing different kinds of information that should
1399 be unique for the compilation and then using the hash sum to identify
1400 the cached output. Ccache uses BLAKE3, a very fast cryptographic hash
1401 algorithm, for the hashing. On a cache hit, ccache is able to supply
1402 all of the correct compiler outputs (including all warnings, dependency
1403 file, etc) from the cache. Data stored in the cache is checksummed with
1404 XXH3, an extremely fast non-cryptographic algorithm, to detect
1405 corruption.
1406 Ccache has two ways of gathering information used to look up results in
1408 the cache:
1409 • the preprocessor mode, where ccache runs the preprocessor on the
1411 source code and hashes the result
1412 • the direct mode, where ccache hashes the source code and include
1414 files directly
1415 The direct mode is generally faster since running the preprocessor has
1417 some overhead.
1418 If no previous result is detected (i.e., there is a cache miss) using
1420 the direct mode, ccache will fall back to the preprocessor mode unless
1421 the depend mode is enabled. In the depend mode, ccache never runs the
1422 preprocessor, not even on cache misses. Read more in [_the_depend_mode]
1423 below.
1424 Common hashed information
1426 The following information is always included in the hash:
1427 • the extension used by the compiler for a file with preprocessor
1429 output (normally .i for C code and .ii for C++ code)
1430 • the compiler’s size and modification time (or other
1432 compiler-specific information specified by compiler_check)
1433 • the name of the compiler
1435 • the current directory (if hash_dir is enabled)
1437 • contents of files specified by extra_files_to_hash (if any)
1439 The preprocessor mode
1441 In the preprocessor mode, the hash is formed of the common information
1442 and:
1443 • the preprocessor output from running the compiler with -E
1445 • the command line options except those that affect include files
1447 (-I, -include, -D, etc; the theory is that these command line
1448 options will change the preprocessor output if they have any effect
1449 at all)
1450 • any standard error output generated by the preprocessor
1452 Based on the hash, the cached compilation result can be looked up
1454 directly in the cache.
1455 The direct mode
1457 In the direct mode, the hash is formed of the common information and:
1458 • the input source file
1460 • the compiler options
1462 Based on the hash, a data structure called “manifest” is looked up in
1464 the cache. The manifest contains:
1465 • references to cached compilation results (object file, dependency
1467 file, etc) that were produced by previous compilations that matched
1468 the hash
1469 • paths to the include files that were read at the time the
1471 compilation results were stored in the cache
1472 • hash sums of the include files at the time the compilation results
1474 were stored in the cache
1475 The current contents of the include files are then hashed and compared
1477 to the information in the manifest. If there is a match, ccache knows
1478 the result of the compilation. If there is no match, ccache falls back
1479 to running the preprocessor. The output from the preprocessor is parsed
1480 to find the include files that were read. The paths and hash sums of
1481 those include files are then stored in the manifest along with
1482 information about the produced compilation result.
1483 There is a catch with the direct mode: header files that were used by
1485 the compiler are recorded, but header files that were not used, but
1486 would have been used if they existed, are not. So, when ccache checks
1487 if a result can be taken from the cache, it currently can’t check if
1488 the existence of a new header file should invalidate the result. In
1489 practice, the direct mode is safe to use in the absolute majority of
1490 cases.
1491 The direct mode will be disabled if any of the following holds:
1493 • direct_mode is false
1495 • a modification time of one of the include files is too new (needed
1497 to avoid a race condition)
1498 • a compiler option not supported by the direct mode is used:
1500 • a -Wp,* compiler option other than -Wp,-MD,<path>,
1502 -Wp,-MMD,<path> and -Wp,-D<define>
1503 • -Xpreprocessor
1505 • the string __TIME__ is present in the source code
1507 The depend mode
1509 If the depend mode is enabled, ccache will not use the preprocessor at
1510 all. The hash used to identify results in the cache will be based on
1511 the direct mode hash described above plus information about include
1512 files read from the dependency file generated by the compiler with -MD
1513 or -MMD.
1514 Advantages:
1516 • The ccache overhead of a cache miss will be much smaller.
1518 • Not running the preprocessor at all can be good if compilation is
1520 performed remotely, for instance when using distcc or similar;
1521 ccache then won’t make potentially costly preprocessor calls on the
1522 local machine.
1523 Disadvantages:
1525 • The cache hit rate will likely be lower since any change to
1527 compiler options or source code will make the hash different.
1528 Compare this with the default setup where ccache will fall back to
1529 the preprocessor mode, which is tolerant to some types of changes
1530 of compiler options and source code changes.
1531 • If -MD is used, the manifest entries will include system header
1533 files as well, thus slowing down cache hits slightly, just as using
1534 -MD slows down make.
1535 • If -MMD is used, the manifest entries will not include system
1537 header files, which means ccache will ignore changes in them.
1538 The depend mode will be disabled if any of the following holds:
1540 • depend_mode is false.
1542 • run_second_cpp is false.
1544 • The compiler is not generating dependencies using -MD or -MMD.
1546
1548 If modification time (mtime) or status change time (ctime) of one of
1549 the include files is the same second as the time compilation is being
1550 done, ccache disables the direct mode (or, in the case of a precompiled
1551 header, disables caching completely). This done as a safety measure to
1552 avoid a race condition (see below).
1553 To be able to use a newly created header files in direct mode (or use a
1555 newly precompiled header), either:
1556 • create the include file earlier in the build process, or
1558 • set sloppiness to include_file_ctime,include_file_mtime if you are
1560 willing to take the risk, for instance if you know that your build
1561 system is robust enough not to trigger the race condition.
1562 For reference, the race condition mentioned above consists of these
1564 events:
1565 1. The preprocessor is run.
1567 2. An include file is modified by someone.
1569 3. The new include file is hashed by ccache.
1571 4. The real compiler is run on the preprocessor’s output, which
1573 contains data from the old header file.
1574 5. The wrong object file is stored in the cache.
1576
1578 To find out what information ccache actually is hashing, you can enable
1579 the debug mode via the configuration option debug or by setting
1580 CCACHE_DEBUG in the environment. This can be useful if you are
1581 investigating why you don’t get cache hits. Note that performance will
1582 be reduced slightly.
1583 When the debug mode is enabled, ccache will create up to five
1585 additional files next to the object file:
1586 ┌───────────────────────────────┬───────────────────────────┐
1588 │ │ │
1589 │Filename │ Description │
1590 ├───────────────────────────────┼───────────────────────────┤
1591 │ │ │
1592 │<objectfile>.ccache-input-c │ Binary input hashed by │
1593 │ │ both the direct mode and │
1594 │ │ the preprocessor mode. │
1595 ├───────────────────────────────┼───────────────────────────┤
1596 │ │ │
1597 │<objectfile>.ccache-input-d │ Binary input only hashed │
1598 │ │ by the direct mode. │
1599 ├───────────────────────────────┼───────────────────────────┤
1600 │ │ │
1601 │<objectfile>.ccache-input-p │ Binary input only hashed │
1602 │ │ by the preprocessor mode. │
1603 ├───────────────────────────────┼───────────────────────────┤
1604 │ │ │
1605 │<objectfile>.ccache-input-text │ Human-readable combined │
1606 │ │ diffable text version of │
1607 │ │ the three files above. │
1608 ├───────────────────────────────┼───────────────────────────┤
1609 │ │ │
1610 │<objectfile>.ccache-log │ Log for this object file. │
1611 └───────────────────────────────┴───────────────────────────┘
1612 If config_dir (environment variable CCACHE_DEBUGDIR) is set, the files
1614 above will be written to that directory with full absolute paths
1615 instead of next to the object file.
1616 In the direct mode, ccache uses the 160 bit BLAKE3 hash of the
1618 “ccache-input-c” + “ccache-input-d” data (where + means concatenation),
1619 while the “ccache-input-c” + “ccache-input-p” data is used in the
1620 preprocessor mode.
1621 The “ccache-input-text” file is a combined text version of the three
1623 binary input files. It has three sections (“COMMON”, “DIRECT MODE” and
1624 “PREPROCESSOR MODE”), which is turn contain annotations that say what
1625 kind of data comes next.
1626 To debug why you don’t get an expected cache hit for an object file,
1628 you can do something like this:
1629 1. Build with debug mode enabled.
1631 2. Save the <objectfile>.ccache-* files.
1633 3. Build again with debug mode enabled.
1635 4. Compare <objectfile>.ccache-input-text for the two builds. This
1637 together with the <objectfile>.ccache-log files should give you
1638 some clues about what is happening.
1639
1641 Some information included in the hash that identifies a unique
1642 compilation can contain absolute paths:
1643 • The preprocessed source code may contain absolute paths to include
1645 files if the compiler option -g is used or if absolute paths are
1646 given to -I and similar compiler options.
1647 • Paths specified by compiler options (such as -I, -MF, etc) on the
1649 command line may be absolute.
1650 • The source code file path may be absolute, and that path may
1652 substituted for __FILE__ macros in the source code or included in
1653 warnings emitted to standard error by the preprocessor.
1654 This means that if you compile the same code in different locations,
1656 you can’t share compilation results between the different build
1657 directories since you get cache misses because of the absolute build
1658 directory paths that are part of the hash.
1659 Here’s what can be done to enable cache hits between different build
1661 directories:
1662 • If you build with -g (or similar) to add debug information to the
1664 object file, you must either:
1665 • use the compiler option -fdebug-prefix-map=<old>=<new> for
1667 relocating debug info to a common prefix (e.g.
1668 -fdebug-prefix-map=$PWD=.); or
1669 • set hash_dir = false.
1671 • If you use absolute paths anywhere on the command line (e.g. the
1673 source code file path or an argument to compiler options like -I
1674 and -MF), you must set base_dir to an absolute path to a “base
1675 directory”. Ccache will then rewrite absolute paths under that
1676 directory to relative before computing the hash.
1677
1679 Ccache has support for GCC’s precompiled headers. However, you have to
1680 do some things to make it work properly:
1681 • You must set sloppiness to pch_defines,time_macros. The reason is
1683 that ccache can’t tell whether __TIME__, __DATE__ or __TIMESTAMP__
1684 is used when using a precompiled header. Further, it can’t detect
1685 changes in #defines in the source code because of how preprocessing
1686 works in combination with precompiled headers.
1687 • You may also want to include include_file_mtime,include_file_ctime
1689 in sloppiness. See [_handling_of_newly_created_header_files].
1690 • You must either:
1692 • use the compiler option -include to include the precompiled
1694 header (i.e., don’t use #include in the source code to include
1695 the header; the filename itself must be sufficient to find the
1696 header, i.e. -I paths are not searched); or
1697 • (for the Clang compiler) use the compiler option -include-pch
1699 to include the PCH file generated from the precompiled header;
1700 or
1701 • (for the GCC compiler) add the compiler option -fpch-preprocess
1703 when compiling.
1704 If you don’t do this, either the non-precompiled version of the
1706 header file will be used (if available) or ccache will fall back to
1707 running the real compiler and increase the statistics counter
1708 “Preprocessing failed” (if the non-precompiled header file is not
1709 available).
1710
1712 Ccache has support for Clang’s -fmodules option. In practice ccache
1713 only additionally hashes module.modulemap files; it does not know how
1714 Clang handles its cached binary form of modules so those are ignored.
1715 This should not matter in practice: as long as everything else
1716 (including module.modulemap files) is the same the cached result should
1717 work. Still, you must set sloppiness to modules to allow caching.
1718 You must use both direct mode and depend mode. When using the
1720 preprocessor mode Clang does not provide enough information to allow
1721 hashing of module.modulemap files.
1722
1724 A group of developers can increase the cache hit rate by sharing a
1725 cache directory. To share a cache without unpleasant side effects, the
1726 following conditions should to be met:
1727 • Use the same cache directory.
1729 • Make sure that the configuration option hard_link is false (which
1731 is the default).
1732 • Make sure that all users are in the same group.
1734 • Set the configuration option umask to 002. This ensures that cached
1736 files are accessible to everyone in the group.
1737 • Make sure that all users have write permission in the entire cache
1739 directory (and that you trust all users of the shared cache).
1740 • Make sure that the setgid bit is set on all directories in the
1742 cache. This tells the filesystem to inherit group ownership for new
1743 directories. The following command might be useful for this:
1744 find $CCACHE_DIR -type d | xargs chmod g+s
1746 The reason to avoid the hard link mode is that the hard links cause
1748 unwanted side effects, as all links to a cached file share the file’s
1749 modification timestamp. This results in false dependencies to be
1750 triggered by timestamp-based build systems whenever another user links
1751 to an existing file. Typically, users will see that their libraries and
1752 binaries are relinked without reason.
1753 You may also want to make sure that a base directory is set
1755 appropriately, as discussed in a previous section.
1756
1758 It is possible to put the cache directory on an NFS filesystem (or
1759 similar filesystems), but keep in mind that:
1760 • Having the cache on NFS may slow down compilation. Make sure to do
1762 some benchmarking to see if it’s worth it.
1763 • Ccache hasn’t been tested very thoroughly on NFS.
1765 A tip is to set temporary_dir to a directory on the local host to avoid
1767 NFS traffic for temporary files.
1768 It is recommended to use the same operating system version when using a
1770 shared cache. If operating system versions are different then system
1771 include files will likely be different and there will be few or no
1772 cache hits between the systems. One way of improving cache hit rate in
1773 that case is to set sloppiness to system_headers to ignore system
1774 headers.
1775 An alternative to putting the main cache directory on NFS is to set up
1777 a secondary storage file cache.
1778
1780 The recommended way of combining ccache with another compiler wrapper
1781 (such as “distcc”) is by letting ccache execute the compiler wrapper.
1782 This is accomplished by defining prefix_command, for example by setting
1783 the environment variable CCACHE_PREFIX to the name of the wrapper (e.g.
1784 distcc). Ccache will then prefix the command line with the specified
1785 command when running the compiler. To specify several prefix commands,
1786 set prefix_command to a colon-separated list of commands.
1787 Unless you set compiler_check to a suitable command (see the
1789 description of that configuration option), it is not recommended to use
1790 the form ccache anotherwrapper compiler args as the compilation
1791 command. It’s also not recommended to use the masquerading technique
1792 for the other compiler wrapper. The reason is that by default, ccache
1793 will in both cases hash the mtime and size of the other wrapper instead
1794 of the real compiler, which means that:
1795 • Compiler upgrades will not be detected properly.
1797 • The cached results will not be shared between compilations with and
1799 without the other wrapper.
1800 Another minor thing is that if prefix_command is used, ccache will not
1802 invoke the other wrapper when running the preprocessor, which increases
1803 performance. You can use prefix_command_cpp if you also want to invoke
1804 the other wrapper when doing preprocessing (normally by adding -E).
1805
1807 • The direct mode fails to pick up new header files in some rare
1808 scenarios. See [_the_direct_mode] above.
1809
1811 General
1812 A general tip for getting information about what ccache is doing is to
1813 enable debug logging by setting the configuration option debug (or the
1814 environment variable CCACHE_DEBUG); see [_cache_debugging] for more
1815 information. Another way of keeping track of what is happening is to
1816 check the output of ccache -s.
1817 Performance
1819 Ccache has been written to perform well out of the box, but sometimes
1820 you may have to do some adjustments of how you use the compiler and
1821 ccache in order to improve performance.
1822 Since ccache works best when I/O is fast, put the cache directory on a
1824 fast storage device if possible. Having lots of free memory so that
1825 files in the cache directory stay in the disk cache is also preferable.
1826 A good way of monitoring how well ccache works is to run ccache -s
1828 before and after your build and then compare the statistics counters.
1829 Here are some common problems and what may be done to increase the hit
1830 rate:
1831 • If the counter for preprocessed cache hits has been incremented
1833 instead of the one for direct cache hits, ccache has fallen back to
1834 preprocessor mode, which is generally slower. Some possible reasons
1835 are:
1836 • The source code has been modified in such a way that the
1838 preprocessor output is not affected.
1839 • Compiler arguments that are hashed in the direct mode but not
1841 in the preprocessor mode have changed (-I, -include, -D, etc)
1842 and they didn’t affect the preprocessor output.
1843 • The compiler option -Xpreprocessor or -Wp,* (except
1845 -Wp,-MD,<path>, -Wp,-MMD,<path>, and -Wp,-D<define>) is used.
1846 • This was the first compilation with a new value of the base
1848 directory.
1849 • A modification or status change time of one of the include
1851 files is too new (created the same second as the compilation is
1852 being done). See [_handling_of_newly_created_header_files].
1853 • The __TIME__ preprocessor macro is (potentially) being used.
1855 Ccache turns off direct mode if __TIME__ is present in the
1856 source code. This is done as a safety measure since the string
1857 indicates that a __TIME__ macro may affect the output. (To be
1858 sure, ccache would have to run the preprocessor, but the sole
1859 point of the direct mode is to avoid that.) If you know that
1860 __TIME__ isn’t used in practise, or don’t care if ccache
1861 produces objects where __TIME__ is expanded to something in the
1862 past, you can set sloppiness to time_macros.
1863 • The __DATE__ preprocessor macro is (potentially) being used and
1865 the date has changed. This is similar to how __TIME__ is
1866 handled. If __DATE__ is present in the source code, ccache
1867 hashes the current date in order to be able to produce the
1868 correct object file if the __DATE__ macro affects the output.
1869 If you know that __DATE__ isn’t used in practise, or don’t care
1870 if ccache produces objects where __DATE__ is expanded to
1871 something in the past, you can set sloppiness to time_macros.
1872 • The __TIMESTAMP__ preprocessor macro is (potentially) being
1874 used and the source file’s modification time has changed. This
1875 is similar to how __TIME__ is handled. If __TIMESTAMP__ is
1876 present in the source code, ccache hashes the string
1877 representation of the source file’s modification time in order
1878 to be able to produce the correct object file if the
1879 __TIMESTAMP__ macro affects the output. If you know that
1880 __TIMESTAMP__ isn’t used in practise, or don’t care if ccache
1881 produces objects where __TIMESTAMP__ is expanded to something
1882 in the past, you can set sloppiness to time_macros.
1883 • The input file path has changed. Ccache includes the input file
1885 path in the direct mode hash to be able to take relative
1886 include files into account and to produce a correct object file
1887 if the source code includes a __FILE__ macro.
1888 • If a cache hit counter was not incremented even though the same
1890 code has been compiled and cached before, ccache has either
1891 detected that something has changed anyway or a cleanup has been
1892 performed (either explicitly or implicitly when a cache limit has
1893 been reached). Some perhaps unobvious things that may result in a
1894 cache miss are usage of __TIME__, __DATE__ or __TIMESTAMP__ macros,
1895 or use of automatically generated code that contains a timestamp,
1896 build counter or other volatile information.
1897 • If “Multiple source files” has been incremented, it’s an indication
1899 that the compiler has been invoked on several source code files at
1900 once. Ccache doesn’t support that. Compile the source code files
1901 separately if possible.
1902 • If “Unsupported compiler option” has been incremented, enable debug
1904 logging and check which compiler option was rejected.
1905 • If “Preprocessing failed” has been incremented, one possible reason
1907 is that precompiled headers are being used. See
1908 [_precompiled_headers] for how to remedy this.
1909 • If “Could not use precompiled header” has been incremented, see
1911 [_precompiled_headers].
1912 • If “Could not use modules” has been incremented, see [_c_modules].
1914 Corrupt object files
1916 It should be noted that ccache is susceptible to general storage
1917 problems. If a bad object file sneaks into the cache for some reason,
1918 it will of course stay bad. Some possible reasons for erroneous object
1919 files are bad hardware (disk drive, disk controller, memory, etc),
1920 buggy drivers or file systems, a bad prefix_command or compiler
1921 wrapper. If this happens, the easiest way of fixing it is this:
1922 1. Build so that the bad object file ends up in the build tree.
1924 2. Remove the bad object file from the build tree.
1926 3. Rebuild with CCACHE_RECACHE set.
1928 An alternative is to clear the whole cache with ccache -C if you don’t
1930 mind losing other cached results.
1931 There are no reported issues about ccache producing broken object files
1933 reproducibly. That doesn’t mean it can’t happen, so if you find a
1934 repeatable case, please report it.
1935
1937 Credits, mailing list information, bug reporting instructions, source
1938 code, etc, can be found on ccache’s web site: https://ccache.dev.
1939
1941 Ccache was originally written by Andrew Tridgell and is currently
1942 developed and maintained by Joel Rosdahl. See AUTHORS.txt or
1943 AUTHORS.html and https://ccache.dev/credits.html for a list of
1944 contributors.
1945Ccache 4.5.1 2022-01-19 CCACHE(1)