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 <willi...@gentoo.org> 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
signature.asc
Description: Digital signature
