[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