1 |
I'm working on packaging the Radeon Open Compute (ROC) packages for |
2 |
Gentoo with first goal being to get the OpenCL runtime working. |
3 |
|
4 |
The OpenCL runtime can be found at: |
5 |
https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime |
6 |
|
7 |
It has a mess of dependencies; I can handle most of them (not that it'll |
8 |
be easy, but at least I know what to do). The 3 troublemakers I'd like |
9 |
to discuss are the ROC forks of: |
10 |
llvm: https://github.com/RadeonOpenCompute/llvm/ |
11 |
clang: https://github.com/RadeonOpenCompute/clang/ |
12 |
ldd: https://github.com/RadeonOpenCompute/ldd/ |
13 |
|
14 |
Potential approaches include: |
15 |
1) Create new packages for each: sys-devel/radeon-open-compute-llvm, |
16 |
sys-devel/radeon-open-compute-clang, sys-devel/radeon-open-compute-lld |
17 |
2) Add use flags to existing packages that apply the ROC changes as a |
18 |
patch |
19 |
3) Add use flags to existing packages that use ROC archives as the |
20 |
SRC_URIs |
21 |
4) Take the approach justxi did in his overlay which is to bundle these |
22 |
dependencies wherever they're needed; for example, take a look at |
23 |
https://github.com/justxi/rocm/blob/master/media-libs/ROCm-OpenCL-Runtime/ROCm-OpenCL-Runtime-1.7.0-r3.ebuild |
24 |
|
25 |
Personally, I dislike (4), as it's contrary to the bundling policy that |
26 |
Gentoo tries to follow. |
27 |
|
28 |
For (2), I'm concerned that generating and maintaining that patch may be |
29 |
really annoying and a lot of work. |
30 |
|
31 |
For (3), it's not great to have different base archives. |
32 |
|
33 |
Since ROC will eventually upstream all of it's work, (2) is ideal - but |
34 |
I have no idea what the timeline on that upstreaming effort may be, and |
35 |
I can't find anything that gives a hint. |
36 |
|
37 |
What is the best way forward? And what would be acceptable to the Gentoo |
38 |
LLVM project? |
39 |
|
40 |
Thanks, |
41 |
~Craig |