Date: Wed, 18 Jun 2008 19:05:36 +0100 From: RW <fbsd06@mlists.homeunix.com> To: freebsd-ports@freebsd.org Subject: Re: Standardize NO_CCACHE flag and ccache definitions Message-ID: <20080618190536.3f4cd45a@gumby.homeunix.com.> In-Reply-To: <20080618172352.GA45188@ravenloft.kiev.ua> References: <20080618172352.GA45188@ravenloft.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080618190536.3f4cd45a>