| 1 |
On Sun, 20 Jul 2008 17:38:32 +0400 |
| 2 |
Peter Volkov <pva@g.o> wrote: |
| 3 |
> В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет: |
| 4 |
> > Which part of the 'Problem' section in the GLEP didn't you |
| 5 |
> > understand? Do you seriously consider not being able to add or |
| 6 |
> > change global scope functions in future EAPIs to be a non-issue, or |
| 7 |
> > were you ignoring those two bullet points? |
| 8 |
> |
| 9 |
> I've read all previous discussions but still miss answer to the |
| 10 |
> question: Why is it impossible to state that .ebuild extension is for |
| 11 |
> bash based ebuild make package manager get and filter EAPIs based on |
| 12 |
> EAPI variable? |
| 13 |
|
| 14 |
I think your question is missing a word or something. I'm not entirely |
| 15 |
sure what you're trying to ask... |
| 16 |
|
| 17 |
But if you're asking why we can't use the EAPI variable, it's because |
| 18 |
we can't get the EAPI variable unless we already know what it is. It's |
| 19 |
only possible currently because all EAPIs have identical global scope |
| 20 |
functions and environment requirements, but future EAPIs want to change |
| 21 |
things there. |
| 22 |
|
| 23 |
> In any case I'd like to understand why should we start support this |
| 24 |
> hell of extensions. |
| 25 |
|
| 26 |
Why do you think it's hell? It's just as easy as having an EAPI |
| 27 |
variable inside the ebuild, and has the added advantage that your |
| 28 |
editor of choice can start doing EAPI-aware syntax highlighting for you. |
| 29 |
|
| 30 |
-- |
| 31 |
Ciaran McCreesh |
Archives