[Rcpp-devel] Distribution of Rcpp codebase

[Gábor Csárdi]

On Mon, Apr 7, 2014 at 9:20 AM, Romain François <romain at 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

[...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140407/d3281b10/attachment-0001.html>