Hi ccache folks,

I'm trying to optimize the ccache usage of a project I'm working on
(coreboot.org). ccache already does a splendid job for one-shot builds
(thank you for that!) but I've found an interesting corner case in our
automated builds.

To begin with, our incredibly complex Makefiles assume that you run
make from the top of our tree. But you can specify a specific build
directory $(obj) where all the output is stored. Our automated builds
run many processes in parallel, each with a different configuration
file and build directory.

We make the configuration accessible to C code with a generated header
file `$(obj)/config.h`. And here is the problem, as this file is inclu-
ded in all source files but not all changes affect all source files, you
might expect some "preprocessed" hits. But there aren't any, because the
differing path to the `config.h` ends up in two hashed places:

 1. In those #-lines in the preprocessor output.
 2. In dependency files we let GCC generate through `-MMD`.

If I'm looking at the right spot in the code, I can see that 1. happens
on purpose (in process_preprocessed_file(), ccache.c:945). Though, I
wonder why? I wouldn't expect that it matters for the preprocessed case,
with the same argument that allows us to skip hashing `-I` etc. parame-
ters from the compiler command line: If it would matter, it would affect
the actual code after preprocessing as well.

Maybe these lines could affect the object files, but it doesn't in our
case. If it can affect the object files, maybe we could still add an
option to skip the hashing of these paths?

Another thought: Could this be handled with the `base_dir` normali-
zation? I already tried to set $(obj) as base_dir, without success.
I guess it would require to normalize paths relative to `base_dir`
even if they are not under `base_dir`.

For 2., I know we can skip our `config.h` in the dependency file by
treating it as a system header. But maybe somebody knows a better way?


ccache mailing list

Reply via email to