Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jun 2008 22:06:21 +0300
From:      Alex Kozlov <spam@rm-rf.kiev.ua>
To:        RW <fbsd06@mlists.homeunix.com>, Edwin Groothuis <edwin@mavetju.org>, Alex Dupre <ale@FreeBSD.org>, ports@freebsd.org, spam@rm-rf.kiev.ua
Subject:   Re: Standardize NO_CCACHE flag and ccache definitions
Message-ID:  <20080618190621.GA49597@ravenloft.kiev.ua>

next in thread | raw e-mail | index | archive | help
On Wed, Jun 18, 2008 at 07:05:36PM +0100, RW wrote:
> On Wed, 18 Jun 2008 20:23:52 +0300
> Alex Kozlov <spam@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080618190621.GA49597>