[R-pkg-devel] Working with R-devel
luke-tierney at uiowa.edu
luke-tierney at uiowa.edu
Wed Jan 24 14:03:09 CET 2018
On Wed, 24 Jan 2018, Uwe Ligges wrote:
> On 24.01.2018 12:00, Martin Maechler wrote:
>>>>>>> Uwe Ligges <ligges at statistik.tu-dortmund.de>
>>>>>>> on Wed, 24 Jan 2018 11:23:50 +0100 writes:
>> > On 24.01.2018 03:20, Dirk Eddelbuettel wrote:
>> >> I am going in circles here and have lost my way. I used to have
> means to
>> >> build R-devel (still do) and use it for local testing (no longer
>> >> - Fresh build of R-devel
>> >> - One entry in .libPaths()
>> >> - I can install Rcpp, it ends up in that .libPaths()
>> >> - I can load
>> >> - With the _exact same settings_ starting R as R CMD check ... I
> fail on
>> >> ** preparing package for lazy loading
>> >> Error : package ‘Rcpp’ was installed by an R version with different
> internals; \
>> >> it needs to be reinstalled for use with this R version
If you are picking up an R 3.4.x that is trying to load a package
built by R-devel you should also see a warning that the package was
built under R version 3.5.0
If you are not, then you could be picking up an older R-devel from
before the internals change. Probably more likely, the Rcpp being
loaded at that point was built by 3.4.x, which would suggest library
path settings are messed up at that point, but not clear why. [It
might be possible and useful to provide more information about the
broken pieces in the error message but I won't have time to look any
At the moment when it matters I usually use
env R_LIBS=<my R-devel library> R CMD check ...
for checks under R_devel
>> > I guess you actually pick up anotehr version of R.
>> > Carefully check what is on your PATH and perhaps some Renviron files
>> > that may be around?
>> > Best,
>> > Uwe
>> Yes exactly. I've been bitten many times by similar issues in
>> recent weeks.
>> The problem here is that we have so many environment variables
>> governing the process.
>> I think I have mostly solved this by the following "strategy"
>> (Linux/Unixy bash-like shell):
>> ## To check: one of
>> env | grep '^R_'
>> env | grep -E '^_?R_'
>> ## Before running:
>> unset R_PROFILE R_ENVIRON R_LIBS
>> export R_CHECK_ENVIRON=~/.R/check.Renviron_Rdevel
>> ## where my check.Renviron* basically only sets R_LIBS
>> [In an ideal world, R functions involved here would *not* start
>> other R processes... but that seems necessary for other good reasons]
> The simplest one is that R can crash during a check, then you would end
> uo without message where that happened, it is hard to compare timings etc.
> In the real but not so ideal world, I need even a wrapper around R CMD
> check to have control about the process to be able to kill it
> programmaically etc.
>> >> which is both false (see above) and irritating.
>> >> Does anybody have any tips, working guidelines or interpretations
> of the ever
>> >> changing manuals (which charmingly never document what changes) ?
>> >> Dirk
>> > ______________________________________________
>> > R-package-devel at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> R-package-devel at r-project.org mailing list
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
241 Schaeffer Hall email: luke-tierney at uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
More information about the R-package-devel