From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21153 invoked from network); 19 Oct 2004 20:02:47 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Oct 2004 20:02:47 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CK0Bz-0000C7-1Z for arch-gentoo-dev@lists.gentoo.org; Tue, 19 Oct 2004 20:02:47 +0000 Received: (qmail 31841 invoked by uid 89); 19 Oct 2004 20:02:46 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 28419 invoked from network); 19 Oct 2004 20:02:45 +0000 From: Dan Armak Reply-To: danarmak@gentoo.org Organization: Gentoo Technologies, Inc. To: gentoo-dev@lists.gentoo.org Date: Tue, 19 Oct 2004 22:03:41 +0200 User-Agent: KMail/1.7.1 References: <200410191926.13381.danarmak@gentoo.org> <200410192040.54826.danarmak@gentoo.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2253417.r1DLX8DgxS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410192203.49686.danarmak@gentoo.org> Subject: Re: [gentoo-dev] Re: ANN: broken-up kde ebuilds (aka 'emerge kmail') X-Archives-Salt: 29ca5e99-1116-444f-a1f0-2068428bb2a2 X-Archives-Hash: 9dcc737819ccaef3bb9256fc3279f25c --nextPart2253417.r1DLX8DgxS Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 19 October 2004 21:33, Duncan wrote: > Good point re portage tracking. How do you manage the dependencies? Do > you rebuild every time in-builddir, or do you look in the deployed system > first and only build in-builddir if it isn't yet deployed? =20 Very little rebuilding takes place. Sometimes we copy built pieces from th= e=20 live filesystem into the workdir, but in those cases we depend on having be= en=20 build and installed first. The only things that are rebuilt are the ones that have to be: static libs= =20 that are never installed. They are very few and this is negligible in terms= =20 of performance. If you want the details, read the comments in kde-meta.eclass, then grep th= e=20 ebuilds to get usage statistics of each mode of operation. > Is there a=20 > list of an optimal emerge order if the latter? Not needed. Just normal portage deps. > From earlier, I remember you (?) saying=20 > what it DID cache, it invalidated entirely if there was just one change. I > can see how this would be simpler to implement. However, if you are > caching everything, I'd hope you are doing it in segments Caching is a builtin feature of configure scripts generated by autoconf.=20 configure --help | grep cache will show you. All we do in confcache is stor= e=20 the cache after every run and give it to the next run. So we have to invalidate it entirely and we can't segment it. Either behavi= our=20 would require basically replacing/rewriting autoconf. And if someone did do= =20 that, I'd be very happy :-) (Maybe the unsermake people?) But for now, this= =20 is all we can do. That said if the existing bugs are worked out (like not panicking=20 when /proc/cpuinfo's checksum changes due to cpu clock changes) our confcac= he=20 is pretty good too in terms of performance. =2D-=20 Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key =46ingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 --nextPart2253417.r1DLX8DgxS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBdXMlUI2RQ41fiVERAkzxAJ4kY9WkjbTiDXaCulis1oig4ZPkGwCdGNZ+ Hfw5QpFp8bQiuWU1L3hENIQ= =Xi5Q -----END PGP SIGNATURE----- --nextPart2253417.r1DLX8DgxS--