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

[William Hubbs]

On Sun, Aug 17, 2014 at 12:54:17AM +0200, Michał Górny wrote:
> Dnia 2014-08-16, o godz. 16:54:28
> William Hubbs <williamh@g.o> napisał(a):
>
> > The initial proposal is to change this behaviour so that the PMS default
> > phase functions call all matching phase functions from inherited
> > eclasses in sequence.
> >
> > For example:
> >
> > - your ebuild inherits foo and bar and each of them have src_unpack
> >   functions. With this new behaviour, the default src_unpack would run
> >   foo_src_unpack, bar_src_unpack, then perform its own actions.
>
> Why doesn't it call default_src_unpack too?

In the original proposal, the loop that ran foo_src_unpack,
bar_src_unpack, etc would be part of default_src_unpack.

> > I strongly oppose this change, because I feel it will make our
> > entire tree very unpredictable at best. I realize this might eliminate
> > boilerplating from our tree. Weighing that against the possible
> > ramifications in this big of a change in automagic behaviour, I think
> > the cost is much higher than the gain.
>
> 'Unpredictable' is very lightly said. 'Complete mayhem' seems much more
> appropriate.
>
> Right now, finding proper phase functions may be a bit hard due to
> indirect inherits. Imagine all the fun of debugging phase functions
> when every single indirect inherits adds to the stack. I don't want
> even to discuss the issue of ordering them all.

Agreed. It definitely would be a mess.

> > I am also not very comfortable with our current state, because it has
> > a lot of uncertainty in terms of how the eclass phase functions are
> > called.
>
> That is not really a problem of PMS behavior but a problem with
> the eclasses. If eclasses were done at least semi-reasonably, you
> would be able to easily guess which phase functions are exported by
> which eclass.

I'm all ears as they say; feel free to start a new thread on redesigning
our eclasses. I have no idea how they could be done differently
to make this easier.

>
> > My counter proposal to this is that we stop calling eclass phase
> > functions automatically, and to minimize the amount of boilerplating
> >   we would have to do, we use a variable, such as ECLASS_PHASES  which
> >   would be defined at the ebuild level and contain a list of the eclass
> >   phase functions we want to run automatically.
> >
> > Going back to my previous example, say your ebuild does the following:
> >
> > -- code begins here --
> >
> > inherit foo bar
> >
> > # Foo and bar both have src_unpack and src_install functions.
> > # we want foo's src_unpack and bar's src_install:
> >
> > ECLASS_PHASES="foo_src_unpack
> > 	bar_src_install"
> >
> > -- code ends here ---
>
> And how is this exactly different than:
>
>   src_unpack() { foo_src_unpack; }
>   src_install() { bar_src_install; }
>
> forced by your previous idea? As I see it, it's just a redundant way of
> doing the same thing. A few bytes shorter maybe, at the cost of having
> to control and consider another variable.
 
 I'm not arguing that either.

> What happens if ebuild specifies both ECLASS_PHASES="foo_src_unpack"
> and explicit src_unpack()?

The src_unpack() in the ebuild wins.

> That said, I suggest you focus your efforts on solving the real issue
> -- that is, fixing the eclasses -- rather than trying to shoehorn
> an ugly workaround into PMS.

Like I said above, I'm all ears; start a new thread about how the eclasses
can be fixed.

William