Hi Kris,

On Fri, 21 Jun 2019 at 02:43, Malfettone, Kris wrote:
> My project uses a large number of generated C++ files (.h/.cpp files). On a
> clean build these files are cleaned up as well. As a result during the next
> build since they are generated again they will all have a newer mtime and
> ctime than the previous runs. Their content is the same though. Is there a
> way for those files to disable checking both the mtime and ctime checks?

I'm not sure I understand your question. Since the content of the generated
files is the same, they will get the same hash sum and will therefore be seen
as the same for the purposes of caching compilation results.

Or are you talking about the "sloppiness = file_stat_matches" option, where the
normal content hashing is sidestepped and matching in the direct mode can be
done by checking only size/mtime/ctime? If so, the answer is that it's not
possible to only check the size. Or rather: It would of course be possible to
implement such an option, but that does not seem like a good idea – it would be
way too dangerous since files of course can differ in many ways but still have
the same size.

But if you really want to try it yourself, you can simply change

  if (fi->fsize != st->size) {
    return false;


  if (fi->fsize == st->size) {

in verify_result in src/manifest.c.

Is the problem that you think that hashing the generated files takes too much
time? If so, have you in some way been able to measure that hashing indeed is a

> I would love to be able to check based on some sort of "check file size then
> check content checksum" ignoring mtime and ctime.

Again, not sure I understand what you mean. In the normal case (no "sloppiness
= file_stat_matches"), the mtime/ctime is not checked for verification (but
they are checked to rule out "too new" files; see
include_file_mtime/include_file_ctime in the manual), so what you describe is
how it already works. In the "sloppiness = file_stat_matches" case, the
verification also falls back to check the content if mtime/ctime don't match.

-- Joel

ccache mailing list

Reply via email to