[R-pkg-devel] Using the correct R binary in configure script

Jack Wasey jack at jackwasey.com
Sun Sep 27 13:11:40 CEST 2015


Thanks for all your input. I am now aware that the R environment
running configure will have set R_HOME. I had sometimes been running
./configure without R_HOME set, leading to my problem (since in this
case, the configure snippet does assume 'R'). I'll stick to the
official build routine from now on.

It may be helpful to other package developers that I threw a tiny
package up on github to demonstrate this behavior: this could be
useful as a simple test base for people working on configure scripts
in R packages.

https://github.com/jackwasey/configrdev
The script therein tests the package in DIrk's
rocker/r-devel-san-clang which has both R and RD.

Jack

On Sat, Sep 26, 2015 at 4:54 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 26 September 2015 at 22:29, peter dalgaard wrote:
> |
> | > On 26 Sep 2015, at 17:43 , Dirk Eddelbuettel <edd at 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 | edd at debian.org



More information about the R-package-devel mailing list