[R-sig-Debian] GPU packages and 'Debian R Policy'

[Kevin.Buckley at ecs.vuw.ac.nz]

Hi there,

Moving this request for info over from an R-HPC-SIG list thread as
the issue is less HPC than something that has bitten me as a result
of trying to install HPC (read CUDA) R packages.

Background to this is that I have both a Ubuntu host for a Tesla card
that some researchers are looking to do CUDA-related R computation on,
and a prototype, RHEL-based, cluster that is being used to offer a
technology preview, for our central IT facilitator, of the interfaces
to the NZ national-level grid infrastructure, a cluster upon which I
installed R from source into /opt/R, a personal choice, so as to keep
away from /usr/local.

I've thus recently become aware that the Ubuntu R has the de-facto
location of /usr/local/lib/R/site-library as the place that any
packages not available via the package manager should go and that
that location is propagated into R's package build system via use
of the R_LIBS_SITE variable set in R_HOME/etc/Renviron.

As noted in the 'Debian R Policy' discussion I've now read, from-source
R installations have neither /usr/local/lib/R/site-library nor
R_HOME/etc/Renviron out-of-the-tarball.

On my built-from-source R installtion, I had gone down the route of
using /opt/Rlibs, to correspond with /opt/R, and then ensuring
that users would get  R_LIBS=/opt/Rlibs set in the environment
that their jobs would be started in. That worked OK for Rmpi
so I guess I made the (a?) right choice.

My original query had centered around whether or not I could/should
replicate the 'Debian R Policy' approach, for example by simply
linking /opt/Rlibs back to /usr/local/lib/R/site-library or similar.

Not that big an issue, as things work, but a bit of consistency
never did much harm.

I've since hit another snagette though, hence me now formally
posting here so as to get some clarification if at all possible
before addressing the original issue.


On the Ubuntu host for the Tesla, I was trying to install the
cudaBayesreg package.

This gets its compile-time include path by doing an `R RHOME`
and adding "/include" to it.

It thus ends up trying to compile a source code file using

 -I/usr/lib64/R/include

but that fails to pull in the Rmath.h include file that the
source file requires but doesn't find, not least because
there is no `R RHOME`/include.

I thus went looking for said Rmath.h and found one to be at:

 /usr/share/R/include/Rmath.h

and so tried to get the cudaBayesreg installer to take notice
of that location.

I tried a number of approaches to coddling the underlying configure
without much success.

The small success I did have though then showed up that even
though I had an Rmath.h, I didn't have any Rmath libraries,
because, it turns out, they are in a seperate package.

However, on installing Ubuntu's r-mathlib package, I find that
it doesn't put Rmath.h in R_HOME/include but simply dumps it
in the system area /usr/include and uses similar system dirs
for the libs.

Of course, the cudaBayesreg now compiles, but it might as well
not have bothered specifying -I$(R_HOME)/include, as it'll get
the /usr/include copy gratis.

So, what's going on?

1) Should there be an "include" directory under $(R_HOME) or rather
   what R reports as being its "RHOME".

2) Why is there an Rmath.h in

 /usr/share/R/include/Rmath.h

even when you don't have the Rmath package.

3) Why does the Rmath package put its Rmath.h in the system dir
    and not below an "R directory"

If it's of any use, I recently upgraded, on Dirk Eddelbuettel's
advice, the Ubuntu's standard R packages with the 2.12 ones
from a $CRANmirror/bin/linux/ubuntu/

Any thoughts/info welcome,
Kevin

-- 
Kevin M. Buckley                                  Room:  CO327
School of Engineering and                         Phone: +64 4 463 5971
 Computer Science
Victoria University of Wellington
New Zealand