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

[Dirk Eddelbuettel]

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