[Rcpp-devel] Re-using C++ code from a package with modules and defining linker flags using Rscript
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>