| 1 |
On Sun, 5 Oct 2008 15:07:27 +0100 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
|
| 4 |
> On Sun, 5 Oct 2008 15:36:30 +0200 |
| 5 |
> Ulrich Mueller <ulm@g.o> wrote: |
| 6 |
> > How should exporting of src_configure in eclasses be handled? Should |
| 7 |
> > it be conditional, depending on the EAPI? Or is it O.K. to export |
| 8 |
> > src_configure unconditionally, since it doesn't harm for EAPI<2? |
| 9 |
> |
| 10 |
> Export it if and only if EAPI is 2. |
| 11 |
> |
| 12 |
> Note that this means EAPI really really has to be set as the first |
| 13 |
> thing in the ebuild (*cough* or in the file extension). |
| 14 |
|
| 15 |
By the way, do we really want to special case eapi-2 in every eclass ? |
| 16 |
That's lot of code duplication and will get even worse when we'll reach |
| 17 |
eapi-42. That would have been cool to have a pm function that tells |
| 18 |
"has my eapi foo support" but that sort of bites its tail that way. |
| 19 |
An eapi.eclass with such functions and lists of eapi & features |
| 20 |
maintained there could help though. |
| 21 |
An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi |
| 22 |
would help too. |
| 23 |
|
| 24 |
Alexis. |
Archives