R-alpha: names for .RData
Fri, 22 Aug 1997 11:52:21 +0200
>>>>> 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
> 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.,
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
with all potential problems of such.)
* Similarly, there should not be any problem with having
* The first question is, what EXACTLY is `platform'? E.g., the GNU
Coding Standards would imply the triplet
whereas e.g. the Debian GNU/Linux standards tell you to use
(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/bin/R # shell script
/usr/local/lib/R/bin/R-<platform> # binaries ...
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
** 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.)
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.
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: email@example.com