[ccache] ccache and -g

Chris Swiedler cswiedler at perpetual.com
Wed Jan 4 17:25:51 GMT 2006


> 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.

Well, what if the unifier never changed the actual count of lines (i.e.
never squashed newlines)? That would cut down a little on cache hits,
but would still allow minor changes to comments or whitespace.

> > 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.

Steve's patch helps me since it means I don't have to change my
makefiles to use relative paths, but to solve the debug-mode problem I'm
thinking of a patch which just:

* Changes the unifier to not squash any newlines
* Allows the unifier to run even in debug mode (Steve's patch does
something similar with CCACHE_UNIFY=force)

Does this sound correct?

chris


More information about the ccache mailing list