Re: [gentoo-dev] Segregating KDE?

[Simone Gotti]

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
<simone.gotti@×××××.it>
http://kde-bluetooth.sf.net

--
gentoo-dev@g.o mailing list