[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] rfc: calling all eclass phase functions by default
From:       Chris Reffett <creffett () gentoo ! org>
Date:       2014-08-18 19:37:26
Message-ID: d2221097-0cdf-42a3-a183-a7ef3e399c8c () email ! android ! com
[Download RAW message or body]



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


[prev in list] [next in list] [prev in thread] [next in thread]