[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