pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: recent ccache trouble?

Marko Schütz Schmuck <> 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` and there the toolchain compiler
> gets freshly made to then build the target system. So I set

Absent wrapper scripts that seems like it would work.

>> So I wonder why this is a problem now.  It seems mk/compiler/
>> 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 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:

  .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

Home | Main Index | Thread Index | Old Index