| 1 |
On 2020-04-05 06:44, Michał Górny wrote: |
| 2 |
|
| 3 |
>> +EAPI=6 |
| 4 |
> Is there really a good reason to use an old EAPI here? |
| 5 |
|
| 6 |
None other than me having assumed that there must have been an important |
| 7 |
reason why such a simple ebuild had not been bumped to EAPI 7 yet. Will |
| 8 |
change this in the next iteration. |
| 9 |
|
| 10 |
>> +RDEPEND="app-eselect/eselect-opencl |
| 11 |
>> + dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]" |
| 12 |
> |
| 13 |
> Wouldn't it make sense to remove the virtual and just have stuff depend |
| 14 |
> on that instead? |
| 15 |
|
| 16 |
It would if there only were only one ICD loader in the tree - but there |
| 17 |
are two, this one and dev-libs/opencl-icd-loader. Overall it seems the |
| 18 |
latter might be preferable in the long run (official Khronos Group |
| 19 |
loader, much smaller output library, supports the new unified headers, |
| 20 |
the last ocl-icd release came out in November 2017 and there has been |
| 21 |
minimal repo activity since then) but with it having only been |
| 22 |
officially released in mid-March and with me having only just added it |
| 23 |
to Gentoo, I feel I'd rather test it for a while before listing it as an |
| 24 |
alternative in the virtual. |
| 25 |
|
| 26 |
Moreover, for the time being we still need eselect-opencl here even if |
| 27 |
we are no longer to use to switch between implementations because |
| 28 |
somewhat surprisingly (to me anyway), the package in questions installs |
| 29 |
OpenCL header files too. |
| 30 |
|
| 31 |
> This looks like README.gentoo material. |
| 32 |
|
| 33 |
Will do. |
| 34 |
|
| 35 |
-- |
| 36 |
MS |
Archives