19.08.2014 00:23, hasufell пишет:
> Chris Reffett:
>>
>>
>> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" <mgo...@gentoo.org> wrote:
>>> Dnia 2014-08-18, o godz. 09:22:46
>>> Chris Reffett <creff...@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
> That's proposal make more sense. Even if it will bring such short and wrapper functions, it may be more compliant and ease things for PM itself. Usually i do not agree with your proposals, but that's one in it's current definition is really get +1 from me! -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
