1 |
On Fri, Mar 9, 2012 at 12:47 PM, Zac Medico <zmedico@g.o> wrote: |
2 |
> Anyway, lets focus on our main goal, which is to decide on a way to |
3 |
> obtain the EAPI _without_ sourcing the ebuild. |
4 |
|
5 |
Agreed. Plus, an approach that either uses the filename or something |
6 |
like a comment line is also going to be much more flexible if bash |
7 |
syntax changes substantially, or if we want to support |
8 |
ebuilds-in-python or some other approach. |
9 |
|
10 |
That is the main merit I see to the shebang approach - you could |
11 |
define some kind of API that actually involves executing the ebuild. |
12 |
Sticking the EAPI in the filename is a little less complicated and it |
13 |
gives you the same flexibility - I'm not aware of any file format that |
14 |
is fussy about the content of the filename. |
15 |
|
16 |
Even approaches like putting EAPI=5 in the file (even inside a |
17 |
comment) might break if the file is meant to be generally interpreted |
18 |
by some program that has rigid syntax rules. Most scripting |
19 |
languages could probably handle this somehow, but if you ever wanted |
20 |
ELF ebuilds that wouldn't be so likely to fly unless you could embed |
21 |
\nEAPI=ELF8\n in something near the start of the file. |
22 |
|
23 |
Sure, I doubt we'll ever want ELF ebuilds (I'd consider |
24 |
non-programatic ebuilds for more trivial packages more likely), but |
25 |
the point is that we should prefer options that offer more flexibility |
26 |
down the road over ones that solve the immediate need but just leave |
27 |
us with the same debate two years from now. |
28 |
|
29 |
Rich |