What you describe is true on Linux but not on OS X where R uses a framework by
default.
You can have as many version as you want, OS X is using the standard framework
versioning scheme - see also
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html
This means that you can use any version at a given time by simply changing the
"Current" symlink. This applies to compilation as well - the CRAN R is setup
correctly to compile the correct paths for each version. Note, however, that
you cannot run different versions *at the same time*.
Cheers,
Simon
PS: If you want to redistribute your binaries you have to be careful - you'll
have to change libraries linked from your local locations to those inside R if
you want them to be usable by others.
On Apr 26, 2015, at 3:23 PM, Reijo Sund wrote:
> I try to maintain a build system for the R packages so that I can easily
> produce all required Windows and Mac OS X binaries (for R versions 2.15.x and
> up) whenever I update my packages. I acknowledge that excellent services such
> as CRAN or RForge could be used, but to maximise the flexibility required by
> my packages, I prefer to have my own private building system. Currently the
> build system uses several virtual machines and a separate VM is needed for
> Mac OS X Leopard, Snow Leopard and Mavericks. I would like to use the CRAN
> versions of R to maximise the compatibility of binaries.
>
> Unfortunately I have had problems to install multiple CRAN versions of R to
> the same VM. The R-admin manual (chapter 4) gives instructions for installing
> multiple versions (subchapter 4.3), but even if I use pkgutil to forget the
> old version and use command line such as
> /Library/Frameworks/R.framework/Versions/3.1/Resources/bin/R to run R, it
> always launches the version installed latest.
>
> A quick look to the R ”binary" (for which the command line refers to) reveals
> that it is actually a shell wrapper for R executable that contains paths not
> including the version information. It is not difficult to change "hard coded"
> paths R_HOME_DIR, R_SHARE_DIR, R_INCLUDE_DIR and R_DOC_DIR in the wrapper and
> then indeed the correct version launches.
>
> Unfortunately, the building of packages including C code using different
> versions seems not to work for other than the version installed latest even
> after changing the paths; or actually the compilation phase seems to work
> fine and linking paths etc. are conditional to the version, but the "testing
> if installed package can be loaded” results in a segfault. The similar
> procedure works fine for me if I (instead of installing CRAN version of R)
> manually build R from sources to some directory and use it for building of
> packages (I use this technique to build against Aqua Tcl/Tk), but then the
> compatibility of builded binary packages will be restricted to my
> configuration if I have understood correctly.
>
> Currently the only working solution I have found has been to install a new VM
> for each (major) version of R. That is actually a good way also to to update
> the toolchains, but probably and hopefully that is not required for each
> version of R as each new VM increases the burden for maintaining a building
> system.
>
> So even after reading the manuals and FAQs several times, I have not so far
> been able to sort this out myself (i.e. how to use several CRAN R versions to
> build packages containing C code on a same Mac OS X VM), so any tips would be
> appreciated.
>
>
> Best wishes,
>
> Reijo Sund
> Centre for Research Methods,
> Department of Social Research,
> University of Helsinki,
> Finland
>
> ___
> R-SIG-Mac mailing list
> [email protected]
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
