[ccache] Would backdating source files allow sharing hardlinks between trees?

[Joel Rosdahl]

On 2010-11-25 21:56, Justin Lebar wrote:
> [...]
> 1) Update the object file's mtime to now.  If we do this, then when we
> rebuild in another tree, the object file will be newer than the things
> which depend on it (e.g. shared libraries which include the file), so
> we'll have to relink.
> 
> 2) Leave the object file's mtime unmodified.  If we do this, then when
> we rebuild this same tree, the object file will appear out of date.
>
> I believe ccache takes the first approach, which seems sensible.

Yes.

However, ccache also updates the object file's mtime for another reason:
it's used to mark the object as "used" so that the cleanup algorithm
knows which least recently used results it should remove. (So an option
like you suggest below must also change ccache's bookkeeping of
"usedness" in some way.)

> But as an alternative, what if we backdated the source file's mtime to
> before the object file was created and left the object file's mtime
> unchanged?  (If we didn't want to arbitrarily choose a time, we could
> save the mtime of the source file which originally generated the
> object file and use that.)

That's an interesting idea!

> This would be an option, of course -- it's kind of strange behavior,
> so it certainly shouldn't be on unless the user asks for it.  But I
> wonder if this actually solves the problem.  I suspect it might screw
> up some important tool, but I can't think of a potential bad
> interaction off the top of my head.

One issue I see is that if foo.c is generated from foo.y, then a
backdated foo.c may become older than foo.y, which will trigger
generation of foo.c, which will trigger building of foo.o, which makes
ccache backdate foo.c, which leads back to square one.

-- Joel