1 |
On 29 March 2014 06:12, Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>wrote: |
2 |
|
3 |
> These look a lot like they're just parameters to an eclass... An |
4 |
> alternative approach is to make this explicit, rather than having |
5 |
> zillions of environment variables: |
6 |
> |
7 |
|
8 |
Something I'd *like* to be able to do is have eclass specific keys that map |
9 |
to other ENVVars, for instance, in some python ebuilds, you have keys that |
10 |
expand to DEPEND, like PYTHON_REQ_USE, which are kinda messy to have |
11 |
implemented as eclass parameters. |
12 |
|
13 |
Mostly, because instead of eclass behaviour being simple inheritance or |
14 |
"make this function available", you're coupling behaviour to the import |
15 |
time. |
16 |
|
17 |
|
18 |
namely, something like: |
19 |
--- |
20 |
|
21 |
inherit perl-module [ |
22 |
runtime.requires = [ "Moose", "HTTP::Tiny" ] |
23 |
] |
24 |
|
25 |
--- |
26 |
|
27 |
Seems like it would get messy too fast, especially with being parseable. |
28 |
|
29 |
--- |
30 |
inherit perl-module |
31 |
|
32 |
PERL_RUNTIME_REQUIRES=( |
33 |
"Moose","HTTP::Tiny" |
34 |
) |
35 |
--- |
36 |
|
37 |
with a hook in perl-module that expands those to atoms in DEPENDS |
38 |
would be much more natural, ( and much more flexible ). |
39 |
|
40 |
|
41 |
-- |
42 |
Kent |