We have seen problems with a number of packages which use R/Rscript to
run R code in configure or makefiles.
(a) You must give a full path: there need be no version of R in the
path, and if there is it might not be the version/build of R under which
package installation is being done. So the general form is to use
${R_HOME}/bin/R
to select the right version. And since ${R_HOME} might contain spaces,
you need something like "${R_HOME}/bin/R".
There appear to be bare uses of Rscript in Rcpp RQuantLib bifactorial
mvabund, of bare R in ROracle pgfSweave rcom and many more packages
without quotes.
(b) There are further issues with platforms which use sub-architectures
(mainly Mac OS X and R-devel Windows). On Windows the
architecture-dependent executables will (as from R 2.12.0) be in
subdirectories of ${R_HOME}/bin, so the general form is to use one of
"${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe"
"${R_HOME}/bin${R_ARCH_BIN}/Rterm.exe"
"${R_HOME}/bin${R_ARCH_BIN}/Rcmd.exe"
On R-devel Windows ${R_HOME}/bin/R.exe and ${R_HOME}/bin/Rscript.exe do
exist and are 32-bit executables whose sole task is to launch the
appropriate executable from a sub-directory. Since process creation is
expensive on Windows, this intermediate step is best avoided.
On Mac OS X, ${R_HOME}/bin/R is a script that launches the
architecture-dependent executables from a subdirectory, and on CRAN
builds ${R_HOME}/bin/Rscript is a 'fat' (multi-arch) executable, so the
issues have been worked around (but not necessarily for user installs).
(c) Calling R in configure.win will typically call 32-bit R with R-devel
Windows. If the result needs to depend on the architecture (and e.g. the
library dirs may well) then the work needs to be done in
src/Makevars.win: see the R-devel 'Writing R Extensions' manual for how
to achieve this.
(The reason is that configure.win is called once, and then
src/Makevars.win is called for each architecture.)
BDR