[R-SIG-Mac] R as OS X Framework

[Jan de Leeuw]

This is a major step in the right direction. I know that Duncan has at  
least
the beginning of an R bridge to the Cocoa toolkits, which would be the
second major step. It will make it possible to write stand-alone R based
applications with a Cocoa GUI, of which R.app will just be a major  
example,
but of which Rglm.app or Rcluster.app could be other examples (with
problem specific menus and graphics). And these could all be developed
nicely by having a Xcode plugin for R. These steps emphasize the  
strengths
of OS X (as the quartz device already does) and do not just give another
boring shell around the command line interpreter. Getting away from  
Carbon
in this way is important, and you don't have to learn Objective C to
program in Cocoa.

By the way, as another example, the quartz device works fine from
Rpy running in one of the Python or wxPython GUI's (which have
decent eventloops). See the desktops at gifi.stat.ucla.edu/pub.

On Nov 29, 2003, at 16:45, Simon Urbanek wrote:

> After the recent discussion about future direction of the Mac OS X  
> port, I was toying with the idea to make R a proper Mac OS X  
> framework. There are several advantages: OS X locates frameworks  
> automatically, therefore any program wishing to link against R has  
> only to specify "-framework R" at link time. Furthermore versioning is  
> supported, i.e. if a program is linked against R 1.7.1 and you install  
> 1.9.0 later, then the program will still get the correct 1.7.1 version  
> (if we define the 1.9.0 not to be compatible with 1.7.1), but any new  
> program will link against the most recent R. The granularity is up the  
> framework creator.
>
> It is possible to easily create a R Framework just with the current R  
> as follows:
>
> configure your favorite R (I'll use 1.8.1 for illustration) but use  
> the following prefix:
> --prefix=/Library/Frameworks/R.framework/Versions/1.8.1/Resources
> you should also add --enable-R-shlib (if you want to use  
> --enable-aqua, read on first!)
>
> after make / make install run the following script as root (you may  
> want to edit it if you didin't use 1.8.1 or if you want to install an  
> user-private framework):
>
> http://stats.math.uni-augsburg.de/misc/Rframework.sh
>
> This will create a proper framework from what the R installer created  
> - and you're all set! You can use such framework for any program -  
> just like Apple's system frameworks. It's really great what you can do  
> with Xcode then (code completion of R stuff, zero-linking etc ;)). For  
> a screenshot of Xcode using R framework, see:
> http://stats.math.uni-augsburg.de/misc/Rframework.png
>
> You can even make a symlink from  
> /Library/Frameworks/R.framework/Resources/bin/R to /usr/binR and you  
> will have the most recent R always at your fingertips.
>
> The nice thing is that you can use ~/Library/Frameworks instead of the  
> above /Library/Frameworks if you want. There is no difference from  
> system's point of view. You could event supply the R framework inside  
> you application's bundle, but I guess that'd be an overkill ;)
>
> Now for some issues that need to be solved:
>
> The current R needs R_HOME to be set before using it even in its  
> embedded form. Now this defeats the idea of location independence of  
> the framework. The application doesn't have to care whether the  
> framework is in /Library/Frameworks, ~/Library/Frameworks or any  
> user-defined framework location. Therefore it would be nice to have a  
> tiny function in the R shlib, that would tell me where the shlib lives  
> (either by using system's API to determine its own location, or at  
> least the path used on installation).
>
> BTW: This is not Mac specific - I was fighting this on Windows (and  
> unix for that matter) as well - it is possible to run an .exe linked  
> to R.dll from anywhere, if R.dll is in the PATH. But then, one has to  
> determine R_HOME somehow (yes, there is the registry, but that's not  
> really safe if more R versions are installed).
>
> The second issue is a rather minor one which will be solved if RAqua  
> uses the framework. If you used --enable-aqua then configure overrides  
> the dylib location, which is bad for our framework:
> configure.ac @ 1050:
>    if test "x${want_aqua}" = xyes; then
>       LIBR_LDFLAGS="-dynamiclib -install_name  
> /Applications/StartR.app/RAqua.app/Contents/Frameworks/libR.dylib"
>     else
>       LIBR_LDFLAGS="-dynamiclib -install_name  
> \$(Rexeclibdir)/libR.dylib"
>     fi
> You'll need to remove the aqua part of it, otherwise the libR.dylib is  
> not expected inside the framework.
>
> Finally, in order to take advantage of the versioning, we should add  
> version information to the dylib. This can be done by adding   
> -dylib_compatibility_version and  -dylib_current_version to the  
> LIBR_LDFLAGS (e.g. for R-1.8.1 probably 1.8.0 to compatibility and  
> 1.8.1 to current).
>
> BTW: A side note - if the host application runs a proper event loop  
> (like my Rgui runs the standard Cocoa event loop) then the Quartz  
> device works flawlessly even without RAqua! Good job, Stefano!
>
> There is still room for improvement - I started this more as a proof  
> of concept and was surprised how smoothly it went. Someone interested  
> might look into issues like using Tcl/Tk, placing libraries  
> conveniently (in ~/Library/Application Support/R/library ?) etc.
>
> ---
> Simon Urbanek
> Department of computer oriented statistics and data analysis
> Universitätsstr. 14
> 86135 Augsburg
> Germany
>
> Tel: +49-821-598-2236
> Fax: +49-821-598-2280
>
> Simon.Urbanek at Math.Uni-Augsburg.de
> http://simon.urbanek.info
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-mac
>
>
===
Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
Editor: Journal of Multivariate Analysis, Journal of Statistical  
Software
US mail: 8130 Math Sciences Bldg, Box 951554, Los Angeles, CA 90095-1554
phone (310)-825-9550;  fax (310)-206-5658;  email: deleeuw at stat.ucla.edu
homepage: http://gifi.stat.ucla.edu
   
------------------------------------------------------------------------ 
-------------------------
           No matter where you go, there you are. --- Buckaroo Banzai
                    http://gifi.stat.ucla.edu/sounds/nomatter.au