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

2018-12-14 Thread Michał Górny
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


signature.asc
Description: This is a digitally signed message part


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

2018-12-14 Thread Craig Andrews
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


signature.asc
Description: OpenPGP digital signature