| 1 |
Chris Reffett: |
| 2 |
> |
| 3 |
> |
| 4 |
> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" <mgorny@g.o> wrote: |
| 5 |
>> Dnia 2014-08-18, o godz. 09:22:46 |
| 6 |
>> Chris Reffett <creffett@g.o> napisał(a): |
| 7 |
>> |
| 8 |
>>> On 8/18/2014 8:56 AM, hasufell wrote: |
| 9 |
>>>> Almost forgot, of course this does not work if you expect |
| 10 |
>>>> unpacker_src_unpacker() to run: |
| 11 |
>>>> inherit unpacker games base |
| 12 |
>>>> |
| 13 |
>>>> as well as |
| 14 |
>>>> inherit unpacker base games |
| 15 |
>>>> |
| 16 |
>>>> however |
| 17 |
>>>> inherit games unpacker base |
| 18 |
>>>> |
| 19 |
>>>> will work. |
| 20 |
>>>> |
| 21 |
>>>> And now... guess why the games herd made it a policy to always |
| 22 |
>> inherit |
| 23 |
>>>> games.eclass last. Because of the unpredictability of eclasses and |
| 24 |
>> that |
| 25 |
>>>> they may randomly add exported phase functions. It's a bit |
| 26 |
>> paranoid, but |
| 27 |
>>>> understandable, since we don't have any real rules here. |
| 28 |
>>>> |
| 29 |
>>>> So in the end 3 eclasses all tell you "inherit me last! really!". |
| 30 |
>> Good |
| 31 |
>>>> luck with figuring out how to make a gnome game with python and |
| 32 |
>> multilib |
| 33 |
>>>> support work together. I can predict the days such a review would |
| 34 |
>> take |
| 35 |
>>>> in #gentoo-sunrise. Not less than 3. |
| 36 |
>>>> |
| 37 |
>>> Would it be feasible to add a repoman check for situations like this, |
| 38 |
>>> where the behavior of a phase is dependent on inherit order? If so, |
| 39 |
>> it |
| 40 |
>>> seems reasonable to me to require explicit calls to eclass functions |
| 41 |
>> in |
| 42 |
>>> these cases to make it clear what's being called when. |
| 43 |
>> |
| 44 |
>> Right now, we have no kind of repoman for eclasses. If you have time to |
| 45 |
>> work on such a thing, please do. Otherwise, all we can do is put more |
| 46 |
>> checks in ebuilds but that triggers the warning for the wrong people... |
| 47 |
> |
| 48 |
> 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. |
| 49 |
> |
| 50 |
> Chris Reffett |
| 51 |
> |
| 52 |
|
| 53 |
I don't want to code against warning tools, but against a reliable API. |
| 54 |
|
| 55 |
That said, EXPORT_FUNCTIONS in eclasses should be definite and |
| 56 |
non-recursive. Currently, people have to track down the actual exported |
| 57 |
functions themselves through the endless list of indirect inheritance |
| 58 |
which may: |
| 59 |
* randomly change |
| 60 |
* be highly dependant on the inherit order in the eclass and of those |
| 61 |
indirectly inheriting others... |
| 62 |
|
| 63 |
So to pick up the proposal again, I think this could make sense: |
| 64 |
* disable exported functions from indirectly inherited eclasses |
| 65 |
* have eclass authors do these things explicitly, so they have to export |
| 66 |
ALL functions themselves and may have to adjust their eclasses, as in: |
| 67 |
games_src_prepare() { base_src_prepare ; } (I know that base.eclass is |
| 68 |
deprecated, this is an example) |
| 69 |
* include the exported functions automatically in the generated eclass |
| 70 |
manpages |
Archives