From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.3/8.13.3) with ESMTP id j2HIdIjH004789 for ; Thu, 17 Mar 2005 18:39:18 GMT Received: from smtp3.actcom.co.il ([192.114.47.65]) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DBzts-0007pW-EM for gentoo-dev@robin.gentoo.org; Thu, 17 Mar 2005 18:39:16 +0000 Received: from alpha.danarmak.homelinux.net (l85-130-132-135.broadband.actcom.net.il [85.130.132.135]) by smtp3.actcom.co.il (8.13.3/8.13.3) with ESMTP id j2HIdB5o003924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Mar 2005 20:39:16 +0200 Received: from localhost ([127.0.0.1]) (TLS: TLSv1/SSLv3,128bits,RC4-MD5) by alpha.danarmak.homelinux.net with esmtp; Thu, 17 Mar 2005 21:05:40 +0200 id 011AFBA2.4239D504.00004473 From: Dan Armak Organization: Gentoo Technologies, Inc. To: gentoo-dev@robin.gentoo.org Subject: Re: [gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds Date: Thu, 17 Mar 2005 21:05:36 +0200 User-Agent: KMail/1.8 References: <200503162216.06885.danarmak@gentoo.org> <1111025370.16294.44.camel@localhost> In-Reply-To: <1111025370.16294.44.camel@localhost> Precedence: bulk List-Post: , , List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-To: gentoo-dev@gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2020066.Vv2ptEd9kf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503172105.37587.danarmak@gentoo.org> X-Archives-Salt: cf1cd039-5b29-49ea-914c-a4f105e5a2cf X-Archives-Hash: a6920f798ccb4fabc5b57f98614f1d04 --nextPart2020066.Vv2ptEd9kf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 17 March 2005 04:09, W.Kenworthy wrote: > One thing missing from this how to avoid using the spit ebuilds (i.e., > some kind of use flag may be needed?). =20 'avoid'? You can still get the monolithic ebuilds if you emerge kde rather= =20 than emerge kde-meta (and kdebase rather than kdebase-meta), etc. > Even with distcc and multiple=20 > helpers, it only takes a few separate packages to blow the time needed > to compile past a single package. Are you saying it takes longer to compile just a few split packages derived= =20 from kdebase than the monolithic kdebase package? Could you give actual=20 numbers to back that up? It's true that distcc gives an advantage to the monolithic ebuilds because= =20 they get to parallelize a lot more. But the solution to this should be=20 parallel emerging and sharing compiled packages, not huge packages. > > Example on a K6-500, kdelibs took (according to genlop) 11hrs 39 mins. kdelibs is the same whether you use monolithic or split ebuilds. > This was out of some 3 and a bit days compiling 86 packages (big update > - mostly gnome related - see last paragraph). You say in the documents > that a split kde will do around 100 packages in a typical update.=20 I don't know if that's typical... Anyway, monolithic ebuilds install the=20 equivalent of 300 packages every time. Even today's split ebuilds, which ar= e=20 not optimal, take a lot less time to do an upgrade (with 100 changed=20 packages) than a monolithic ebuilds upgrade (recompiling everything). > On=20 > the above figures, that looks like it will blow my compile times way > out! Not just an acceptable small amount. The time required to emerge kdelibs is far far bigger than any other kde sp= lit=20 package, and all but a few monolithic ones. > Is it only me that thinks this idea is crazy, as the biggest single > criticism of gentoo is build from source compile time, especially on the > first install where this will hit really really badly? Monolithic > builds are not ideal and have problems of their own, but here I think > practicality needs to come into it. =20 You talk as if splitting kdebase into 40 ebuilds makes the total kdebase-me= ta=20 compile time 40 times greater than that of kdebase... The very worst-case is several tens of percents more time. This is bad, but= =20 it's not hopeless, and we'll be improving it in various ways. > Alternatively, some major fixes to=20 > the build system to fix the core problem (mostly the configure stage > needs caching properly) well before this is implemented. This is true. It's why we still provide and support the monolithic ebuilds.= =20 KDE4 will (probably? hopefully?) use SCons instead of autotools, which will= be=20 1) a lot faster and 2) easily and powerfully cacheable (confcache for=20 autoconf configure scripts is a hack...). Even if they don't, there's=20 confcache, and unsermake, and we can avoid running make -f=20 admin/Makefile.common with some work. And other speedups like gcc 4 (faster= =20 c++ frontend, precompiled headers...) coming up in the same timeframe. As I've said elsewhere, our goal is that for kde 4 at the latest the split= =20 ebuilds will be 1) almost as fast as the monolithic ones _then_ and 2) fast= er=20 than the monolithic ones are _now_. That accomplished, we'll drop the=20 monolithic ebuilds.=20 Remember that the split ebuilds provide a lot of benefits, they're not just= a=20 gimmick. =2D-=20 Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key =46ingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 --nextPart2020066.Vv2ptEd9kf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCOdUBUI2RQ41fiVERAkMqAJ9IWDy7x5V3bHQ6NhZmEpFag8Ln6wCdGE/O UKj21p4/WS1Yij5uE1EL3qs= =Z0pk -----END PGP SIGNATURE----- --nextPart2020066.Vv2ptEd9kf-- -- gentoo-dev@gentoo.org mailing list