From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17048 invoked from network); 8 Oct 2004 19:57:39 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 8 Oct 2004 19:57:39 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CG0rw-0003ao-CF for arch-gentoo-portage-dev@lists.gentoo.org; Fri, 08 Oct 2004 19:57:36 +0000 Received: (qmail 20545 invoked by uid 89); 8 Oct 2004 19:57:35 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 6588 invoked from network); 8 Oct 2004 19:57:33 +0000 From: Brian Harring Reply-To: ferringb@gentoo.org To: gentoo-portage-dev@lists.gentoo.org Cc: stuart@gentoo.org Content-Type: text/plain Message-Id: <1097265907.8869.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 08 Oct 2004 13:08:29 -0700 Content-Transfer-Encoding: 7bit Subject: [gentoo-portage-dev] re: confcache X-Archives-Salt: 2e23715f-cb5c-44cd-b671-60f70b24fdda X-Archives-Hash: 2311923ade8bb5d8c627ba4bfab51661 Well... that's weird, attempted to send this directly to dan, having it bail due to 'failed: relaying not allowed: danarmak@gentoo.org' I assume I'm being an idiot and screwing up the address (or local configuration)... Either way, you might want to take a look at my implementation of confcache in http://dev.gentoo.org/~ferringb/ebuild-daemon/51-pre20-cvs/ You can use SANDBOX_DEBUG_LOG and SANDBOX_DEBUG instead of modifying the sandbox- works just the same. Also, variables changing _will_ cause configure to bail if they've been cached (cflags fex), so you might want to either filter those entries (they start with ac_cv_env_), or rewrite them (I went for rewrite, works although I worry about other cache entries relying on the vars not changing). Aside from that, there is also the md5'ing of /proc/cpuinfo- most users, not an issue, as magnade pointed out, this is a killer for users that have procs that adjust their frequency (laptops fex) for power saving- this changes the md5 of /proc/cpuinfo pretty much continually, invalidating the cache continually. ~brian -- gentoo-portage-dev@gentoo.org mailing list