| 1 |
On Wed, Nov 18, 2015 at 10:23 AM, Brian Dolbec <dolsen@g.o> wrote: |
| 2 |
> On Wed, 18 Nov 2015 12:02:15 +0100 |
| 3 |
> Alexis Ballier <aballier@g.o> wrote: |
| 4 |
> |
| 5 |
>> On Wed, 18 Nov 2015 21:53:17 +1100 |
| 6 |
>> Michael Palimaka <kensington@g.o> wrote: |
| 7 |
>> |
| 8 |
>> > What do you think? |
| 9 |
>> |
| 10 |
>> |
| 11 |
>> +1 |
| 12 |
>> |
| 13 |
>> even if I sometimes use those cmake-utils_use*, they tend to confuse |
| 14 |
>> me and find -DABCD=$(usex ...) much easier to understand for the |
| 15 |
>> occasional user of cmake-utils.eclass. |
| 16 |
>> |
| 17 |
> |
| 18 |
> |
| 19 |
> Forgive me if I'm wrong, but I thought EAPI 6 specifications were |
| 20 |
> finalized. |
| 21 |
> |
| 22 |
> Doesn't that mean this will have to wait for EAPI 7? |
| 23 |
|
| 24 |
eclass API is not directly tied to EAPI/PMS. However, |
| 25 |
cmake-utils.eclass has this: |
| 26 |
|
| 27 |
case ${EAPI} in |
| 28 |
2|3|4|5) : ;; |
| 29 |
*) die "EAPI=${EAPI:-0} is not supported" ;; |
| 30 |
esac |
| 31 |
|
| 32 |
That means that its API is currently undefined when EAPI is set to 6; |
| 33 |
the eclass will immediately die. |
| 34 |
|
| 35 |
This is just a convenient opportunity to change the API of this eclass |
| 36 |
without risking breakage of existing ebuilds. |
Archives