[Rd] compiling C code using headers from another R package
edd at debian.org
Tue Mar 12 16:14:39 CET 2013
On 12 March 2013 at 08:26, Simon Urbanek wrote:
| On Mar 11, 2013, at 5:20 PM, Kevin Horan wrote:
| > I am developing an R package, eiR, which depends on another C library, GNU scientific library (GSL). In order to make life easier for the user, it would be nice to not have this as an external dependency, thus I would like to wrap this library in another R package, say GSLR for example. Thus far I know how to do this. The C code in eiR requires the .so library and the header files from GSL in order to compile. So the idea is that eiR would depend on GSLR, then GSLR gets compiled and installed first, then, while eiR is installing, it should be able to make use of the GSL library and header files while compiling. So my question is, how do I know where the GSL library and header files, packaged in GSLR, would live so I can point the compiler at them? I know how to find the installed directory of an R package from within R, but is there way to find that out using just Makevars or a Makefile? I'm open to suggestions about a better way organize all of this as well. I like the i!
| dea of keeping the GSL code separate so that it can be updated/changed independently from eiR though.
| Have a look at Rcpp.
And particularly the RcppGSL package which even includes a complete working
example calling a single GSL function, a vector norm.
Users still need an external GSL to link (on Unix and OS X, om Windows CRAN
has this covered as I recall).
| > I'm also aware of the gsl R library on CRAN, however, this just wraps GSL in R functions, but I need to use the GSL C functions in other C code in eiR.
| Why is what you are proposing any better than simply using GSL in eiR? You will still need the GSL external dependency for GSLR and you are only adding a lot of complexity by linking into another package's external directory (you cannot use libs) which is in itself very tricky (you'll have to deal with both static and shared version, multi-arch setups, possible relocation etc.). It won't make it any easier on the user, rather to the contrary as there will be more things to break. The only reason Rcpp goes into such length to do this is because it has no choice (the Rcpp library has to use the same libR so cannot be used as external dependency) - I would certainly not recommend it for something as trivial as providing GSL.
| > Thanks.
| > Kevin
| > ______________________________________________
| > R-devel at r-project.org mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-devel
| R-devel at r-project.org mailing list
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
More information about the R-devel