| 1 |
On Sun, 5 Oct 2008 16:15:46 +0200 |
| 2 |
Alexis Ballier <aballier@g.o> wrote: |
| 3 |
> An eapi.eclass with such functions and lists of eapi & features |
| 4 |
> maintained there could help though. |
| 5 |
|
| 6 |
The problem is, 'features' change between EAPIs. For example, all three |
| 7 |
EAPIs have src_compile, but it does different things for all three. One |
| 8 |
can't assume that a feature working for current EAPIs will carry on |
| 9 |
working for future EAPIs, and even if it does there can be other |
| 10 |
interactions that break. |
| 11 |
|
| 12 |
> An EXPORT_FUNCTIONS ignoring any function its doesn't know for its |
| 13 |
> eapi would help too. |
| 14 |
|
| 15 |
An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place |
| 16 |
checking for eclass screwups... |
| 17 |
|
| 18 |
-- |
| 19 |
Ciaran McCreesh |
Archives