[R-SIG-Mac]Package distribution for Macintosh R
Tue, 18 Jun 2002 08:44:02 -0700
A few thoughts in response.
At 8:02 PM -0700 6/17/02, Jan de Leeuw wrote:
>That would be nice, no more binaries. In fact, I stopped building
>them, telling everybody to use fink, but it seems very few people
I switched to fink, but then when the release of v1.5.0 on fink
lagged behind its release on every other platform by several weeks, I
kind of lost enthusiasm for that approach. And, as far as I could
tell, a variety of packages from fink unstable were needed, and that
also dampened my enthusiasm.
> And using the fink version of R is less flexible,
>of course. Other problems with no-binaries:
>-- typical Macintosh users are proud to stay away from the command line
This is a consideration, but S is, after all, a _programming_
language, so putting a lot of effort into serving folks who don't
want to use a command line may be an exercise in futility.
>-- more is needed than the Apple Development tools (i.e.
> from fink we need dlcompat, X11, gnome perhaps)
I'll say. I build R from sources on Solaris, and that includes having
had to first install GCC, tcltk, png, jpeg, readlines, and libz, also
from sources. And all of them in non-standard locations. But I have
not yet succeeded in building R (Darwin) from sources on OS X,
despite help from folks on R-SIG-Mac.
>-- the Apple DevTools are changing rapidly and have various
> incompatibilities (the December 2001 tools, the April 2002
> tools, the Jaguar Tools)
>-- as a consequence the developer must choose between
> various versions of gcc and g77 or f2c
>-- does the typical user know about ATLAS ? Another choice.
There are lots of things for which the R configuration script checks
presence or absence. Could ATLAS be one of them? Isn't this an issue
in the Linuxs also?
>-- no-more-binaries implies that the typical R user has the
>DevTools installed (and maintains a personal version of
I think it's reasonable to expect R users who wish to build from
sources to have DevTools and fink installed.
>-- it seems to me that for other Unixes R and its packages are
> also distributed as binaries (for the same reason). Every Unix
> distribution must provide binaries of the recommended
>-- packages in the Carbon version are binaries because the
> typical R user does not know (and probably cannot be
> asked to know) how to build shared libraries on the OS 9
> platform. tools (MPW, CodeWarrior) are readily available.
I agree. Readily available, perhaps, but at a prohibitive financial
price, I think. In OS X, the tools are available, but the cost is
more in the users' time than his/her money.
>-- many of the packages depend on other libraries (netpbm,
> hdf5, MySQL, MPI, PVM, and so on) being present. Again, often
> fink comes to the rescue, but the user needs to maintain all this in
Again, I think it's reasonable to expect R users who wish to build
from sources to also install fink to get these. One just needs to
know which other libraries are required.
>-- building some of the OmegaHat packages is far from
> easy, and can perhaps never be made easy
>-- the Darwin/X11 distribution is already like all other
> Unix distributions, except that I provide a ridiculous
> number of binaries
And how many of these binaries required modifications either to
source code (C or fortran?) or to a makefile, that were specific to
For example, if I develop a package that includes fortran or C code,
I can only test it on platforms available to me. How, in general, do
package developers ensure that their packages work on all of the
platforms that R works on? Is OS X so different that whatever has
been working for various other unixes doesn't work for OS X?
I've had pretty good success with install.packages() in Darwin R,
though that may be because I've only tried some of the simpler
packages. And not very many either.
>-- next week I will have OS X installer packages for the
> whole thing, and users only need to know how to
> double=click, and only have to deal with a single
> installer file.
>-- with the Quartz device and the Cocoa interfaces things
> will become easier for the user, but harder for the developer
> (need to know more stuff, need to have more stuff)
I'm a little concerned at this prospect, because you and Stefano and
others currently involved who have the expertise will someday wish to
stop--who will take your place? The higher the level of expertise and
resources required, the fewer potential candidates, I would think.
>Now eventually the DevTools and OS X itself will stabilize, and
>the various configure problems will be worked out (currently,
>ATLAS does not build properly with the April tools and gcc2 with
>its g77, and R does not build with gcc3 and its g77). Then
>things will become much easier, and many more people will
>roll their own. Especially when they are happy with X11 and
>the command line. And that's good, because making your own
>provides a better understanding of the whole environment and
>allows you to optimize towards your own machine and your own
I greatly appreciate the effort and generosity involved in providing
binaries--especially in OS 9 and the early days of OS X. Even so I
would feel more comfortable knowing that I could build from sources
if necessary. So I hope this vision comes to pass.
>On Monday, Jun 17, 2002, at 18:08 America/Los_Angeles, Roger Peng wrote:
>>With the growing adoption of OS X and the soon-to-be discontinued Carbon
>>version of R, I have a question about how packages will continue to be
>>distributed for the Macintosh version of R. This question arose from some
>>discussions over developing a GUI for Macintosh R and perhaps
>>incorporating a rudimentary "package manager".
I could probably increase the usage of R around here if there were a
GUI, but it strikes me as an extremely challenging task. Unless
someone wrote a generic gui-generator function that would create on
the fly a gui interface to any other function.
>>Currently, it seems that for the Carbon version, one must rely on
>>precompiled binary versions of the packages (.sit files) due to the
>>scarcity of development tools on Mac OS < X. The situation here is similar
>>to that of the Windows platform where packages are precompiled and
>>downloaded as .zip files. While compilation of source packages on either
>>of these platforms is far from impossible, it is not entirely
>>straightforward and probably out of the realm of the average R user.
>>On the other hand, Unix users, with the exception of a few Linux
>>distributions, must essentially build R from source and install packages
>>from source. However, if the user's installation of Unix has a working
>>development environment (i.e. C, Fortran compiler, Perl, etc.), and most
>>do, then this can be very straightforward. Similarly, given a good R
>>installation, Unix users can use install.packages() and friends to
>>install, update (and compile) packages. Forcing (even casual) Unix users
>>to rely on this setup does not seem to cause a huge problem.
>>For the Darwin/X11/Quartz version of R, it seems that we are (perhaps
>>unnecessarily?) taking the Carbon/Windows approach, with Jan building
>>compiled versions of all the packages (as well as R itself). My question
>>is are we going to continue this approach to package distribution or
>>should we abandon the precompilation method and just let users build
>>packages from source? With gcc, g77, perl, latex, etc. appearing on OS X
>>it seems that we could allow the package distribution setup for OS X
>>mirror more closely that of the standard Unix platform.
>>UCLA Department of Statistics
>>R-SIG-Mac mailing list
>Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
>US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554
>phone (310)-825-9550; fax (310)-206-5658; email: firstname.lastname@example.org
> No matter where you go, there you are. --- Buckaroo Banzai
>R-SIG-Mac mailing list
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA