From owner-freebsd-ports@FreeBSD.ORG Wed Jun 18 19:06:34 2008 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D9551065677; Wed, 18 Jun 2008 19:06:34 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from istc.kiev.ua (wolf.istc.kiev.ua [193.108.236.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA968FC1C; Wed, 18 Jun 2008 19:06:33 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from [91.123.146.100] (helo=ravenloft.kiev.ua) by istc.kiev.ua with esmtp (Exim 4.52) id 1K92zD-00083M-9M; Wed, 18 Jun 2008 22:06:29 +0300 Received: from kozlov by ravenloft.kiev.ua with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K92z7-000CwL-7c; Wed, 18 Jun 2008 22:06:21 +0300 Date: Wed, 18 Jun 2008 22:06:21 +0300 From: Alex Kozlov To: RW , Edwin Groothuis , Alex Dupre , ports@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20080618190621.GA49597@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Alex Kozlov X-Spam-Score: 0.0 (/) X-Spam-Report: Content analysis detailz: (0.0 points, 10.0 required) Cc: Subject: Re: Standardize NO_CCACHE flag and ccache definitions X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 19:06:34 -0000 On Wed, Jun 18, 2008 at 07:05:36PM +0100, RW wrote: > On Wed, 18 Jun 2008 20:23:52 +0300 > Alex Kozlov 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