Re: [gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds

[Dan Armak]

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?).
'avoid'? You can still get the monolithic ebuilds if you emerge kde rather 
than emerge kde-meta (and kdebase rather than kdebase-meta), etc.

> Even with distcc and multiple
> 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 
from kdebase than the monolithic kdebase package? Could you give actual 
numbers to back that up?

It's true that distcc gives an advantage to the monolithic ebuilds because 
they get to parallelize a lot more. But the solution to this should be 
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.
I don't know if that's typical... Anyway, monolithic ebuilds install the 
equivalent of 300 packages every time. Even today's split ebuilds, which are 
not optimal, take a lot less time to do an upgrade (with 100 changed 
packages) than a monolithic ebuilds upgrade (recompiling everything).

> On
> 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 split 
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.
You talk as if splitting kdebase into 40 ebuilds makes the total kdebase-meta 
compile time 40 times greater than that of kdebase...

The very worst-case is several tens of percents more time. This is bad, but 
it's not hopeless, and we'll be improving it in various ways.

> Alternatively, some major fixes to
> 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. 

KDE4 will (probably? hopefully?) use SCons instead of autotools, which will be 
1) a lot faster and 2) easily and powerfully cacheable (confcache for 
autoconf configure scripts is a hack...). Even if they don't, there's 
confcache, and unsermake, and we can avoid running make -f 
admin/Makefile.common with some work. And other speedups like gcc 4 (faster 
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 
ebuilds will be 1) almost as fast as the monolithic ones _then_ and 2) faster 
than the monolithic ones are _now_. That accomplished, we'll drop the 
monolithic ebuilds. 

Remember that the split ebuilds provide a lot of benefits, they're not just a 
gimmick.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951