On Mon, Apr 7, 2014 at 2:19 PM, Romain François <[email protected]>wrote: [...]
> Oh, I see, you mean installing Rcpp* dependent packages from git(hub) > directly. I imagine some people would want to put the headers into their > tree, as ordinary files. > > > Having the files into the client package is what I meant. This way, the > developer of the package is in control of what version is used. The > challenge is how to make it easy. > Sure, we are on the same page here. What I meant is that if the client package is on CRAN, then you'll have to include the Rcpp* header files in the package, obviously. Unless you create Rcpp* packages that contain multiple versions of the headers, in different folders..... Personally, if I created a client package for Rcpp11 today, I would just copy over the header files, in a subfolder, and keep them unchanged, so that it is easy to update them with a delete/copy. If there is an RcppJam package that can update these files, perhaps add compilation flags, etc., that's also great. > Btw. I obviously don't have to tell you, but I want to point it out that > this "snapshotting" is already possible today. I can just take the Rcpp* > headers and put them in my package, and then I don't have to worry about > future changes. This is assuming the package is header-only. With compiled > code it is trickier, because of the name clashes. > > > Good luck doing that with current Rcpp. Many functions are compiled into > the shared library shipped with the package. It is not linking as it used > to do it, which is the big win of 0.11.0, but there is still a library. > > Many of these functions go through the namespace of the Rcpp package, etc > ... so you could snapshot Rcpp, but it would definitely not be easy at all. > I agree. With header-only packages it'll be easy. With compiled code it is trickier, but C++ is actually easier than C, because for the name clashes, you can just put the code in a new namespace. Then you'll need to redefine "::" and ".Call" in your package, and even this might not be enough, especially for Rcpp. Gabor
_______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
