From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9509 invoked from network); 19 Sep 2004 20:55:56 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Sep 2004 20:55:56 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1C98j5-0000Gn-Jv for arch-gentoo-dev@lists.gentoo.org; Sun, 19 Sep 2004 20:56:03 +0000 Received: (qmail 26499 invoked by uid 89); 19 Sep 2004 20:55:28 +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 6315 invoked from network); 19 Sep 2004 20:55:27 +0000 From: Simone Gotti To: gentoo-dev@lists.gentoo.org Date: Sun, 19 Sep 2004 23:00:39 +0200 User-Agent: KMail/1.7 References: <200409180057.34014.anthony@ectrolinux.com> <200409192008.23813.simone.gotti@email.it> <200409192233.39105.danarmak@gentoo.org> In-Reply-To: <200409192233.39105.danarmak@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409192300.39826.simone.gotti@email.it> X-Virus-Scanned: Cineca AppOs 0.81 at as2.cineca.it Subject: Re: [gentoo-dev] Segregating KDE? X-Archives-Salt: 815aadb7-ee3d-4491-ad8b-fd0ae8de45c2 X-Archives-Hash: 771fb62189a6067e8a7164b8c34f2bc7 On Sunday 19 September 2004 21:33, Dan Armak wrote: > As I said, I'm definitely going to try making this work, but won't have > real time until the weekend after next (and most days after that, > hopefully), so you can beat me to it. There are other few issues, for example some libraries aren't installed in the system because defined in the Makefile.am as "noinst_LTLIBRARIES". And some programs in differents subdirs are linking to them, so these library must be recompiled for every program we are compiling that needs them and this will bring to more compilation time. I can't see a solution to this, installing them will go against the kde developers decisions and there's a reason because they aren't installed. > I've just tried the confcache patch. It's integrated into portage .51 cvs > snapshots here http://dev.gentoo.org/~ferringb/ebuild-daemon/51-pre20-cvs/ > - they apparently include other highly experimental stuff and the last one > has some bugs already fixed in cvs, so be in touch with #gentoo-portage if > using these. To enable confcache, add 'confcache' to FEATURES and change > the kde ebuilds to use econf rather than call configure directly. This > results in the kde.eclass attached - the change is trivial, but as I'm on > rsync not cvs atm, I can't make a diff immediately, sorry. The change for > split packages should also be on the order of a five-liner in kde.eclass, > apart from the makefile changes. > > On my athlon xp 2600, this makes the kdelibs configure run go down from 66 > seconds to 28 seconds. At least 10-12 seconds of each of these two numbers > is due to makefile generation, which will be very much reduced in split-up > ebuilds, so we get 54 sec -> 16 sec, or a 5x improvement. > > Also, on slower machines a far larger percent of time spent in (non-cached) > configure is due to slow compilations rather than (as here) IO, so the > benefit will be even greater there. This indicates we should at least > reevluate the emerge performance factor of splitting up the kde ebuilds. > > Using my old rough formula, we get: > 17 configure scripts (before splitting ebuilds) --> 20-60 minutes total > running time > splitting up --> >=220 packages (? but at least that many, I believe) > splitting up without confcache --> 220-660 minutes, i.e. 3.6-11 hours, > total running time (clearly unacceptable) > splitting up with confcache --> about 15-20% of above, i.e. 1-2.2 hours > total running time > > According to these numbers, if we both add confcache and split the ebuilds, > the total time for emerging all or nearly all of kde will increase by > 0.6-1.2 hours, plus the overhead from running the emerge cycle 200 more > times, which I hope is relatively negligible (a few minutes?). > > Compared with the benefits (to those who don't want all of kde, and > considering that >95% of people typing 'emerge kde' to save package > selection time don't really want kdetoys and kdeedu and such, this seems on > first sight to be a reasonable tradeoff for the added functionality. What > do you think, everyone? Also note that my benchmarking is hardly > scientific, so I'd be glad if someone bothered to repeat it and compare his > results to mine. I'll try it. Thanks. Bye! --- Simone Gotti http://kde-bluetooth.sf.net -- gentoo-dev@gentoo.org mailing list