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