1 |
On Fri, 2018-12-14 at 15:00 -0500, Craig Andrews wrote: |
2 |
> I'm working on packaging the Radeon Open Compute (ROC) packages for |
3 |
> Gentoo with first goal being to get the OpenCL runtime working. |
4 |
> |
5 |
> The OpenCL runtime can be found at: |
6 |
> https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime |
7 |
> |
8 |
> It has a mess of dependencies; I can handle most of them (not that it'll |
9 |
> be easy, but at least I know what to do). The 3 troublemakers I'd like |
10 |
> to discuss are the ROC forks of: |
11 |
> llvm: https://github.com/RadeonOpenCompute/llvm/ |
12 |
> clang: https://github.com/RadeonOpenCompute/clang/ |
13 |
> ldd: https://github.com/RadeonOpenCompute/ldd/ |
14 |
> |
15 |
> Potential approaches include: |
16 |
> 1) Create new packages for each: sys-devel/radeon-open-compute-llvm, |
17 |
> sys-devel/radeon-open-compute-clang, sys-devel/radeon-open-compute-lld |
18 |
|
19 |
Are you really going to maintain that? Are they going to block stock |
20 |
LLVM packages, and require everyone to go through hell, or are they |
21 |
going to be just bundled packages masked as unbundled? |
22 |
|
23 |
> 2) Add use flags to existing packages that apply the ROC changes as a |
24 |
> patch |
25 |
> 3) Add use flags to existing packages that use ROC archives as the |
26 |
> SRC_URIs |
27 |
|
28 |
What makes you believe that ROC is special enough to deserve this? |
29 |
There are Rust fork, Julia fork... all of them going to 'eventually' |
30 |
be merged upstream. Trying to allow even some of them is going to turn |
31 |
LLVM into a maintenance PITA. Not to mention it ain't easy already. |
32 |
|
33 |
> 4) Take the approach justxi did in his overlay which is to bundle these |
34 |
> dependencies wherever they're needed; for example, take a look at |
35 |
> https://github.com/justxi/rocm/blob/master/media-libs/ROCm-OpenCL-Runtime/ROCm-OpenCL-Runtime-1.7.0-r3.ebuild |
36 |
> |
37 |
> Personally, I dislike (4), as it's contrary to the bundling policy that |
38 |
> Gentoo tries to follow. |
39 |
|
40 |
It's no different from (1), except in (1) you pretend it isn't bundled, |
41 |
except it's something nobody else is going to do. |
42 |
|
43 |
> Since ROC will eventually upstream all of it's work, (2) is ideal - but |
44 |
> I have no idea what the timeline on that upstreaming effort may be, and |
45 |
> I can't find anything that gives a hint. |
46 |
|
47 |
So bundle it until it's actually merged. This reduces the work right |
48 |
now, and makes it possible to switch to a 'proper' solution with minimum |
49 |
effort. |
50 |
|
51 |
-- |
52 |
Best regards, |
53 |
Michał Górny |