1 |
On Thursday 07 February 2002 21:27, you wrote: |
2 |
> I like the idea. If its documentation becomes part of the ebuild howto, |
3 |
> it will get adopted fairly quickly. |
4 |
> |
5 |
> The main concern Hallski and me (and possibly others, such as John |
6 |
> Stalker, if memory serves) was that the current ebuild system mirrors |
7 |
> the manual build process so closely that external contributors have |
8 |
> little or no difficulty sending us ebuilds. |
9 |
> |
10 |
> I think this can be solved somewhat if it is clearly documented _what_ |
11 |
> is assumed by the various eclasses and perhaps a motivation when the |
12 |
> assumptions are less than crystal clear. |
13 |
When parts of the eclasses are merged into portage proper, what's left will |
14 |
(I hope) be a more unified and harmonious whole. Most of what's left will be |
15 |
in kde.eclass, which is written just like a standard ebuild, so anyone can |
16 |
read it (except for the many debug output statements). |
17 |
|
18 |
As for documentation, there's my eclass-howto (in /usr/portage/eclass/doc) |
19 |
which explains almost everything abuot eclasses and can in fact serve as a |
20 |
guide to writing new eclasses, not just inheriting ebuilds. It also has |
21 |
specific detailed instructions for writing inheriting kde ebuilds. I haven't |
22 |
updated it yet for yesterday's changes, but I shortly will. |
23 |
|
24 |
> |
25 |
> What plagues many non-kde ebuilds is that their build systems are fairly |
26 |
> non-standard. And even packages with seemingly standard build systems |
27 |
> quickly turn out to have both minor and major flaws (Mailman is a good |
28 |
> example of a horrible build system that on the surface looks nice, but |
29 |
> in practice turns out to be a real bitch). |
30 |
> |
31 |
> The minor nuisances of the various build systems mean that we might find |
32 |
> it easier to patch the generated Makefiles instead of the Makefile.in or |
33 |
> Makefile.am files, thus requiring an intermediate step between |
34 |
> configure and make (ie, patching in src_unpack is too troublesome). |
35 |
> |
36 |
> Consequently a simple wrapper for src_compile will only work a certain |
37 |
> percentage (possibly relatively low; <= 50%) of the time, and a |
38 |
> full-blown manual src_compile() function must be written for the rest of |
39 |
> the ebuilds. |
40 |
> |
41 |
> The situation for src_install() is even more dire, as it would appear |
42 |
> that close to all packages have trouble conforming to any kind of FHS, |
43 |
> and installing in a temporary directory is completely foreign. |
44 |
I know; kde ebuilds are surprisingly uniform and standard/fhs-compliant -a |
45 |
maintainer's dream really. That's what made kde eclasses possible in the |
46 |
first place. |
47 |
|
48 |
> Now, for our regular ebuild writers, the 50% saving is a big deal. For a |
49 |
> new submitter, it means he has to figure out which eclasses are |
50 |
> available (+ what they are), which criteria his package must meet to be |
51 |
> able to avail himself of the various eclasses, and finally test that |
52 |
> this is really so. |
53 |
|
54 |
The following is an illustrative explanations for people who aren't very |
55 |
familiar with eclasses: |
56 |
The lesson learned from eclasses is, that writing standard functions and |
57 |
overriding them in the ebuilds when they don't work still isn't efficient |
58 |
enough to justify the whole thing. Instead we must provide means to easily |
59 |
extend these functions. |
60 |
|
61 |
In the existing eclasses (mostly base and kde) I do it in two ways. The first |
62 |
one is function sections; quoting fom the eclass-howto (I've erased some |
63 |
parts to make this shorter): |
64 |
|
65 |
<quote> |
66 |
One rarely uses predefined functions as-is; you usually want to extend them. |
67 |
Once they have unique names (foo_src_unpack) [another eclass feature, see |
68 |
eclass-howto] it's easy to add code that executes before or after them. |
69 |
Function sections break them down and allow code to execute between any two |
70 |
sections. |
71 |
|
72 |
The implementation is simple. Let's take as an example the src_compile() |
73 |
function from base.eclass. It looks like this: |
74 |
|
75 |
base_src_compile() { |
76 |
./configure || die |
77 |
make || die |
78 |
} |
79 |
|
80 |
Here is the same function, divided into sections: |
81 |
|
82 |
base_src_compile() { |
83 |
|
84 |
[ -z "$1" ] && base_src_compile all |
85 |
|
86 |
while [ "$1" ]; do |
87 |
case $1 in |
88 |
configure) |
89 |
./configure || die;; |
90 |
make) |
91 |
make || die;; |
92 |
all) |
93 |
base_src_compile configure make;; |
94 |
esac |
95 |
shift |
96 |
done |
97 |
|
98 |
} |
99 |
|
100 |
The code has been divided into two "sections": configure and make. In our |
101 |
simple example, they correspond to the two commands in the original function. |
102 |
|
103 |
The special case all calls the same function recursively with a list of |
104 |
sections in order. The line before the block says that a call without |
105 |
parameters should be treated the same as a call with the single parameter all. |
106 |
|
107 |
Now, in your ebuild (or eclass) that inherits from base.eclass, you get the |
108 |
stub function src_compile which calls base_src_compile without parameters. |
109 |
This makes base_src_compile execute all, that is, all its sections. You can |
110 |
leave it as-is. If you wish to extend it, you define a new src_compile and |
111 |
call base_src_compile a section at a time: |
112 |
|
113 |
src_compile() { |
114 |
|
115 |
# do what i want |
116 |
base_src_compile configure |
117 |
# do something in between |
118 |
base_src_compile make |
119 |
# do something else |
120 |
|
121 |
} |
122 |
|
123 |
A final note: not all functions execute all their sections when called with |
124 |
all or without parameters. Some sections may be non-standard and must be |
125 |
called explicitly. The only such section right now is base_src_compile patch. |
126 |
</quote> |
127 |
|
128 |
The second way is by setting variables that the functions act on. The best |
129 |
example is that of $myconf. Many ebuilds say, in their general section: |
130 |
myconf="$myconf my-parameter" # you can place a use flag? here too |
131 |
Then, kde_src_compile passes $myconf to configure (after adding all the std |
132 |
parameters it knows about). |
133 |
|
134 |
In my view, the eclass interface isn't very different from the ordinary |
135 |
ebuild one, it just encapsulates very many things, especially in the case of |
136 |
KDE where apps are stantardized. the great majority of inheriting ebuilds |
137 |
looks like this: |
138 |
<headers> |
139 |
. /usr/portage/eclass/inherit.eclass || die |
140 |
inherit kde-base |
141 |
newdepend "foo? ( bar )" |
142 |
use foo && myconf="$myconf --with-foo" || myconf="$myconf --without-foo" |
143 |
--- |
144 |
|
145 |
At the end of the eclass-howto I explain in detail how to write inheriting |
146 |
kde ebuilds, as well as ebuilds for apps with optional kde functionality. |
147 |
Please take a look at that; I think that (possibly with some improvements) it |
148 |
can be added to the ebuild writing howto (or a reference added). |
149 |
|
150 |
A problem with kde ebuilds is that they *have* to use eclasses, in order for |
151 |
the kde "scheme" to work ($KDE?DIR and all that). Otherwise every kde ebuild |
152 |
would have to include some standard code that figures out where to install |
153 |
and against which kdelibs to link (it's currently in functions.eclass), so |
154 |
the obvious solution is to make a sourceable file out of it. |
155 |
|
156 |
However, other ebuilds needn't be forced into this situation (which isn't |
157 |
strictly beneficial): I think we should avoid, at least at first, making smoe |
158 |
features only available via the eclasses. An ebuild writer should be able to |
159 |
recreate everything with minimal effort, even if it means rewriting a |
160 |
standard src_compile(). This way new ebuild authors can start out writing |
161 |
ordinary ebuilds, and later (or never if they so choose) move to inheriting |
162 |
ones. As long as there's no obligation or pressure on ebuild |
163 |
authors/developers to use eclasses, there needn't be any pressure not to. |
164 |
|
165 |
-- |
166 |
Dan Armak |
167 |
Gentoo Linux Developer, Desktop Team (KDE) |
168 |
Matan, Israel |