Bug#785569: Work in progress in personal GitHub fork

2015-05-18 20:46 GMT+01:00 Mathieu Malaterre <malat@debian.org>:

Hi Ghislain,

On Mon, May 18, 2015 at 9:39 PM, Ghislain Vaillant <ghisvail@gmail.com> wrote:
> The CUDA backend should be more straightforward. Also, I am not sure
> whether it is more desirable to build the CUDA backend and have
> ArrayFire in contrib or stick with just CPU and OpenCL and have it in
> main.

Please keep this package in main. Same thing happen in the past to
libthrust. Having a package in contrib or non-free make it
non-existant to lots of people.

I understand the reasoning, although a significant portion of the scientific crowd still favours
CUDA over OpenCL. The case of libthrust is a bit of a non-issue now, since it is a header-only
library so no build-deps on non-free components like the CUDA stack. On the other hand,
ArrayFire would require the CUDA stack at build time.

Just add a quick documentation to README.Debian to build the CUDA backend.

2cts

I am only interested in the CPU and OpenCL backend so far. This is a good suggestion to provide

the steps to build the CUDA backend from the source package in a README.

Since some of the dependencies required to build the OpenCL backend are missing, wouldn't it be

worth to submit the CPU backend first and later update the package with the OpenCL binaries ?

I am intending to help with packaging clBLAS and clFFT (which Jerome recently started working on I
believe), but these new packages will take quite some time to be reviewed and uploaded to the main
archive, which would postpone the subsequent availability of ArrayFire in Debian.

Additional comments / suggestions welcome :)

Ghis