Marko Schütz Schmuck <MarkoSchuetz%web.de@localhost> writes: > Why would the mtime of the compiler change on every run? Or were you > thinking of the atime? I meant that the wrapper script in work/.wrapper/bin/cc has a new mtime every time you make the package. But, that wrapper invokes work/.ccache/bin/gcc which is a symlink to /usr/pkg/bin/ccache. But in PATH the ccache wrapper dir is befoer the gcc wrapper dir, so I don't see how ccahe avoids a loop. > I use ccache for `./build.sh build` and there the toolchain compiler > gets freshly made to then build the target system. So I set > CCACHE_COMPILERCHECK to 'content'. Absent wrapper scripts that seems like it would work. >> So I wonder why this is a problem now. It seems mk/compiler/ccache.mk >> sets CCACHE_HASHCC, but that variable is not mentioned any more in the >> 3.1.4 man page. > > CCACHE_HASHCC was introduced as a pkgsrc patch. That explains why it's gone :-) >> So it seems we need to change ccache.mk to set CCACHE_COMPILERCHECK >> (additionally), so it works with either version of ccache. > > It might be a good idea to use CCACHE_COMPILERCHECK=content also for > pkgsrc, so that replacing the compiler with the same version, but more > recently built, won't invalidate the cache. I think the concern is that content is expensive. But using "%compiler% -v" should avoid invalidation on rebuild of the compiler too. So, can anyone explain the intended call chain from wrapper scripts and ccache? I would expect: .wrapper/bin/gcc .ccache/bin/gcc (symlink to ccache) .gcc/bin/gcc (symlink to real gcc) Does ccache, when searching the path, skip symlinks to ccache? It would seem that it must, but this is not obvious from the man page. I wonder if the issue is that stat on the symlink is returning symlink mtime on the mac, and target mtime NetBSD.
Attachment:
pgpyBvGb5qNM8.pgp
Description: PGP signature