Re: On providing a separate source package for the CUDA build of a library.

[Gianfranco Costamagna <costamagnagianfranco@yahoo.it>]

Hi,

I did the following on a package I maintain
https://sources.debian.net/src/boinc/7.6.17%2Bdfsg-1/debian/control.in/


note: this package is using cuda and opencl by "dlopen", so there is no 
way to detect it at build time.

does this helps you?
(not a clean solution I know)


Il Martedì 15 Dicembre 2015 12:56, Ghislain Vaillant <ghisvail@gmail.com> ha scritto:



Dear all,

I am the maintainer of ArrayFire, a library which offers different 
implementations of the same API as computational backends. So far, I 
have packaged the CPU and OpenCL ones to keep the package in main, but a 
CUDA backend also exists.

Upstream kindly asked whether the CUDA backend could be packaged as 
well, and I wanted to confirm with you guys what my options are. I 
thought about providing an additional source package with the same 
upstream sources, but which would be responsible for building the CUDA 
backend only. I believe this source package (arrayfire-cuda) would have 
to be in contrib since it is open-source licensed but build-depends on 
non-free components (CUDA).

Is this the right way to go? Are there any tips to handle the 
synchronization between the arrayfire and arrayfire-cuda packages? Any 
other examples of a set-up like this in the archive?

Thanks for your advice,
Ghis