1 |
Hi all, |
2 |
|
3 |
This is an idea of mine which I sent to drobbins. With his blessing I'll |
4 |
begin testing on the kde ebuilds. Ideas welcome! |
5 |
|
6 |
---------- Forwarded Message ---------- |
7 |
|
8 |
Subject: Inheritance in Ebuilds |
9 |
Date: Thu, 20 Sep 2001 13:29:21 +0300 |
10 |
From: Dan Armak <danarmak@g.o> |
11 |
To: drobbins@g.o |
12 |
|
13 |
Hi drobbins, |
14 |
|
15 |
I've had an idea: make inheriting ebuilds, and generic "base" ebuilds. |
16 |
Please tell me what you think. Personally I like this idea very much. |
17 |
|
18 |
New ebuilds are as a rule a pain to write. Our skel.build provides a good |
19 |
example to study, but is uncomfortable to adjust. I usually copy a similar |
20 |
existing ebuild and modify that. |
21 |
|
22 |
However, most ebuilds are actually very similar. The kde ebuilds are a good |
23 |
example. All kde apps confirm to a standard [make -f Makefile;] configure; |
24 |
make; make install pattern. Their ebuilds vary only in their dependencies and |
25 |
the options passed to configure. |
26 |
|
27 |
Some time ago I added the objprelink option to the kde-base ebuilds, and that |
28 |
set me thinking. I had to change many files in an identical way. The files |
29 |
were, however, sufficiently dissimilar that I could not write a simple sed |
30 |
command or script to take care of the issue. |
31 |
|
32 |
My idea is like class inheritance: all common functionality should be defined |
33 |
and implemented in a single location. New common features will then be very |
34 |
easy to add; bugs in common features, easy to find and fix. We get all the |
35 |
benefits of class ineritance. Only the properties specific to the ebuild |
36 |
should actually be defined in it. |
37 |
|
38 |
An example ebuild for a kde app will then be reduced to something like this: |
39 |
|
40 |
<header> |
41 |
source /usr/portage/common/kde-generic.build |
42 |
DEPEND="$DEPEND app-foo/foo app-foo/foo2" |
43 |
|
44 |
src_install() { |
45 |
src_install2 # see explanation for this further down |
46 |
dobin "extra bin not installed by make install" |
47 |
} |
48 |
|
49 |
-- cut here -- |
50 |
|
51 |
A perfectly standard ebuild could then, in theory, be reduced to just a |
52 |
header, source statements and DEPEND definitions. |
53 |
|
54 |
The kde-generic.build file would define some generic deps, like kde-libs. It |
55 |
would also define default functions. These would be called (for example) |
56 |
src_unpack2(), src_compile2(), etc. For a kde ebuild, these functions would |
57 |
take care of common things like KDEDIR, QTDIR handling, qtmt, objprelink etc. |
58 |
etc. |
59 |
|
60 |
The generic ebuild would then say: |
61 |
src_install() { src_install2 } |
62 |
... |
63 |
Repeat for every ebuild function. This keeps the actual code in helper |
64 |
functions with the "2" prefix. The inheriting ebuild has three choices: |
65 |
1) Let the default src_install() stay. |
66 |
2) Override with a custom src_install() that calls src_install2() at some |
67 |
point, as in the above example. |
68 |
3) Override with a completely custom function. |
69 |
|
70 |
This way, ebuild writers can concentrate on their package pecularities and |
71 |
leave the generic kde code, for example, to me. With such a scheme, I |
72 |
wouldn't have needed to update all kde-dependant ebuilds after the /usr |
73 |
switch, as I did yesterday. |
74 |
|
75 |
Now, beyond kde. The gnome packages are AFAIK not very similar to one |
76 |
another, although they should be - my scheme is a unifying one. In any case, |
77 |
I think that if this works, eventually we'll have a base "virtual" ebuild |
78 |
from which all other ebuilds will inherit, which will define the same default |
79 |
function that are currently defined in ebuild.sh (I think that's the place). |
80 |
Then there will be several layers of inheritance, or maybe ebuilds will |
81 |
inherit from several generic ebuilds at once, which would make things really |
82 |
interesting. That way we could plug in all sorts of extensions and helper |
83 |
functions. I have ideas like unified output for messages. In my view this is |
84 |
much better than putting such functions in the ebuild/emerge utils' code |
85 |
base. |
86 |
|
87 |
An added advantage is that this scheme isn't binding. A developer can always |
88 |
write an ebuild of his own, in the current style. In fact, I could |
89 |
"centralize" kde-base right now, and it needn't affect anything else. |
90 |
Developers could source different things according to their style and purpose. |
91 |
|
92 |
Well, what do you think? |
93 |
|
94 |
Note from drobbins: the "base" inherited ebuilds are to be called eclassses, |
95 |
with .eclass extensions. |
96 |
|
97 |
-- |
98 |
|
99 |
Dan Armak |
100 |
Gentoo Linux Developer, Desktop Team |
101 |
Matan, Israel |