On 24.01.2018 12:00, Martin Maechler wrote:
Uwe Ligges <lig...@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 do).
     >>
     >> - 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

     > 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.

Best,
Uwe







Martin



     >>
     >> 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@r-project.org mailing list
     > https://stat.ethz.ch/mailman/listinfo/r-package-devel


______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to