[R-pkg-devel] Working with R-devel

[Uwe Ligges]

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