| 1 |
Fabian Groffen kirjoitti: |
| 2 |
> On 09-11-2007 23:55:51 +0200, Petteri Räty wrote: |
| 3 |
>> Usually it's best that ebuild variables follow the order that is in |
| 4 |
>> skel.ebuild. So know we should decide where to place EAPI. I suggest we |
| 5 |
>> put it it after LICENSE as that's where the more technical stuff like |
| 6 |
>> SLOT starts. Attached a patch for skel.ebuild. |
| 7 |
> |
| 8 |
> Just my 2 cents, I have placed EAPI right after the # $Header: line of |
| 9 |
> each ebuild, as I felt that it was the first thing to know of the |
| 10 |
> ebuild, as it describes how you possibly have to process the rest of the |
| 11 |
> ebuild. Examples can be found in the prefix overlay, e.g. |
| 12 |
> http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/app-shells/bash/bash-3.2_p17-r00.1.ebuild |
| 13 |
> |
| 14 |
> It has the advantage for me that EAPI is never hidden away somewhere |
| 15 |
> down the ebuild, and it is just inserted by a simple bash script |
| 16 |
> automagically (eapify in this case). |
| 17 |
> |
| 18 |
|
| 19 |
If we go with this solution then I guess eclasses must check for the |
| 20 |
EAPI variable and then act accordingly. For example if the ebuild sets |
| 21 |
EAPI=2 and the eclass is designed for EAPI=1 then it could be made to |
| 22 |
die in case EAPI 2 is not backwards compatible. The main reason for me |
| 23 |
asking this it that I plan to make the java eclasses use the EAPI 1 |
| 24 |
features. |
| 25 |
|
| 26 |
Regards, |
| 27 |
Petteri |
Archives