On 14 October 2014 at 13:29, David Ibarra Gómez wrote:
| I usually build C++ executables on debian 7 (x64) that calls R
| using RInside. It just so happens that everything it?s working with R 2.15 and
| RInside 0.29. But I wanted some new features of some packages, but It?s seem
| mandatory to upgrade R > 3.0.
The way the R ecosystem works is that CRAN sometimes suggests we make changes
in packages, which then in turn depend on something in the R 'system'.
The clearest recent example was a move of the vignettes/ directory, which in
turn with changes in R, lead many packages have a Depends: R (>= 3.0.0)
If you know what you are doing, none of this is binding to you. The __only__
interface Rcpp touches from R is
SEXP .Call(SEXP a, SEXP b, ...)
and as this is plain C nothing has changed [1]. So there should be no
changes on your side you could not accomodate with, if need be, some editing
of the DESCRIPTION files.
In a nutshell: there is no issue here you can't address, but as you have not
asked a concrete (reproducible) question I can't give a more concrete answer.
| Originally I installed R (2.15) and RInside from sources with some special
| configuration options (i.e. ./configure --with-x=no LIBnn=lib
| --enable-R-shlib).
R configuration has little to do with on R package builds.
| The question is: To upgrade R and R Inside should I follow the analogous way
| (install from source with special options)? or it?s possible and recommendable
| to use apt-get with some ?dev? flag.
Whether you use apt-get for prebuild binary, or work from source has not so
much to do with Rcpp and more with how you run your system -- maybe a
question for r-sig-debian?
For what it is worth, on all my .deb systems at home and work, I install Rcpp
and friends from source.
Hope this helps, Dirk
[1] As an aside, and despite what some may claim, this also means that it
does not matter which C++ dialect or flavour you use -- they all communicate
with R via the same plain C interface -- and favouring one to the exclusion
of the others is at the end of the day just a constraint on what you can, or
cannot, use. I rather avoid such constraints, but it is fine that people have
choices.
|
|
|
| Regards
|
|
|
|
|
|
|
|
|
|
|
| cid:image004.jpg@01CCF71E.03D7B6D0
|
| David Ibarra Gómez
|
| Jefe de Proyectos
|
| Dirección de Ingeniería de
| Sistemas
|
| Aqualogy Aqua Ambiente
|
| diba...@aquology.net
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-------------------------------------------------------------------------------
| Disclaimer: http://disclaimer.aqualogy.net/
| _______________________________________________
| 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
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
_______________________________________________
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
