<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 7, 2014 at 4:12 AM, Romain François <span dir="ltr"><<a href="mailto:romain@r-enthusiasts.com" target="_blank">romain@r-enthusiasts.com</a>></span> wrote:</div>
<div class="gmail_quote">[...]<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">However, in terms of wins:<br>
- package developers would know for sure which version of the codebase is used with their package. Once they have done testing, they don’t have to be hostage of api breakage and things like « please recompile your package, etc … »<br>

- developers of Rcpp* are less trapped by the compatibility issues, hands are set free to innovate.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Btw. you are essentially "simulating" versioned package dependencies this way. :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The next thing to consider is that Rcpp is not just Rcpp, there are really nice extensions like RcppArmadillo, etc ... perhaps we could setup some tools (e.g. RcppJam) to combine several header only libraries into the end package, instead of what we do now, which is have some headers in Rcpp, some in RcppArmadillo, some in RcppGSL, … with every risk of one being outdated or out of sync with the other.</blockquote>
<div><br></div><div>Exactly. IMHO this could work well and take the pressure of both Rcpp* developers and users.</div><div><br></div><div>Gabor</div></div></div></div>