On Mon, Apr 7, 2014 at 9:20 AM, Romain François <rom...@r-enthusiasts.com>wrote: [...]
> The only small downsides I see here is that (1) users potentially have to > do more work to include Rcpp* in their packages (although you can just > write an R function to include/update their Rcpp* versions); and that (2) > source packages will be somewhat bigger. > > > The difference is that if they don't want a new version, they can stick > with the version they have in their package. So when they want newer Rcpp, > they can have it, but they are not forced to do anything when the Rcpp* > team wants to update the codebase. > > About 1). We just need to find a good way to propagate newer Rcpp* into a > repo. Maybe through git subtree, git sub modules or something. We can come > up with some tools. > 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. Others might want to have it as submodules. For the latter to work, I imagine you would need to set up some special repo structure. 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. So I think, the question is whether to support this with some infrastructure, e.g. to update the embedded headers, have them as a git submodule, etc. About 2). So What ;) > Agreed. CRAN-core might be fussy about it, though, if source packages get much bigger because of this. Or might be not. Gabor [...]
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
