[ccache] direct mode

Joel Rosdahl joel at rosdahl.net
Sun Oct 27 14:03:23 MDT 2013


On 23 October 2013 12:01, Andrew Stubbs <ams at codesourcery.com> wrote:

> I've thought about this a little, since our last exchange.


Thanks! Sounds like the best solution so far.

Some thoughts:


> 1. When running the preprocessor, on cache-miss, use -v the capture the
> compiler's search path. This ought to be almost zero extra cost.


This only works with very GCC-like compilers. For instance, ccache
currently works with Solaris's compiler as well, and it doesn't support -v.
Although I have written "Only works with GCC and compilers that behave
similar enough" in the documentation, it would be nice to continue
supporting other slightly less GCC-like compilers if possible.

2. For each header file found in the preprocessed source, record the
> directories in which the compiler did *not* find that file.
> [...]
> 4. On cache-lookup, load the manifest file, and do
> "access(potential_include_file, R_OK)" for each include path listed in the
> manifest. If any call comes back non-zero then skip direct mode.


I don't think that it's possible to calculate potential_include_file
correctly in all cases with only the information from -E -v. Consider this
.c file:

#include <foo/bar.h>

When compiling with "-I/example/foo -I/example", "gcc -E -v" will give
something like this:

#include "..." search starts here:
#include <...> search starts here:
 /example/foo
 /example
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include

Assume that /example/foo/foo/bar.h doesn't exist and that
/example/foo/bar.h exists. The preprocessed output will indicate that
/example/foo/bar.h was read. Which directories where the header wasn't
found should we store in the manifest? The correct answer is
"/example/foo", which I don't see how ccache can conclude from the
available information.

In terms of false negatives, it's hard to tell the difference between ""
> and <> includes (in which the search path starts in a different place), and
> it'll be suboptimal where the user's source contains explicit paths to
> header files.


Right.

I do think the problems are quite minor, though - your proposal is
certainly better than no detection mechanism, and it will hopefully cover
the absolute majority of use cases in practice.

Regarding how to know whether we can pass compiler-specific options like
-v, I have had some thoughts about that some years ago, see comment 3 on
https://bugzilla.samba.org/show_bug.cgi?id=7556#c3.

-- Joel


More information about the ccache mailing list