Re: [gentoo-dev] Re: ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Dan Armak]

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?

Very little rebuilding takes place.  Sometimes we copy built pieces from the 
live filesystem into the workdir, but in those cases we depend on having been 
build and installed first.

The only things that are rebuilt are the ones that have to be: static libs 
that are never installed. They are very few and this is negligible in terms 
of performance.

If you want the details, read the comments in kde-meta.eclass, then grep the 
ebuilds to get usage statistics of each mode of operation.

> Is there a
> list of an optimal emerge order if the latter?
Not needed. Just normal portage deps.

> From earlier, I remember you (?) saying
> 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. 
configure --help | grep cache will show you. All we do in confcache is store 
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 behaviour 
would require basically replacing/rewriting autoconf. And if someone did do 
that, I'd be very happy :-) (Maybe the unsermake people?) But for now, this 
is all we can do.

That said if the existing bugs are worked out (like not panicking 
when /proc/cpuinfo's checksum changes due to cpu clock changes) our confcache 
is pretty good too in terms of performance.

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