[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:       hasufell <hasufell () gentoo ! org>
Date:       2014-08-18 12:56:05
Message-ID: 53F1F7E5.4000309 () gentoo ! org
[Download RAW message or body]

hasufell:
> 
> Even more interesting... you can work around this by inheriting
> base.eclass explicitly before e.g. unpacker.eclass, something like
> 
> inherit base unpacker games
> 
> => unpacker_src_unpack() is carried out by default (and the ebuild
> breaks if someone thinks the base.eclass is useless and removes it)
> 
> inherit unpacker games
> 
> => unpacker_src_unpack is not carried out by default although
> games.eclass does not directly overwrite it
> 
> If you think any of this is sensible...
> 

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.

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