>> Maybe the right thing to do would be to have ccache keep track of the >> source files' attributes. =A0If some environment variable was set, >> ccache would treat a file with unchanged attributes as unchanged. >> (ccache could maintain a new index into its cache, indexed on absolute >> path, or it could hash a string "magic-bitstring | file-path | file >> attributes" and use the current cache infrastructure.) =A0This seems a >> lot simpler than trying to interface with git. > >I think that is a better approach too. It's probably enough to just >store the mtime and (on unix) ctime. There are a couple of tricks to >doing this safely: if the time == the current time, you can't trust it >because the file could be modified again before the end of the current >second. On some filesystems (eg vfat) the fs actually only stores >2-second granularities. On some Linux systems you get sub-second >accuracy while the file is in cache but not when it's been flushed to >disk (this might have been fixed.)
I also think this is a good approach, though having been down the road before, mtime isn't always enough as you noted, but including the size also makes it *almost* perfect. Most edits change the size. Note several tools like scons use this technique, and some store the hashes in a single hash file inside each source directory. That has the nice advantage of allowing sharing, though the downside of poluting the source areas so I don't really like it. I think putting it into the ccache infrastructure is nicer; but you may still want multiple hashes to be stored under a hash of the directory name, instead of a hash of the filename, because that allows reading fewer files. (Otherwise reading the hundreds of hash files will become the new bottleneck.) _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache