R SIG Debian - Jan 2011 - GPU packages and 'Debian R Policy'

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

I am about to go running so I just scanned this for now. See below.

On 20 January 2011 at 18:03, Kevin.Buckley at ecs.vuw.ac.nz wrote:
| 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.

Red herring. Rmath is for _separate non-R programs wanting to link with the
functions in that header_ which is why that 
 
| 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".

No. Years back I worked with R Core to make R itself use a different variable
rather than cutting and pasting "$RHOME/include"
 
| 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"

See above. Maybe it is

4) cudaBayesReg has a weak/broken install script.

I'd treat this as a local cudaBayesReg problem. I have yet to install that
package. The main CUDA package (gputools) works fine.

Gotta go. More later, maybe.

Dirk
 
| 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
| 
| _______________________________________________
| R-SIG-Debian mailing list
| R-SIG-Debian at r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com