1 |
Ciaran McCreesh wrote: |
2 |
> On Wed, 19 Dec 2007 18:59:47 -0500 |
3 |
> Richard Freeman <rich@××××××××××××××.net> wrote: |
4 |
>> Am I missing something? |
5 |
> |
6 |
> Yes. You're missing all the explanations that have already been given |
7 |
> about why it's impossible to parse ebuilds using anything other than |
8 |
> bash. |
9 |
> |
10 |
|
11 |
If the EAPI can be parsed from a filename without using bash, why |
12 |
couldn't it be parsed from a line in the ebuild contents without using |
13 |
bash? |
14 |
|
15 |
An inelegant solution (but possibly more elegant than using filenames) |
16 |
might be to put the EAPI on the first line of the ebuild, with nothing |
17 |
else on that line. Then a simple head -n 1 <file> retrieves the EAPI. |
18 |
Certainly not pretty - but perhaps nicer than putting the EAPI in the |
19 |
filename itself. And I don't see how it is any less flexible than |
20 |
putting it in the filename - if nothing else it would allow you a larger |
21 |
character set without making command-line work painful. |
22 |
|
23 |
However, I still don't see how a regexp wouldn't work - if you made the |
24 |
policy that all ebuilds must have a line that says: |
25 |
EAPI="<something>" - exactly. No spaces, quotes mandatory, etc. That |
26 |
can't be any less painful on devs than putting the EAPI in the filename, |
27 |
and it could be checked for by repoman/etc. Or, if package managers are |
28 |
willing to do a little more work we could allow a little whitespace and |
29 |
make things easier on devs. |
30 |
|
31 |
Issues with not using bash to parse the EAPI value would come into play |
32 |
mainly in situations where putting the EAPI in the filename wouldn't |
33 |
work either. |