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 <[email protected]> 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
