[R-SIG-Mac] Clarification of R-Tcl/Tk installation wish-list

[stefano iacus]

On Jul 7, 2004, at 11:54 AM, Simon Urbanek wrote:

> On Jul 7, 2004, at 2:15 AM, James Wettenhall wrote:
>
>> If R-Tcl/Tk could be installed without the developer tools,
>
> It can always be installed w/o developer tools. If you're worried 
> about add-ons then I'd rather worry about X11 which isn't installed by 
> default ;).
>
>> Does anyone else like the idea of having an option of installing
>> Tcl/Tk binaries in $R_HOME/Tcl/ in the same way that it is done
>> on Windows?  See "R_Tcl.zip" on Duncan Murdoch's webpage:
>> http://www.murdoch-sutherland.com/Rtools/
>
> Well, it's one way to go ... I guess the problem is that there is not 
> just one Tck/Tk for OS X. The native versions come as frameworks which 
> makes sense. Supplying X11 versions as frameworks is questionable, but 
> possible. Since the X11 versions are not really Mac-native, they 
> probably shouldn't "shadow" the native way (frameworks)... I guess 
> some people think they should go to /usr/local/...
>
>> Now, as far as adminstrator privileges, it looks like I still
>> have a bit to learn about the difference between root and
>> administrator on Mac OS X.
>
> root - user with all privileges - this one is by default disabled in 
> OS X (i.e. you can't directly login as root)
> admin - an user belonging to the "admin" group which is used 
> throughout the system (e.g. you can write in Applications) also can 
> use sudo to run commands in the root context
>
>>   But my desire should be clear - to
>> be able to double-click the R installer from R.dmg and install
>> it in a custom directory (without getting an error message
>> saying that it requires administrator privileges).
>
> There's no error message :P Anyway, but "custom directory" is a 
> problem. Not from the installer point of view - you can install 
> anything anywhere, but R is not easily relocatable. The only way to 
> relocate R is to patch all binaries and modify dynamic references. It 
> can be done, but is tedious and error-prone. This is why we have the 
> fixed framework and relocatable R.app.
>
>> Maybe non-administrator installation in a custom directory is
>> more difficult on Mac OS X than on Windows, because Mac OS X is
>> based on Unix where it is natural to choose the --prefix for
>> configure BEFORE building from source (so the binaries may
>> contain absolute directory paths).  Similarly, some RPMs on
>> Linux can only be installed in one place.  Can Mac OS X be
>> more flexible, like R for Windows?
>
> It's not really a question of the operating system being more flexible 
> or not. It's the way things are linked, built and installed. IMHO the 
> building process could be slightly modified to allow relocatable R 
> framework (don't use paths in linked objects and rely on 
> LIBRARY_PATH).

the R.framework per se is relocatable, the problem is that moving the 
R.framework outside "standard" locations, i.e. where the linker and 
apps expect they to be, make every additional binary distibuted package 
to fail and even building of packages to fail.
The same applies to apps  embedding R.

I don't think that bypass the framework is a good idea as it is the way 
apple thinks about its system.

But relocation is not what I understand you are saying James. R.app is 
relocatable in the sense you can move it at any time on your system. A 
framework (any) once installed, to be moved requires  many things 
(related to the path) to be fixed.
We can certainly prepare a script to do the task, but this is not the 
way you do things on Macs

> However there are some issues with add-ons such as newly compiled 
> packages. The main problem is that we would need to kind of `bypass' 
> the framework concept and use our own concept that requires several 
> preparations before R or libR can be used (setting correct LP etc.) -  
> and that's what we wanted to prevent. Moreover you could create 
> inconsistencies when libraries are loaded from somewhere else that 
> you'd expect (which can happen on Windows).
>
> Again, a compromise would be to fix all paths on install ...
>
> But back to your issue: why would you want to insist on re-locatable 
> framework? One way of achieving what you want would be to use one of 
> the regular places like Applications or Users/Shared - at least I 
> guess that should work for your biologists and you wouldn't have to 
> think about OS X internals... Moreover if you want to deal with Tcl/Tk 
> you ran into relocation issues, too.
>


what you can reasonably do James, is to ask your system manager to 
install the tcltk stuff and the developer tools (how can you build your 
packages without?).
Packages will be built in your local directory ~/Library/R/library, 
tar.gz the binaries and distribute them. They will work.

stefano

> Simon
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-mac
>