1 |
19.08.2014 00:23, hasufell пишет: |
2 |
> Chris Reffett: |
3 |
>> |
4 |
>> |
5 |
>> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" <mgorny@g.o> wrote: |
6 |
>>> Dnia 2014-08-18, o godz. 09:22:46 |
7 |
>>> Chris Reffett <creffett@g.o> napisał(a): |
8 |
>>> |
9 |
>>>> On 8/18/2014 8:56 AM, hasufell wrote: |
10 |
>>>>> Almost forgot, of course this does not work if you expect |
11 |
>>>>> unpacker_src_unpacker() to run: |
12 |
>>>>> inherit unpacker games base |
13 |
>>>>> |
14 |
>>>>> as well as |
15 |
>>>>> inherit unpacker base games |
16 |
>>>>> |
17 |
>>>>> however |
18 |
>>>>> inherit games unpacker base |
19 |
>>>>> |
20 |
>>>>> will work. |
21 |
>>>>> |
22 |
>>>>> And now... guess why the games herd made it a policy to always |
23 |
>>> inherit |
24 |
>>>>> games.eclass last. Because of the unpredictability of eclasses and |
25 |
>>> that |
26 |
>>>>> they may randomly add exported phase functions. It's a bit |
27 |
>>> paranoid, but |
28 |
>>>>> understandable, since we don't have any real rules here. |
29 |
>>>>> |
30 |
>>>>> So in the end 3 eclasses all tell you "inherit me last! really!". |
31 |
>>> Good |
32 |
>>>>> luck with figuring out how to make a gnome game with python and |
33 |
>>> multilib |
34 |
>>>>> support work together. I can predict the days such a review would |
35 |
>>> take |
36 |
>>>>> in #gentoo-sunrise. Not less than 3. |
37 |
>>>>> |
38 |
>>>> Would it be feasible to add a repoman check for situations like this, |
39 |
>>>> where the behavior of a phase is dependent on inherit order? If so, |
40 |
>>> it |
41 |
>>>> seems reasonable to me to require explicit calls to eclass functions |
42 |
>>> in |
43 |
>>>> these cases to make it clear what's being called when. |
44 |
>>> |
45 |
>>> Right now, we have no kind of repoman for eclasses. If you have time to |
46 |
>>> work on such a thing, please do. Otherwise, all we can do is put more |
47 |
>>> checks in ebuilds but that triggers the warning for the wrong people... |
48 |
>> |
49 |
>> I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils and games eclasses, and I don't explicitly define src_compile, repoman full could pop up a warning like "src_compile is ambiguous between cmake-utils_src_compile and games_src_compile, please explicitly define this phase and call the appropriate eclass function." I imagine that this would pop up a lot of warnings, but I feel like it would improve readability and make it explicit what should be going on where. I concede that it could make a lot more boilerplate code in ebuilds, so that's a potential issue, mostly just throwing out an idea here. |
50 |
>> |
51 |
>> Chris Reffett |
52 |
>> |
53 |
> |
54 |
> I don't want to code against warning tools, but against a reliable API. |
55 |
> |
56 |
> That said, EXPORT_FUNCTIONS in eclasses should be definite and |
57 |
> non-recursive. Currently, people have to track down the actual exported |
58 |
> functions themselves through the endless list of indirect inheritance |
59 |
> which may: |
60 |
> * randomly change |
61 |
> * be highly dependant on the inherit order in the eclass and of those |
62 |
> indirectly inheriting others... |
63 |
> |
64 |
> So to pick up the proposal again, I think this could make sense: |
65 |
> * disable exported functions from indirectly inherited eclasses |
66 |
> * have eclass authors do these things explicitly, so they have to export |
67 |
> ALL functions themselves and may have to adjust their eclasses, as in: |
68 |
> games_src_prepare() { base_src_prepare ; } (I know that base.eclass is |
69 |
> deprecated, this is an example) |
70 |
> * include the exported functions automatically in the generated eclass |
71 |
> manpages |
72 |
> |
73 |
|
74 |
That's proposal make more sense. Even if it will bring such short and |
75 |
wrapper functions, it may be more compliant and ease things for PM itself. |
76 |
|
77 |
Usually i do not agree with your proposals, but that's one in it's |
78 |
current definition is really get +1 from me! |
79 |
|
80 |
-- |
81 |
Best regards, Sergey Popov |
82 |
Gentoo developer |
83 |
Gentoo Desktop Effects project lead |
84 |
Gentoo Proxy maintainers project lead |