1 |
On Sun, Mar 11, 2012 at 7:20 PM, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring <ferringb@×××××.com> wrote: |
3 |
>> Pragmatic reality, the eapi function actually would work fine. As |
4 |
>> pointed out elsewhere, bash parses as it goes- which isn't going to |
5 |
>> change. |
6 |
> |
7 |
> Unless the ebuild isn't written in bash... |
8 |
|
9 |
I'd opt for a different extension in that case actually. |
10 |
|
11 |
> |
12 |
> How do you source the ebuild if you don't know what to use to source |
13 |
> it? How do you know what to use to source it if you don't know the |
14 |
> EAPI? Right now all the existing EAPIs use bash, but there is no |
15 |
> reason the file couldn't be xml, or python, or just about anything |
16 |
> else. |
17 |
> |
18 |
> If we want to allow for that kind of flexibility, then it might make |
19 |
> sense to go ahead and state that our convention is to stick EAPI=5 in |
20 |
> one of the first few lines of the ebuild, or inside a comment, but |
21 |
> also go a step further and state that the text "EAPI=" cannot appear |
22 |
> elsewhere in the ebuild (or perhaps within the first 10 lines). Just |
23 |
> about any file format we might use would allow us to make "EAPI=" |
24 |
> appear in it, but not all could guarantee that it would occur at the |
25 |
> start of a line, or at the start of a line immediately after a #. |
26 |
> |
27 |
> In any case, I can really see the KISS value in a very rigid syntax |
28 |
> that is trivial to parse. Stuff like this almost makes me wish our |
29 |
> ebuilds already were xml files or such, with bash embedded inside |
30 |
> sections. Finding a particular tag in an xml file is trivial as the |
31 |
> fundamentals haven't changed in 15 years. |
32 |
|
33 |
I will stab the next person who suggests 'xml-like ebuilds.' |
34 |
|
35 |
-A |
36 |
|
37 |
> |
38 |
> Rich |
39 |
> |