1 |
Hi everyone, |
2 |
|
3 |
About five months ago I came up with the idea of eclasses, and drobbins |
4 |
agreed for me to make a test case of all the kde ebuilds, since they are and |
5 |
were extremely similar to one another. |
6 |
|
7 |
The test has been a success but because of big differences between inheriting |
8 |
and regular ebuilds, non-kde ebuilds have not become inheriting. They are |
9 |
also less uniform then the kde ones and are harder to generalise. |
10 |
|
11 |
Unfortunately other developers almost never write inheriting ebuilds. The |
12 |
main complaint against eclasses as they are now, voiced by Hallski and |
13 |
others, is that they change the interface the ebuild writer has to deal with |
14 |
too radically. So developers stay away from the eclasses. Also eclasses are |
15 |
too separate from the rest of portage; at one point I had to recreate some |
16 |
basic version comparison functionality from scratch (that's scrapped now). |
17 |
|
18 |
To remedy that, I propose to merge at least the lower levels of the ebuilds |
19 |
(e.g. base.eclass, newdepend(), etc.) into portage (e.g. ebuild.sh). What |
20 |
would be left is a high-level interface for the kde ebuilds. Ideally nothing |
21 |
but the kde*.eclass files should be left outside portage. |
22 |
|
23 |
What might be merged includes stuff which is similar to what is already in |
24 |
portage. A quick list: |
25 |
|
26 |
- Default functions (i.e. src_unpack calling unpack $A, src_compile calling |
27 |
make). These have existed in base.eclass for months, but recently similar |
28 |
functions have been added to ebuild.sh (the einstall stuff). Obviously this |
29 |
is needless duplication of effort. |
30 |
|
31 |
- newdepend(), which adds its parameters to $DEPEND and $RDEPEND at the same |
32 |
time. It can also accept special parameters, for example the parameter |
33 |
"/autotools" adds autoconf, automake, make etc. to DEPEND (but not RDEPEND). |
34 |
|
35 |
- inherit(), which is really just a stub for source eclass || die. |
36 |
|
37 |
- (possibly) need-qt(), need-kde(), set-kdedir(), set-qtdir(), |
38 |
qtver-from-kdever(), min-qt-ver(): these are the functions dealing with the |
39 |
location of KDE2 and 3. They tell apps where to install and against which |
40 |
kdelibs/qt to link. They are based on the make.{globals,conf} $KDE{2,3}DIR, |
41 |
$KDE{2,3}LIBSDIR settings. |
42 |
|
43 |
What's left will then be a very simple and coherent interface for kde |
44 |
ebuilds, and will be hopefully be followed by eclasses for other things, such |
45 |
as Azarah's autotools.eclass which allows you to use autoconf 2.5 and |
46 |
automake 2.4. |
47 |
|
48 |
I've just now committed a big cleanup of the eclasses (transparent from the |
49 |
inheriting ebuild's point of view) which eliminated several eclasses and |
50 |
brought all misc functions together in a new functions.eclass. I'll update |
51 |
the docs tomorrow. |
52 |
|
53 |
This is all almost certainly portage v2 stuff. However I'd like everyone |
54 |
working on portage (e.g. Bevin, with whom I've spoken) to know where we |
55 |
stand, to coordinate our efforts. As always, any ideas, forecasts, |
56 |
suggestions etc. are always welcome. |
57 |
|
58 |
-- |
59 |
Dan Armak |
60 |
Gentoo Linux Developer, Desktop Team (KDE) |
61 |
Matan, Israel |