[ccache] ccache and -g

[Martin Pool]

On  3 Jan 2006, Chris Swiedler <cswiedler at perpetual.com> wrote:
> Looking at CCACHE_UNIFY: what exactly is the problem mentioned in the
> docs about using CCACHE_UNIFY, for example with debugging (gcc -g)? It
> looks to me like the compiler is always run (on a cache miss) on the
> original source, and the unification is done only for generating the
> hash. If that's the case, how are compiler warning messages outputting
> the wrong lines, and why is it forced off for debug compiles?

As I understand it, the unifier squashes the preprocessed source to
eliminate differences that make no difference to the output.  For
example, the preprocessor outputs one blank line for each comment line,
so if you add comment lines it will cause a cache mismatch.  By removing
them we get a cache hit, but at the expense of getting the wrong line
numbers in debug symbols and compiler warnings.  This is turned off for
-g because having the wrong line numbers would be very confusing.

> In terms of getting cache hits, forcing the unifier to be run (via
> Steve's patch) fixes my problem, since it removes lines beginning with #
> from the hash. That's a little more extreme than I need; I would be
> happy if the unifier just ignored lines beginning with # which refer to
> a directory instead of a file. In my case, the only line which is
> different between the preprocessed output of two identical files in
> different trees is the second line, which looks like

Yes I think that would be better too.

Since most of these option flags are booleans it might be cleaner to add
a new boolean.

-- 
Martin