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

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

[Craig Andrews]

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

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
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
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.

For (2), I'm concerned that generating and maintaining that patch may be 
really annoying and a lot of work.

For (3), it's not great to have different base archives.

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.

What is the best way forward? And what would be acceptable to the Gentoo 
LLVM project?

Thanks,
~Craig

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Luca Barbato]

On 14/12/2018 21:00, Craig Andrews wrote:
> 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.

I'd rather go with 1 and update the deps once llvm upstream gets the 
right support.

lu

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

[Michał Górny]

[-- 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 --]