Hi Kjell, I'm sorry to task this to you instead of trying myself but I've a busy week :( one more tests: * are you able to build packages from sources with your setup? My concerning about moving the framework is really about application embedding. If build an application against -framework R, how can the linker find the R.framework unless you add this to the (frameworks?) path? Because, from Apple's notes it only searches in /Library/Frameworks, /System/Library/Frameworks and in your local home. Suppose you add it to the path, if then you move the R.app application around, what will be of the application needing the R framework to run? there is also a problem with the path of R framework be hard coded inside the libR.dylib, how did you manage this ? thanks for any suggestion you can give me. stefano
On May 11, 2004, at 2:00 PM, Kjell Konis wrote:
On 10 May 2004, at 13:37, stefano iacus wrote:
1) Why not put R.framework in R.app/Contents/Frameworks? I tried this and everything seems to work fine. Here is the modification to R.app/Contents/MacOS/R to get it to work:
did you try to use prebuilt binary packages from CRAN ? I wonder if they can work at all, if so, please let me know.
Packages can be installed from the 'Get CRAN Packages' item in the Packages menu. They are installed in ~/Library/R/library and can be loaded using the library function or the package manager.
R.app can be moved anywhere on the system, and if you change the location of the R.app with the R.framework inside, then you have to use install_tool or similar to hard code the path of the libR.dylib, and you need a script for this. Also, any R contributed package need to know where to find the R.framework and moving the framework around the system, causes troubles (again unless using a script every time you move R.app with the R.framework inside)
The R start up script in Contents/MacOS sets the environment variable R_HOME when R is launched (and my modified script sets this properly when R.framework is in the R.app bundle). As far as I can tell this is sufficient for R contributed packages. The only bad thing one can do is move the R.app bundle while R is running. If you can recommend some packages with complicated dependencies I would be happy to test them using my setup. What are the advantages of putting R.framework in /Library/Frameworks? It seems to me that this creates two really big disadvantages. 1) If more than one application uses the R.framework you have the possibility of version mismatch. On Windows (a platform I hope to never develop for again) this is called "dll hell". 2) Users without administrator privileges (for instance students in a computer lab) will not be able to install/use R if it is not already on the system.
So, for fink installer (for example), it suffices to put the right dependency. [this is for point 3)]
The reason we need ${prefix} to be used is that the packaging utility
sets prefix to something like /packageRoot/really/weird/path/package.
Then, after the make install phase of the build, it does a recursive
ls on /packageRoot/really/weird/path/package to see what files were
created there. This information is saved in a database that is used
for uninstalling and updating. The last step is to copy all of the
files to the actual install location.
Regards,
Kjell