Re: [gentoo-dev] Segregating KDE?

[Dan Armak <danarmak@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

On Saturday 18 September 2004 23:13, Anthony Gorecki wrote:
> Partially separate, but not quite. What I had in mind is more in line with
> a piece of functionality similar to that of a symlink: Instead of manually
> tearing apart the individual KDE distribution packages after every
> revision, they could be left as-is. When a KMail installation was
> requested, for example, its dependencies could be calculated against the
> existing KDE packages and configured using DO_NOT_INSTALL to build only the
> files that were required for KMail and were not already merged onto the
> filesystem.
We wouldn't need to 'tear apart' the kde packages except just once, when we 
first wrote the broken-out ebuilds. After that each ebuild would essentially 
do what you describe: take eg the kdepim tarball and build only kmail using 
DO_NOT_COMPILE and related techniques.

> > IMHO the best way, from the maintainers' POV, would be to be able to use
> > perfectly ordinary separate ebuilds for KDE apps. And, this would require
> > something like the config cache to be viable.
>
> ccache could be quite helpful, regardless of the package that was being
> built; I agree that it would improve KDE compilation time, especially. What
> do you mean by "being viable"? I haven't had a chance to experiment with
> the software, though I thought it was already working reasonably well for
> most computer systems.

Misunderstanding here.

ccache=='compiler cache', which caches the work done by gcc/g++.

I was talking about the recently proposed, and still experimental afaik, 
'configure cache' patch to portage, posted to this list on September 10th by 
Stuart Hebert: 
http://dev.gentoo.org/~stuart/confcache/

It caches the tests run by configure scripts. I haven't tried it yet and 
haven't seen any reports on how well it works for kde specifically. We -need- 
a solution to the configure script run times issue, as described in #11123. 
If that's not resolved, no amount of maintainer manpower can help, because 
the move to separate ebuilds would mean a large increase in emerging time for 
people who do want all of kde. If this configure cache works well and is 
accepted into portage, it'd be the best possible solution to the problem.

-- 
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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]