| 1 |
On Sat, 11 May 2013 11:51:39 -0400 |
| 2 |
Mike Gilbert <floppym@g.o> wrote: |
| 3 |
|
| 4 |
> On Sat, May 11, 2013 at 5:30 AM, Michał Górny <mgorny@g.o> wrote: |
| 5 |
> > Fixed naming the proper default sub-phase and declaring 'edefault' |
| 6 |
> > in python_prepare_all(). |
| 7 |
> > --- |
| 8 |
> |
| 9 |
> I think I prefer to explicitly name the function I want to call, so I |
| 10 |
> don't really see any great benefit here. I'm not strongly opposed to |
| 11 |
> it, but I don't see myself using it either. |
| 12 |
> |
| 13 |
> Also, how would this interact with other eclasses which may define a |
| 14 |
> similar "edefault" function? Packages using distutils-r1 don't often |
| 15 |
> utilize other phase-happy eclasses, but I'm sure it will happen |
| 16 |
> eventually. |
| 17 |
|
| 18 |
Well, the idea is that 'edefault' is defined by the eclass inventing |
| 19 |
the particular sub-phase. So if sub-phase A calls sub-phase B |
| 20 |
indirectly (trough the eclass and so on), edefault points to B |
| 21 |
eventually. |
| 22 |
|
| 23 |
Other thing would be, that after returning to A edefault will be no |
| 24 |
longer defined. That's fixable though, if ever needed. |
| 25 |
|
| 26 |
-- |
| 27 |
Best regards, |
| 28 |
Michał Górny |
Archives