R-alpha: names for .RData

[Kurt Hornik]

>>>>> Thomas Lumley writes:

> It would be nice for the save file name .RData to be a variable in
> config.site (unless the machine-independent files are coming very
> soon).  We are currently running R on a cluster with both
> sparc-solaris and intel-linux machines, which don't like each other's
> .RData files.  At the moment I edit the source files by hand to change
> the name to .RData-linux.

I thought by switching to the new format (XDR?) this would no longer be
a problem?

> On a related topic, has anyone given any more thought to installing
> multiple binaries in the same directory tree (as suggested some time ago
> by Greg Warnes)?  This could save quite a lot of space as well as making
> it easier to keep different operating systems synchronised. 

There was some discussion a time ago.  Let me try to summarize it in my
own biased way.

* In general, we have two ways of arranging the `library' tree.  One is,
grouped according to module, the other, according to type.  I.e.,

	library/<module>/
	library/<module>/funs/
	library/<module>/help/
	library/<module>/html/
	library/<module>/rman/
	library/<module>/objs/<platform>

etc or

	library/funs/<module>
	...
	library/objs/<platform>/<module>

Given that we also have architecture-dependent things in the library, I
would suggest to adopt the former strategy (similar to Emacs) and not
the latter as e.g. in the TeX Directory Standard.

* (As an aside, we could also discuss whether we want to have several
versions of R installed simultaneously.  This would imply having

	RHOME/<version_1>/...
	RHOME/<version_2>/...
	...
	RHOME/<site>

with all potential problems of such.)

* Similarly, there should not be any problem with having

	RHOME/bin/R-<platform>

instead of

	RHOME/bin/R.binary

* The first question is, what EXACTLY is `platform'?  E.g., the GNU
Coding Standards would imply the triplet

	MACHINE-VENDOR-OS

whereas e.g. the Debian GNU/Linux standards tell you to use

	MACHINE-OS

(e.g., `i386-linux') ...

* The main question is, how is the right platform determined at runtime?
I've had some discussions here (forgot who with) where I claimed that
this is not possible from the shell alone.  E.g., on my current system
the output of `uname -a' is

	Linux teddy 2.0.27 #2 Sun Dec 22 22:12:46 MET 1996 i586 unknown

and if someone had compiled R on an i386 I'd be nowhere.  The same
applies for shell variables such as OSTYPE and MACHTYPE, which don't
seem to be POSIX anyway.

* Hence, I think the right things to do are

** Either have several scripts in RHOME/bin, and have links to these
from somewhere in PATH (which sounds a bit stupid)

** Have a simple shell wrapper installed in the PATH which calls the
real one passing the PLATFORM information.  If this sounds confusing,
the idea is the following.  Suppose we install in /usr/local (and that
/usr/local/bin is not shared among platforms).  Then RHOME would be

	/usr/local/lib/R

with

	/usr/local/lib/R/bin/R			# shell script
	/usr/local/lib/R/bin/R-<platform>	# binaries ...

and

	/usr/local/bin/R

would contain

	exec /usr/local/lib/R/bin/R -p PLATFORM $*

and `PLATFORM' is what was determined at compile time.

* I think this is the cleanest solution, and should not be too hard to
implement:

STEP 1.

** Introduce the -p argument (or whatever else) to the script.  Maybe do
something nice such as providing a `default' platform in the script,
such that those with a single-platform setup don't see any difference.

** Rename `R.binary' accordingly.

** Introduce a platform layer in `lib' (and perhaps rename it to `objs'
right away, PLEASE).

** Modify library.dynam() accordingly. (Not a problem, as we have the
`arch' and `os' elements of version() anyway.)

STEP 2.

The above does not create a platform wrapper (where should it put it?),
but single-platform sites won't know a difference (shell script has a
default), and multi-platform people can either have private aliases or
set up wrappers at the sysadmin level.

Eventually, there should be something like a real `make install' with
the installation tree different from the source/build tree.  Then, we
can generate a wrapper at compile time and install it to $(bindir) (the
runtime system will go into $(libdir), and the man page into $(mandir)).

****

That's all, folks.

-k

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-