| 1 |
On Thu, 6 Nov 2014 22:32:17 +0100 |
| 2 |
Jeroen Roovers <jer@g.o> wrote: |
| 3 |
> On Thu, 06 Nov 2014 12:40:33 -0800 |
| 4 |
> Zac Medico <zmedico@g.o> wrote: |
| 5 |
> > On 11/06/2014 12:11 PM, Michał Górny wrote: |
| 6 |
> > > # multilib.eclass collisions |
| 7 |
> > > get_libdir() { future_get_libdir "${@}"; } |
| 8 |
> > > # eutils.eclass collisions |
| 9 |
> > > einstalldocs() { future_einstalldocs "${@}"; } |
| 10 |
> > |
| 11 |
> > This collision handling mechanism seems pretty reasonable. |
| 12 |
> > Alternatively, maybe it could die if the functions are already |
| 13 |
> > defined, and advise the developer that future should be inherited |
| 14 |
> > later than multilib and eutils. |
| 15 |
> |
| 16 |
> I'm not aware of any current definition of order in eclass |
| 17 |
> inheritance. We sure have issues with inheriting eclasses in a |
| 18 |
> different order giving different results now. Is this something |
| 19 |
> that's in the works for a future EAPI, then? |
| 20 |
|
| 21 |
An EAPI solution to this is hard to work out. It would be much easier if |
| 22 |
people just stopped writing "clever" eclasses and didn't mix utility |
| 23 |
functions and phase functions within a single eclass. |
| 24 |
|
| 25 |
-- |
| 26 |
Ciaran McCreesh |
Archives