Le 8 avr. 2014 à 10:12, Xavier Robin <xav...@cbs.dtu.dk> a écrit :
> My 2 cents... > > On 07/04/14 10:12, Romain François wrote: >> It would also mean many copies of the same code base. To which I’m thinking: >> so what. > No, it will mean many copies of /many different and mostly outdated/ code > bases. Still: so what ;) > You can count on me to forget to git pull next time I update my package. And as long as your package keeps working, this is not so much of an issue. You are then in control of which version of the codebase is used. If you want a new version of the codebase, you can get it, and the challenge for me is to make it easy enough for you to get and deploy it into your package, if you don’t that’s fine. Now consider the alternative. You have no idea of which version of the codebase is used with your package. You have no idea if the version used at runtime is the same as the version that was used when the package was compiled. When a new Rcpp package is released, you definitely have to recompile yours, and need to ask your users to recompile your package against this version. I prefer when I’m in control. > What about something like the BH package that contains the boost headers? I'm > using it in a project I'm working on, and just use a LinkingTo declaration > with something in Makevars. That works fine because BH is truly header only. Rcpp is not. The change in Rcpp 0.11.0 was a big step forward, but it is a job half done. Functions in the .h files of Rcpp constantly poke into the Rcpp.so. Any binary change in Rcpp creates hard problem to fix. Currently the usual advice is to ask to recompile, etc ... It is really easy to make such a binary change. > Of course ideally it would be in a build-depends type of declaration so it > isn't pulled during binary installs. > > Xavier _______________________________________________ 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
