Gentoo Archives: gentoo-dev

From: Dan Armak <danarmak@g.o>
To: gentoo-dev@××××××××××.org
Subject: [gentoo-dev] Fwd: Inheritance in Ebuilds
Date: Thu, 20 Sep 2001 13:15:17
1 Hi all,
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!
6 ---------- Forwarded Message ----------
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
13 Hi drobbins,
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.
18 New ebuilds are as a rule a pain to write. Our provides a good
19 example to study, but is uncomfortable to adjust. I usually copy a similar
20 existing ebuild and modify that.
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.
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.
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.
38 An example ebuild for a kde app will then be reduced to something like this:
40 <header>
41 source /usr/portage/common/
42 DEPEND="$DEPEND app-foo/foo app-foo/foo2"
44 src_install() {
45 src_install2 # see explanation for this further down
46 dobin "extra bin not installed by make install"
47 }
49 -- cut here --
51 A perfectly standard ebuild could then, in theory, be reduced to just a
52 header, source statements and DEPEND definitions.
54 The 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.
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.
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.
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 (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.
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.
92 Well, what do you think?
94 Note from drobbins: the "base" inherited ebuilds are to be called eclassses,
95 with .eclass extensions.
97 --
99 Dan Armak
100 Gentoo Linux Developer, Desktop Team
101 Matan, Israel