Re: [gentoo-dev] How to handle ROC forks of llvm and clang

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

On Fri, 2018-12-14 at 15:00 -0500, Craig Andrews wrote:
> I'm working on packaging the Radeon Open Compute (ROC) packages for 
> Gentoo with first goal being to get the OpenCL runtime working.
> 
> The OpenCL runtime can be found at: 
> https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime
> 
> It has a mess of dependencies; I can handle most of them (not that it'll 
> be easy, but at least I know what to do). The 3 troublemakers I'd like 
> to discuss are the ROC forks of:
> llvm: https://github.com/RadeonOpenCompute/llvm/
> clang: https://github.com/RadeonOpenCompute/clang/
> ldd: https://github.com/RadeonOpenCompute/ldd/
> 
> Potential approaches include:
> 1) Create new packages for each: sys-devel/radeon-open-compute-llvm, 
> sys-devel/radeon-open-compute-clang, sys-devel/radeon-open-compute-lld

Are you really going to maintain that?  Are they going to block stock
LLVM packages, and require everyone to go through hell, or are they
going to be just bundled packages masked as unbundled?

> 2) Add use flags to existing packages that apply the ROC changes as a 
> patch
> 3) Add use flags to existing packages that use ROC archives as the 
> SRC_URIs

What makes you believe that ROC is special enough to deserve this? 
There are Rust fork, Julia fork... all of them going to 'eventually'
be merged upstream.  Trying to allow even some of them is going to turn
LLVM into a maintenance PITA.  Not to mention it ain't easy already.

> 4) Take the approach justxi did in his overlay which is to bundle these 
> dependencies wherever they're needed; for example, take a look at 
> https://github.com/justxi/rocm/blob/master/media-libs/ROCm-OpenCL-Runtime/ROCm-OpenCL-Runtime-1.7.0-r3.ebuild
> 
> Personally, I dislike (4), as it's contrary to the bundling policy that 
> Gentoo tries to follow.

It's no different from (1), except in (1) you pretend it isn't bundled,
except it's something nobody else is going to do.

> Since ROC will eventually upstream all of it's work, (2) is ideal - but 
> I have no idea what the timeline on that upstreaming effort may be, and 
> I can't find anything that gives a hint.

So bundle it until it's actually merged.  This reduces the work right
now, and makes it possible to switch to a 'proper' solution with minimum
effort.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]