Re: [ccache] Header-file paths in external build directories

[Joel Rosdahl via ccache]

On Fri, 16 Nov 2018 at 19:46, Nico Huber via ccache
 wrote:
> [...]
> 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?

The history of that code is that https://github.com/ccache/ccache/pull/88
removed it to implement a new feature in ccache 3.3: "Names of included files
are no longer included in the hash of the compiler's preprocessed output. This
leads to more potential cache hits when not using the direct mode." Then
https://github.com/ccache/ccache/issues/134 was discovered, leading to a revert
in https://github.com/ccache/ccache/commit/7cad4ac5.

> Could this be handled with the `base_dir` normalization? 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`.

base_dir should be set to a parent directory of all paths seen by ccache. How
is $(obj) related to your source code directory? Are both absolute paths? Can
$(obj) be reached by a relative path that is the same for different
compilations for which you expect cache hits?

-- Joel

___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

[ccache] Header-file paths in external build directories

[Nico Huber via ccache]

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?

Regards,
Nico

___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache