1 |
On Saturday 18 September 2004 23:13, Anthony Gorecki wrote: |
2 |
> Partially separate, but not quite. What I had in mind is more in line with |
3 |
> a piece of functionality similar to that of a symlink: Instead of manually |
4 |
> tearing apart the individual KDE distribution packages after every |
5 |
> revision, they could be left as-is. When a KMail installation was |
6 |
> requested, for example, its dependencies could be calculated against the |
7 |
> existing KDE packages and configured using DO_NOT_INSTALL to build only the |
8 |
> files that were required for KMail and were not already merged onto the |
9 |
> filesystem. |
10 |
We wouldn't need to 'tear apart' the kde packages except just once, when we |
11 |
first wrote the broken-out ebuilds. After that each ebuild would essentially |
12 |
do what you describe: take eg the kdepim tarball and build only kmail using |
13 |
DO_NOT_COMPILE and related techniques. |
14 |
|
15 |
> > IMHO the best way, from the maintainers' POV, would be to be able to use |
16 |
> > perfectly ordinary separate ebuilds for KDE apps. And, this would require |
17 |
> > something like the config cache to be viable. |
18 |
> |
19 |
> ccache could be quite helpful, regardless of the package that was being |
20 |
> built; I agree that it would improve KDE compilation time, especially. What |
21 |
> do you mean by "being viable"? I haven't had a chance to experiment with |
22 |
> the software, though I thought it was already working reasonably well for |
23 |
> most computer systems. |
24 |
|
25 |
Misunderstanding here. |
26 |
|
27 |
ccache=='compiler cache', which caches the work done by gcc/g++. |
28 |
|
29 |
I was talking about the recently proposed, and still experimental afaik, |
30 |
'configure cache' patch to portage, posted to this list on September 10th by |
31 |
Stuart Hebert: |
32 |
http://dev.gentoo.org/~stuart/confcache/ |
33 |
|
34 |
It caches the tests run by configure scripts. I haven't tried it yet and |
35 |
haven't seen any reports on how well it works for kde specifically. We -need- |
36 |
a solution to the configure script run times issue, as described in #11123. |
37 |
If that's not resolved, no amount of maintainer manpower can help, because |
38 |
the move to separate ebuilds would mean a large increase in emerging time for |
39 |
people who do want all of kde. If this configure cache works well and is |
40 |
accepted into portage, it'd be the best possible solution to the problem. |
41 |
|
42 |
-- |
43 |
Dan Armak |
44 |
Gentoo Linux developer (KDE) |
45 |
Matan, Israel |
46 |
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key |
47 |
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 |