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 <e...@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@max:~$ R RHOME # default installation
> /usr/lib/R
> edd@max:~$ RD RHOME # alternate R-devel with a short-hand
> wrapper
> /usr/local/lib/R-devel/lib/R
> edd@max:~$ which RD
> /home/edd/bin/RD
> edd@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@max:~$ R-devel.sh RHOME
> /usr/local/lib/R-devel/lib/R
> edd@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 | e...@debian.org
> <javascript:;>
>
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
