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

Henrik Bengtsson henrik.bengtsson at ucsf.edu
Sat Sep 26 19:45:49 CEST 2015


Not sure I understand what you're doing and in what context, but if
you're trying to query R for where it lives, the following may help.
Note that executables or where they live do *not* follow solely from
R.home() - there's more to it.

## Windows
$ Rscript -e "R.home()"
[1] "C:/PROGRA~1/R/R-devel"

$ Rscript -e "R.home('bin')"
[1] "C:/PROGRA~1/R/R-devel/bin/x64"

$ Rscript -e "commandArgs()[1L]"
[1] "C:\\PROGRA~1\\R\\R-devel\\bin\\x64\\Rterm.exe"

(there is typically another 32-bit binary under ..bin\i386\ on Windows)


# Linux
$ Rscript -e "R.home()"
[1] "/path-to-software/R/R-3.2.2-20150814/lib64/R"

$ Rscript -e "R.home('bin')"
[1] "/path-to-software/R/R-3.2.2-20150814/lib64/R/bin"

$ Rscript -e "commandArgs()[1L]"
[1] "/path-to/software/R/R-3.2.2-20150814/lib64/R/bin/exec/R"

# Linux R 2.11.1
cclc01{henrik}: /path-to/software/R-2.11.1/bin/Rscript -e "R.home()"
[1] "/path-to/software/R/R-2.11.1-20150918/lib64/R"


# OS X
$ Rscript -e "R.home()"
[1] "/Library/Frameworks/R.framework/Resources"
$ Rscript -e "R.home('bin')"
[1] "/Library/Frameworks/R.framework/Resources/bin"
$ Rscript -e "commandArgs()[1L]"
[1] "/Library/Frameworks/R.framework/Resources/bin/exec/R"

My $.02

Henrik

On Sat, Sep 26, 2015 at 9:32 AM, Jack Wasey <jack at jackwasey.com> wrote:
> Dirk, thanks for detailed reply. I may not have explained myself well
> enough. I think the problem is that the recommended configure command
> assumes 'R', not the actually running RD, Rdevel etc, when inferring
> R_HOME. I can indeed set R_HOME, but I want my configure script to be able
> to figure out which R is running, and thus which R_HOME to use when it is
> not set.
>
> Your RQuantLib seems to use the same bare 'R RHOME', yet if a package is R
> CMD installed with RD, the configure script will in fact not run RD, but R,
> to find R_HOME. I think it is usually not apparent because the compile
> flags derived from R_HOME/bin/R CMD config are usually the same or similar,
> but when, in my case, I have R compiled with OpenMP, and RD with
> sanitizers, but without OpenMP, this fails because of the discrepancy.
>
> Again, I feel like I'm missing something obvious, but I hope my explanation
> of what I think is happening may help you guide me.
>
> Best wishes,
>
> Jack
>
> On Saturday, September 26, 2015, Dirk Eddelbuettel <edd at debian.org> wrote:
>
>>
>> On 26 September 2015 at 10:27, Jack Wasey wrote:
>> | Having just read section 1.2 in Writing R extensions, a fragment of a
>> | configure script is offered in order to determine the correct compiler
>> | options. It starts by setting R_HOME with:
>> |
>> | : ${R_HOME=`R RHOME`}
>> |
>> |
>> | `R` is called, even if, as in my case, `Rdevel` is the command used to
>> | invoke package compilation. This can be overridden by setting R_HOME
>> | in the call to `Rdevel`, but this seems to be undesirable, since the
>> | whole point of a configure script is that it sets up the package given
>> | the constraints of the compiling environment.
>>
>> [...]
>> |
>> | Am I doing something wrong?
>>
>> R_HOME is set to the result of the command R RHOME if and only it is unset.
>>
>> And it usually is unset.  This scheme generally works, I use it in a few
>> packages on CRAN which had it for years -- and it was initially suggested
>> to
>> my by Kurt to make precisely _this_ work:  you set a different $PATH, or
>> call
>> a different R engine.  And the right thing happens:
>>
>>   edd at max:~$ R RHOME            # default installation
>>   /usr/lib/R
>>   edd at max:~$ RD RHOME           # alternate R-devel with a short-hand
>> wrapper
>>   /usr/local/lib/R-devel/lib/R
>>   edd at max:~$ which RD
>>   /home/edd/bin/RD
>>   edd at max:~$
>>
>> The (nice) idea of calling R-devel just 'RD' appears due to Winston.  It
>> works the same way if I just call R-devel-sh as I had for years:
>>
>>   edd at max:~$ R-devel.sh RHOME
>>   /usr/local/lib/R-devel/lib/R
>>   edd at max:~$
>>
>> So if you still think it fails for you, compare to e.g. the packages
>>
>>   nloptr
>>   RProtoBuf
>>   RQuantLib
>>   RVowpalWabbit
>>
>> all of which use this scheme.
>>
>> Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>> <javascript:;>
>>
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



More information about the R-package-devel mailing list