Standardize NO_CCACHE flag and ccache definitions

Alex Kozlov spam at rm-rf.kiev.ua
Wed Jun 18 19:06:34 UTC 2008


On Wed, Jun 18, 2008 at 07:05:36PM +0100, RW wrote:
> On Wed, 18 Jun 2008 20:23:52 +0300
> Alex Kozlov <spam at rm-rf.kiev.ua> wrote:
> > This is not luck. To think more about this, CCACHE_HASH_COMPILER
> > and CCACHE_NOHASH_SIZE_MTIME is two method for the same.
> > hash size and mtime is lightweight and CCACHE_HASH_COMPILER
> > is more heavy.
> It's negligible, it added a few seconds to a build of Firefox,
> and I had to build it ten times to determine that because the
> build-to-build variations are much greater. 
I check this.

> > But in case of buildworld CCACHE_HASH_COMPILER is still not necessary,
> > CCACHE_NOHASH_SIZE_MTIME is enough.
> It depends what you want to achieve, the object of ccache is to
> cache compiler outputs where the results are identical to a fresh
> build (subject to possible minor exceptions like source file paths). If
> you don't detect compiler updates then you can no longer say that's
> true.
In typical case check for size and mtime is enough.
For buildworld We can disable even it, because compiler version
very rare change in RELENG_X lifetime.

In case of tinderbox farm I'm not so sure, if jails don't share
.ccache it probably relatively safe. This is need checking.
If overhead for CCACHE_HASH_COMPILER not big, may be worth turn
it on. Also need testing.

For too smart for it own good ports We can add to /etc/make.conf
something like this:
.if ${.CURDIR:N*/ports/devel/cmake} !="" && ...
CC = ccache
CXX = ccache
.endif

> If you use CCACHE_NOHASH_SIZE_MTIME then you are accepting object files
> produced by mixture of, arbitrarily old, versions of the compiler. If a
> new compiler version brings in better code generation, I'd rather pick
> it up.
> 
> CCACHE_HASH_COMPILER is a good compromise IMO, because it will detect
> changes in the driver, without being sensitive to minor world rebuilds.
> You still need to watch for security updates to GCC because in
> principle they might not affect the drivers, that's rare though.


--
Adios


More information about the freebsd-ports mailing list