| 1 |
On 11/06/2014 01:11 PM, Zac Medico wrote: |
| 2 |
> On 11/06/2014 12:40 PM, Zac Medico wrote: |
| 3 |
>> On 11/06/2014 12:11 PM, Michał Górny wrote: |
| 4 |
>>> # multilib.eclass collisions |
| 5 |
>>> get_libdir() { future_get_libdir "${@}"; } |
| 6 |
>>> # eutils.eclass collisions |
| 7 |
>>> einstalldocs() { future_einstalldocs "${@}"; } |
| 8 |
>> |
| 9 |
>> This collision handling mechanism seems pretty reasonable. |
| 10 |
>> Alternatively, maybe it could die if the functions are already defined, |
| 11 |
>> and advise the developer that future should be inherited later than |
| 12 |
>> multilib and eutils. |
| 13 |
> |
| 14 |
> Now I realize that future.eclass has no way of knowing when mutilib or |
| 15 |
> eutils are inherited later. So, I can't think of a better way to handle |
| 16 |
> the collisions that what you already have. |
| 17 |
|
| 18 |
Well, I suppose that multilib and eutils could check to see if future |
| 19 |
was inherited earlier, and die in that case. |
| 20 |
-- |
| 21 |
Thanks, |
| 22 |
Zac |
Archives