[Rcpp-devel] Use of "Depends: Rcpp" in packages using Rcpp

[Dirk Eddelbuettel]

This is a somewhat complicated / technical issue which is further complicated
by the fact that over the 5+ years we have been making CRAN releases of Rcpp,
this procedure also changed.  But read on...

On 7 January 2014 at 00:18, Davor Cubranic wrote:
| On Jan 6, 2014, at 5:45 PM, French, Joshua <JOSHUA.FRENCH at UCDENVER.EDU> wrote:
| 
| > I¹m not sure if this question is in reference to an email from Brian
| > Ripley, but I was under the impression that we should include Rcpp and/or
| > RcppArmadillo in Depends so that it is not installed for binary versions
| > of the packages.  

[ I believe this to be a typo. Joshua probably meant "LinkingTo:" here, not Depends: ]
| 
| It was prompted by that email, yes, but then I started to wonder why have
| Rcpp in the “Depends” in the first place. The code I’m fixing was written
| before I had a good understanding of packages and namespaces, and nowadays
| I think twice before I add something to “Depends” (as opposed to keeping it
| in “Imports”). 
| 
| But I think you missed Ripley’s point: having a package in “Depends” will
| install it even for binary versions of dependents, which is unnecessary for
| a headers-only package like RcppArmadillo. The way to avoid it is to have
| it appear *only* in “LinkingTo”. 

Yes, but this ignores the fact that LinkingTo did not used to work the way it
works now.  That said, it is the _current_ best practice for RcppArmadillo.

So Ripley is right there as far as RcppArmadillo, RcppEigen, BH, .. is
concerned. There are cases when you get by with just using headers (eg when
you do not call fastLm() from RcppArmadillo, say) and in that case you should
do so.
 
| Note that this only applies to RcppArmadillo — Rcpp is not a headers-only
| package. As such, I *thought* I had to have it installed even for binary
| versions of the dependents, in order for them to link to its DLL. But after
| some experimentation with my package, that appears not to be the
| case. FWIW, I was able to have both Rcpp and RcppArmadillo only in
| LinkingTo, and the binary version of my package can now be installed (and
| pass a reasonably complete test suite) even on computers where Rcpp and
| RcppArmadillo are not present. 

Yes, with newer / newest version of Rcpp his is possibly thanks to some
clever reengineering Romain did -- and this is/will be better still with the
next release --- but it also requires all Rcpp-dependents to be rebuilt. 

I am still thinking about how best to approach this.
 
| At first, I thought that maybe in my package I really only use the headers
|  — it’s an old package and I’m not using any “newish” features such as
|  modules. I then realized that Rcpp:::LdFlags is statically linking to
|  “libRcpp.a”, 

Yes, but depends on the platform. On OS X and Windows, it is enforcing static
linking.  It is this step that will go away next.

| so no DLLs are required at runtime. This is on a Mac, and so I don’t think
| it will work on Linux, where Rcpp is built as a dynamic library, at least
| with the current CRAN version (0.10.6). But then I saw on Github that the
| whole business of building (and linking to) an Rcpp library is being
| deprecated.[1] Maybe Romain can comment on this. Rcpp-package vignette
| hasn’t been updated there. 

There are two issues here.  Rcpp always has, and always will, contain a small
binary library. R finds and loads it for all packages.  No concern for users.

In the past and present, and for Rcpp but not RcppArmadillo / RcppEigen, we
also require a linking step with a user library we build in the Rcpp package.

That step will go away in the future, and I'll email more about that another
time.

Dirk

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