[R-SIG-Mac] Multiple R versions: set Current via symbolic link: permissions?

[Simon Urbanek]

On Jan 26, 2012, at 4:44 PM, Peter Carr wrote:

> That thread does help and it provides enough information to solve most of my problem. However, it is not clear to me how to change the R_HOME directory so that it is not in the /Library/Frameworks/R.framework directory. This is important to me because I am providing a tool which will automatically install R and I don't want my tool to replace an existing version of R.
> 
> I tried building from source, and immediately ran into two problems:
>    1) I don't know enough to know how to configure my build so that it doesn't use the Frameworks location

You don't need to use the framework version of R if you don't need the GUI. If your copy will be "private" you can use --disable-R-framework and set rhome at install time to wherever you want (or alternatively you can set the path of the framework if you need it). Note that you'll have to re-compile all packages as well.


>    2) specifically to R 2.5, which I need, I get compiler errors.
> 

You'll have to share much more detail. Note that such an ancient version of R may not be buildable on your system without SDKs for older OS X versions (and note that recent Xcode tools default to 64-bit which was not supported back then so you may need to use 32-bit).


> I'd like to simply take apart the framework build I get when install from the R-2.5.1.dmg.

It is possible, albeit convoluted. The easy part of to modify R_HOME - you simply do that in the R script. The harder part is that all binaries have absolute paths to libraries inside the framework. You will have to go through every single binary (package, module, executable) and change all paths to your new location using install_name_tool. To be honest, given how ancient your R is I wouldn't even bother and just keep it in its 2.5 folder since chances that it will clash on user's machine are close to zero. But if you choose to tackle this, you can take inspiration from this script (it uses @rpath which is a bit more flexible but requires more support from binaries):

https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R-build/rpath.sh

An alternative fix is to use DYLD_LIBRARY_PATH to prepend your new location of libraries. It may or may not work, depending on what you use from R. It is a bit fragile but is fairly easy to do so you can test whether it works for your particular setup of using R.


> However, I'd also like this to work, even when I move this to a different location on my file system. I appreciate some guidance on this last step.
> 

That is actually close to impossible unless you are ok with giving up package installation. The problem is that a) binary package have full paths encoded and b) if you compile a package it will get full path and they need a path to compile. However, if you are shipping a "fixed" R that will not be modified by adding packages, you can use the same idea as above with the special @executable_path prefix. You'll need to perform some gymnastics to infer R_HOME in the R script since it will by dynamic, but it's possible -- the following patch will give you an idea:

https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R-build/R-rpath-diff

The executive summary is that what you want is possible, but not really easy.

Cheers,
Simon