[Rcpp-devel] inline plug-in linking

Dirk Eddelbuettel edd at debian.org
Fri Nov 16 18:34:17 CET 2012


Wow, that was terrible.  Once again, now proofread and edited.

On 16 November 2012 at 08:50, JJ Allaire wrote:
|     Anyhow, I think I am probably missing some linking info from my
|     inlinePlugIn statement.
| 
| 
| This is the key -- plugins that do linking are much more complicated than ones
| that rely on headers only. You can look at the Rcpp and RcppGSL packages as
| examples 

+1 --- at this point I can only offer RcppGSL as a (working!!) example. I
have a blog post planned to illustrate using the new "Rcpp attributes" with
it.  We have no other example using a library.

| -- in short there needs to be a function inside the package that can
| cough up the correct library locations. If you get this far then your stuff

Exactly. Romain coughed up a very clever (as usual) that is not-obvious-to-follow
(no comment ;-) scheme where the plugins essentially act as callbacks.  For
RcppGSL we have the added "fun" of needing to know where libgsl.* and
libgslcblas.* live -- which I solve with a detection at package load-time (when we
call the external gsl-config script) and storing the data in a package-global
little environment.

That works.  On windows, as always, you need more magic and I rely on the
sort-of public knowledge of where CRAN keeps its support libraries so that
packages can build against these. A "generic" Windows solution against
third-party libraries is impossible. 

If you supply your library with the package, then the callbacks are
self-contained within the package.  A bit of work but a) doable and b) a good
chance of being reliable.

| will work with inline and Rcpp::cppFunction, however people developing packages
| that want to link against your stuff will need custom Makevars entries (which
| you can configure the inline plugin to produce, but by now things have gotten
| pretty complicated for your users).
| 
| If you can manage to do header-only "linking" that will be much, much simpler.
| At the lowest level the key to this is R_GetCCallable. In Rcpp land there is a
| GetCppCallable equivalent that works with modules. You can see the use of this
| in the header file which is generated by Rcpp::interfaces(r, cpp).
| 
| If you want to expose the data structure using this mechanism then you could
| write a function like this:
| 
| // [[Rcpp::export]]
| Rcpp::List getModelStatistics() {
|    return StatController::getModelStatistics();
| }
| 
| And then compileAttributes will automatically generate the shim that calls
| GetCppCallable.

That is a fresh alternative.  And all this is work in progress, and your
feedback in testing and pushing it would also be appreciated -- for either
solution.

So in short you can make it work, but you have to put in some extra blood,
sweat and tears before it all falls into place.

Dirk

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


More information about the Rcpp-devel mailing list