[Rcpp-devel] Re-using C++ code from a package with modules and defining linker flags using Rscript

Douglas Bates bates at stat.wisc.edu
Mon May 16 00:22:58 CEST 2011


On May 15, 2011 5:17 PM, "Dirk Eddelbuettel" <edd at debian.org> wrote:
>
>
> Hi Jelmer,
>
> On 15 May 2011 at 21:42, Jelmer Ypma wrote:
> | Dear all,
> |
> | This is a question about recommended ways of linking C++ code in an R
> | package to C++ code defined in other R packages (using Rcpp 0.9.4.1
>
> Well, you seem to make the assumption that this would be supported and
> documented. But it is not really.
>
> | and Rtools on Windows). I built package A, which contains C++ classes
> | and uses modules to expose some of the methods in these classes to R.
> | Then I built package B, which uses some of the C++ classes in A
> | directly. I added package A to the LinkingTo: and Depends: fields in
> | DESCRIPTION. In order for R to find the header-files (.h) of package
> | A, when compiling package B, I put those header files in
> | A/inst/include. R-Functions LdFlags() and CxxFlags() are defined in
> | package A, so I can have something like
> |
> | PKG_LIBS = $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e
> | "Rcpp:::LdFlags()") \
> |            $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e
"A:::LdFlags()")
> |
> | in B/src/Makevars.
> |
> | At this point I ran into problems when installing package B (error:
> | failed to load module modA from package A). It turns out the same
> | problem occurs when using a Rcpp skeleton package with modules.
> |
> | library('Rcpp')
> | Rcpp.package.skeleton( 'testmodA', module=TRUE )
> |
> | with one file (e.g. inline.R) added in testmodA/R containing
> | ===
> | LdFlags <- function(print=TRUE) {
> |     if (print) cat("test\n") else return( "test" )
> | }
> | ===
> |
> | Install the package
> | R CMD INSTALL testmodA
> |
> | Including
> | PKG_LIBS = $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e
> | "Rcpp:::LdFlags()") \
> |            $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e
> | "testmodA:::LdFlags()")
> |
> | in package B's Makevars leads to errors during compilation, which I
> | traced back to:
> | > Rscript -e "testmodA:::LdFlags()"
> |
> | Error: .onLoad failed in loadNamespace() for 'testmodA', details:
> |   call: value[[3L]](cond)
> |   error: failed to load module yada from package testmodA
> | Execution halted
> |
> | If I replace this by
> | Rscript -e "library(testmodA); testmodA:::LdFlags()"
> | Loading required package: methods
> | Loading required package: Rcpp
> | test
> |
> | it works as expected, so this is what I use in the Makevars file of
package B.
> |
> | Without modules in testmodA
> | > Rscript -e "testmodA:::LdFlags()"
> | works fine.
> |
> | Is this the recommended way of adding linker and cxx flags to packages
> | depending on other R packages with modules? I tried to look at
>
> We simply show no example of definiting object code in one package and
having
> other packages use it -- with the exception of the Rcpp package itself.
 And
> there it takes quite some effort to make this happen.
>
> You could look at what lme4 and Matrix do; this is documented in the
'Writing
> R Extensions' manual under '[Section] 5.4 Registering native routines'.

Unfortunately that approach doesn't work with C++ classes and methods, which
is one of the reasons that Rcpp linkage has to be done the way that it is.
The exporting of symbols a as done by Matrix is restricted to C function
entry points.

> | packages using RcppArmadillo or RcppGSL for inspiration, but both of
> | these packages don't implement modules. Any other packages I should
> | look at?
>
> RcppArmadillo is very different: it used templates only, no linking.
 RcppGSL
> uses GSL; for that we standard configure and system GSL libraries.  None
of
> these package take anything from another R package, besides Rcpp.
>
> So as a simpler step I would just include package A's code in package B,
or
> make it one package.
>
> Sorry,  Dirk
>
> --
> Gauss once played himself in a zero-sum game and won $50.
>                      -- #11 at http://www.gaussfacts.com
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20110515/3ca06a1c/attachment-0001.htm>


More information about the Rcpp-devel mailing list