1 |
I often see one of two patterns: |
2 |
|
3 |
Pattern A) Code Before `inherit` to drive behaviour |
4 |
|
5 |
Example A.1 |
6 |
|
7 |
SOME_VALUE="Foo" |
8 |
inherit someclass |
9 |
OTHERVALUE=Bar" |
10 |
inherit someotherclass |
11 |
|
12 |
This is used heavily in things using perl-module.eclass |
13 |
|
14 |
Pattern B) Require either function calls or have a finalising function |
15 |
call to apply settings. |
16 |
|
17 |
Example B.1 |
18 |
|
19 |
inherit someclass |
20 |
SOME_VALUE="Foo" |
21 |
SOME_OTHER_VALUE="Bar" |
22 |
someclass_post_src; |
23 |
|
24 |
Example B.2 |
25 |
|
26 |
inherit someclass |
27 |
someclass_set_some_value "Foo" |
28 |
someclass_set_some_other_value "Foo" |
29 |
|
30 |
|
31 |
Examples A.1 and B.1 essentially share the same logic: define a value, can |
32 |
call some function that augments that value into other values ( and in the |
33 |
case of A.1, the function is called "inherit" ) |
34 |
|
35 |
A.1 is the least-worst here, its just ugly and you have to remember to put |
36 |
the inherit *after* the variable or the variable will behave as if it |
37 |
wasn't there. |
38 |
|
39 |
And B.1 has the convenient defect that if you forget to call the finalising |
40 |
function at the end, the ebuild may be radically different. |
41 |
|
42 |
B.2 Seems to make things much more complicated for eclass authors. |
43 |
|
44 |
<< TO THE POINT >> |
45 |
|
46 |
What I keep wanting to have is a hook that triggers after the ebuild is |
47 |
loaded, defined in the eclass. |
48 |
|
49 |
> source Foo.ebuild |
50 |
>> see inhert bar |
51 |
>> source bar.eclass |
52 |
>>> bar.eclass registers a hook bar_mauve |
53 |
>>> returns to processing Foo.ebuild |
54 |
>> Process code in Foo.ebuild |
55 |
> return to eclass handeler |
56 |
> trigger bar_mauve |
57 |
|
58 |
Note I've conveniently called it "bar_mauve" here because I have no idea |
59 |
what a good name will be, and establishing if the concept is useful or not |
60 |
should be done before we decide what we'll call it. |
61 |
|
62 |
The hook should be able to see and modify any variables that are to be |
63 |
expected visible to the ebuild itself, and the primary expected use would |
64 |
be augmenting exported variables based on other variables, like we |
65 |
presently do during ebuild sourcing in perl-module.eclass ( which is mostly |
66 |
computing SRC_URI from other variables ), essentially making it easier to |
67 |
write variable declaration based ebuilds. |
68 |
|
69 |
|
70 |
|
71 |
|
72 |
|
73 |
-- |
74 |
Kent |