[R-SIG-Mac] Some suggestions for R.app

[stefano iacus]

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
>
>