| 1 |
On Thu, 2009-05-28 at 19:17 +0200, Michael Haubenwallner wrote: |
| 2 |
|
| 3 |
> inherit eapi 4 |
| 4 |
> |
| 5 |
> Now when the PM is capable of pre-source EAPI detection, it will set |
| 6 |
> EAPI before sourcing, eapi.eclass can see EAPI already being set and not |
| 7 |
> do the 'exit' in global scope. Or even the PM's inherit-implementation |
| 8 |
> expects to be first called with arguments "eapi 4", and not reading the |
| 9 |
> eapi.eclass at all, so the 'eapi.eclass' does not need to check for |
| 10 |
> anything, just needs to 'exit' when inherited. |
| 11 |
|
| 12 |
Ohw, the latter would be necessary here, or '4.ebuild' would not be |
| 13 |
found. |
| 14 |
|
| 15 |
eapi.eclass could also be renamed to sth. like eapisupport.eclass or |
| 16 |
eapivalidation.eclass, to write this way: |
| 17 |
EAPI="4" |
| 18 |
inherit eapisupport |
| 19 |
But then the eclass has to detect which EAPI's are supported by the |
| 20 |
running PM to 'exit' upon an unsupported one. |
| 21 |
|
| 22 |
Btw.: What do non-EAPI-aware PMs do with ebuilds using EAPI 1 and 2 - |
| 23 |
how become they masked _now_? What did I miss here? |
| 24 |
|
| 25 |
Thanks! |
| 26 |
|
| 27 |
/haubi/ |
| 28 |
-- |
| 29 |
Michael Haubenwallner |
| 30 |
Gentoo on a different level |
Archives