Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[hasufell <hasufell@gentoo.org>]

Chris Reffett:
> 
> 
> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" <mgorny@gentoo.org> wrote:
>> Dnia 2014-08-18, o godz. 09:22:46
>> Chris Reffett <creffett@gentoo.org> napisał(a):
>>
>>> On 8/18/2014 8:56 AM, hasufell wrote:
>>>> Almost forgot, of course this does not work if you expect
>>>> unpacker_src_unpacker() to run:
>>>> inherit unpacker games base
>>>>
>>>> as well as
>>>> inherit unpacker base games
>>>>
>>>> however
>>>> inherit games unpacker base
>>>>
>>>> will work.
>>>>
>>>> And now... guess why the games herd made it a policy to always
>> inherit
>>>> games.eclass last. Because of the unpredictability of eclasses and
>> that
>>>> they may randomly add exported phase functions. It's a bit
>> paranoid, but
>>>> understandable, since we don't have any real rules here.
>>>>
>>>> So in the end 3 eclasses all tell you "inherit me last! really!".
>> Good
>>>> luck with figuring out how to make a gnome game with python and
>> multilib
>>>> support work together. I can predict the days such a review would
>> take
>>>> in #gentoo-sunrise. Not less than 3.
>>>>
>>> Would it be feasible to add a repoman check for situations like this,
>>> where the behavior of a phase is dependent on inherit order? If so,
>> it
>>> seems reasonable to me to require explicit calls to eclass functions
>> in
>>> these cases to make it clear what's being called when.
>>
>> Right now, we have no kind of repoman for eclasses. If you have time to
>> work on such a thing, please do. Otherwise, all we can do is put more
>> checks in ebuilds but that triggers the warning for the wrong people...
> 
> 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.
> 
> Chris Reffett
> 

I don't want to code against warning tools, but against a reliable API.

That said, EXPORT_FUNCTIONS in eclasses should be definite and
non-recursive. Currently, people have to track down the actual exported
functions themselves through the endless list of indirect inheritance
which may:
* randomly change
* be highly dependant on the inherit order in the eclass and of those
indirectly inheriting others...

So to pick up the proposal again, I think this could make sense:
* disable exported functions from indirectly inherited eclasses
* have eclass authors do these things explicitly, so they have to export
ALL functions themselves and may have to adjust their eclasses, as in:
games_src_prepare() { base_src_prepare ; } (I know that base.eclass is
deprecated, this is an example)
* include the exported functions automatically in the generated eclass
manpages