Frank>As I will be maintaining the libraries for S-Plus (both
>Windows and Linux/Unix versions, S version 3 and 4
>languages) and for R, I would appreciate learning how
>other users who do the same set up their directories
>to facilitate distributing libraries for both R and
>S-Plus in a way that is also consistent with CVS. In
>other words, I would like to be able to construct
>distributions suitable for CRAN without making it too
>hard to run Unix/Linux shell scripts that also create
>S-Plus distributions.
I have have just completed a multi-year transition from developing my
code in Splus and wanting it to run also in R, to developing in R and
wanting it to run also in Splus. (I still only use Splus 3.3.) The code
was never a big issue for me as I have been careful to avoid anything
depending on fundamental differences between R and S.
Although I have been using R for many years (mainly to avoid debugging
For loops) the real start of my transition was the remarkable support
for help documentation starting sometime just before R 1.0. The final
act was to move all my test programs from my own ad hoc system to R's
tests directories, so that the tests are run by R CMD check. With a few
scripts and a Makefile I now mimic R's approach to run my tests in Splus
and to generate html help for S. I would be happy to send these if you
are interested. I maintain about 1000 functions in a dozen packages
organized into three bundles (one of which I do not distribute).
There is no problem using CVS, but I use it only for co-ordinating my
home version with my work version, so there may be complications I am
not aware of. I don't use Windows and there are undoubtedly
complications, although I think I now have my packages in a state where
there are no serious problems.
Here are a few points you may want to consider.
1/ Up until very recently I tried to mimic a few S functions in R. I
have just converted to mimicking the R conventions in S and I find it
works much better. To do this I have S functions for a few things like
is.R(), Platform(), Sys.info(). This works better, in part because the
cross platform issues are very well thought out in R. (But to be fair,
in S I only try to make it work in Unix and I have not been changing
versions.) I will distribute these functions, but it would make sense to
have a common effort if others are interested.
2/ In the few cases where I need a slightly different definition of
something for S, I keep the functions in an S subdirectory in the R
package structure. I source these first when I build the S version, and
then I use is.R() to avoid redefining them when I source code from the R
subdirectory.
3/ If there is a logical way to divide things up into multiple packages
(and perhaps put them together into a bundle) then it is a good idea. It
is much quicker to build and test changes this way. (At least once you
get the dependencies worked out.)
4/ I keep fortran code in the R package src directory and my Splus
install script compiles it there. For R/S code I essentially build an R
like package for Splus and then have an install script that sources
things from the S and R subdirectories to generate .Data.
Best of luck with your effort, and let me know if you would like my
Makefile or any of my scripts or other code.
Paul Gilbert
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._