[Rcpp-devel] Rcpp Makevars COPYING policy?

Romain Francois romain at r-enthusiasts.com
Wed Oct 16 09:46:40 CEST 2013

Jonathan, Rconsider the // [[Rcpp::interfaces(cpp)]] attribute. That is 
documented in the attributes vignette.

In essence, in the host package (called "host" here), you have this in 
your C++ file:

#include <Rcpp.h>
using namespace Rcpp;

// [[Rcpp::interfaces(cpp)]]

// [[Rcpp::export]]
NumericVector fun() {
     return rnorm(10) ;

// [[Rcpp::export]]
NumericVector foo(double x) {
     return rnorm(10) ;

With Rcpp::interfaces(cpp) you express that you want these functions 
available at the C++ layer in client packages.

Then you call compileAttributes and build the "host" package.

Now, when you want to use it in the client package, you do:
- add LinkingTo: host in client's DESCRIPTION
- include the host.h file
- refer to functions from host with the host:: namespace in C++ code, e.g. :

#include <host.h>

// [[Rcpp::export]]
List do_stuff() {

     List res = List::create(
         ) ;
     return res ;

That's it. The code generated by compileAttributes takes care of 
registering and retrieving the functions.


Le 16/10/13 04:34, Jonathan Olmsted a écrit :
> Finally, some closure...
> Romain, as you sensed, I did not *really* need linking. Of course, I did
> not realize that earlier. You were completely right to point in the
> direction of registering functions. And, while I wish this was some new
> feature, it's been in R for a *long* time. How the answer could be
> mentioned in R-exts with me completely missing it I have no idea (but
> I'm not surprised, I guess).
> It took me longer than I'm willing to reveal to get the functions
> registered in the "host package" (if you will). It then took me another
> similarly long block of time to figure out function pointers. And, it
> then took me a third one of these blocks to figure out how "LinkingTo"
> factored in (prior to this, I'd been calling "R_GetCCallable" on the
> "client package" side. However, I finally got that squared away after
> working through the Rcpp11 repo. As you well know, this approach is
> impressively clean from the perspective of the "client package". Just
> include a header and you are done.
> Darren, I thought I'd just ask about permission first before making
> someone think hard about an already solved problem. But, that's a clever
> idea all the same.
> One sticking point for me was inferring the general from that the
> examples (e.g., Rcpp11, Matrix) which used slightly different approaches
> and, of course, had other moving parts.
> Dirk, If I just looked in the right spot of xts, I'd have seen the
> header trick on the "host package" spelled out in plain English. *sigh*
> In general, I'm quite curious how widely used this is (just a matter of
> a script over the DL-ed ReverseDepends of Rcpp packages) . It'd be a
> shame for devs not to use it more and expose their functionality.
> Many thanks for everyone's help!
> -Jonathan
> -------------------------------------------------------------------------
> J.P. Olmsted
> j.p.olmsted at gmail.com <mailto:j.p.olmsted at gmail.com>
> http://about.me/olmjo
> -------------------------------------------------------------------------
> On Tue, Oct 15, 2013 at 7:01 PM, Darren Cook <darren at dcook.org
> <mailto:darren at dcook.org>> wrote:
>      > Intellectual property rights confuse the heck out of me so I
>     wanted to ask
>      > explicitly before stepping on any toes. Rcpp is GPL-2. However, the
>      > Makevars in the ./src/ directory don't necessarily carry the same
>     license
>      > header as your Cpp source. What are your intentions for
>     derivative use of
>      > the Makevars files you guys use in Rcpp? Specifically, I would
>     like to use
>      > your strategy in an R package to build a static lib for
>     subsequent linking
>      > against by other R packages.
>     You could also describe your actual need on StackOverflow; IIRC the
>     terms and conditions explicitly say all code posted there can be treated
>     as public domain.
>     If someone gives you the same approach then perhaps there is only one
>     way to do it; if someone gives you a different way perhaps that will be
>     just as good.
>     Darren
>     P.S. This idea falls flat if someone just says take a look at the Rcpp
>     Makevars file ;-)
>     _______________________________________________
>     Rcpp-devel mailing list
>     Rcpp-devel at lists.r-forge.r-project.org
>     <mailto:Rcpp-devel at lists.r-forge.r-project.org>
>     https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> _______________________________________________
> 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

Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

More information about the Rcpp-devel mailing list