| 1 |
On Mon, 17 Dec 2007 17:10:46 -0700 |
| 2 |
Joe Peterson <lavajoe@g.o> wrote: |
| 3 |
> I probably missed some of the stuff leading up to this GLEP, but what |
| 4 |
> is the problem with having the EAPI in the file and determining it by |
| 5 |
> looking at the file contents? |
| 6 |
|
| 7 |
Motivation, second bullet point: |
| 8 |
|
| 9 |
| Possibility to extend the behaviour of inherit and add new global |
| 10 |
| scope functions (as a result of not sourcing ebuilds with unsupported |
| 11 |
| EAPI). |
| 12 |
|
| 13 |
> Making the file extension variable by adding "-<EAPI>" to it would, in |
| 14 |
> my opinion, make the portage tree a bit less clean and not as elegant. |
| 15 |
> Wouldn't software (like editors determining file type by looking at |
| 16 |
> what is after the ".") also need to be reworked to recognize a |
| 17 |
> variable string after "-" at the end? |
| 18 |
|
| 19 |
Yep, but that's not very difficult. And as a side effect, editors could |
| 20 |
then provide EAPI aware highlighting. |
| 21 |
|
| 22 |
> I imagine a lot of people do things now like 'find . -name "*.ebuild" |
| 23 |
> | xargs grep ...'. Not that they could not change their habbits, but |
| 24 |
> forgetting to add a more complex matching rule could lead to errors |
| 25 |
> here. |
| 26 |
|
| 27 |
-name '*.ebuild*' isn't exactly much more complex... |
| 28 |
|
| 29 |
-- |
| 30 |
Ciaran McCreesh |
Archives