On 26 September 2015 at 22:29, peter dalgaard wrote: | | > On 26 Sep 2015, at 17:43 , Dirk Eddelbuettel <e...@debian.org> wrote: | > | > R_HOME is set to the result of the command R RHOME if and only it is unset. | > | > And it usually is unset. | | Did you actually mean that, Dirk?
Yes. But I didn't make myself very clear, as you noted. What I meant to say, but did not, sadly, was that via PATH and called the corresponding R front-end script from the particular (via PATH or explicit absolute dir/path/to/R we get R_HOME set by the particular R invoked. Which then calls configure for us, and that is how configure sees it as set without the need for explicit settings. | I would expect that R_HOME would be set by "myR CMD whatever" before it got | to the configure script, so that the default R would only be used as a last | resort. And R rather actively defends itself against R_HOME being set in | its environment. Quite right. | E.g. | | $ R_HOME=/tmp R CMD env | grep R_HOME | WARNING: ignoring environment value of R_HOME | R_HOME=/Library/Frameworks/R.framework/Resources | | (I'm not sure that it is actually supposed to work, but apparently R CMD foo executes 'foo' in the same environment as R CMD check et al.) Some backends take advantage of that. Rserve comes to mind IIRC. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
