On Thu, 23 Aug 2007, Denham Robert wrote: >>> For various reasons, >> I think it is only courteous to mention some good reasons if you want > to take up people's time. > > Some of the reasons we would like a cygwin version aren't necessarily > good reasons. We have been using cygwin for sometime, mostly to deal > with scripting in a combined windows/unix environment. We have a setup > which allows windows users to run many scripts in the same way as unix > users. These scripts are often python or shell scripts. We have R > installed on the unix machines, and the system administrators would like > to be able to have R on windows in the same environment. This set up > also means that the administrator can fairly easily maintain the version > of software used on all user's machines. Probably this could all be > managed and still use the native windows version of R, but the > administrator is familiar with cygwin and they could manage this > software in the same way they manage other packages.
Yes, it could almost certainly be done with Rterm.exe. The issue I came across was the so-called 'posix file paths' that Cygwin uses. Most (but not all) Windows programs accept file paths with / as the path separator, and most (but not all, e.g. tar) Cygwin programs accept paths of the forn c:/path/to/file. So provided you use that as your format, interworking with Unix and Unix-like shells work fine. It used to be the case that if you had just one drive C: then Cygwin programs produced paths of the form /path/to/file that also worked on Windows. Now they produce /cygdrive/c/path/to/file that works nowhere else. In general this is a minor nuisance, but I needed to be able to cross-build R in an environment where I only have Cygwin-based cross-compilers, and there the path issues bit me: I needed a version of R that accepted and returned Cygwin-style paths. So I made the configure changes necessary to build R under Cygwin, and had it running in 20 mins. > We would like to be able to use linux machines on pc's but unfortunately > we have restrictions imposed on us that prevent this. This restriction > also goes as far as the use of virtual machines. My personal preference > would be to run linux on my work pc, and use a virtual machine to run > windows software, such as ArcGIS and Imagine, that are not available for > linux. This does not seem to be an option for us. > > One thing I was interested in was knowing if there are others who also > would like a cygwin version. From the replies to my post, and from a > search of the mailing list archive, I think that there is little demand > for this. We would, however, be prepared to help in some way for the > few people who are interested. As I said earlier, it builds out of the box in R-devel (with suitable options documented in the R-admin manual). No guarantees that it will continue to do so unless tested in the alpha/beta phase though. As no other platform we use nowadays requires that shared objects/dynamic libraries have all imports satisfied at build time, this is liable to get broken. But I would encourage people to use Rterm.exe if it can be made to do what you need. > > > > Robert Denham > Environmental Statistician > Remote Sensing Centre > Telephone 07 3896 9899 > www.nrw.qld.gov.au > > Department of Natural Resources & Water > QScape Building, 80 Meiers Road, Indooroopilly Qld 4068 > > -----Original Message----- > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 21 August 2007 9:53 PM > To: Duncan Murdoch > Cc: Denham Robert; r-devel@r-project.org > Subject: Re: [Rd] compiling R under cygwin > > Yes, > >> What is the advantage of building this? > > was my question too. If you want a Unix-like version of R on PC > hardware running Windows why not run a Unix-like OS under a virtual > machine? > > Quite a lot of the details are wrong: using FLIBS, BLAS_LIBS and LIBS as > intended will solve most of the problems. I would use --disable-nls > --disable-mbcs as you don't need them (and in particular you don't > benefit from MBCS support on Windows unless you are in a CJK locale). > > Note that 2.5.1 is released and there is unlikely to be a 2.5.2, so any > changes would be made only to R-devel. It there is a convincing case to > tailor a build for Cygwin there we can probably do so rather easily, but > the need for ongoing support would be a worry. > > (If platforms are not used and in particular not tested in the > alpha/beta testing phases then the ability to build on them crumbles > away. We seems to be down to regular testers on Linux, Windows, MacOS > X, Solaris and FreeBSD, with some help on AIX after a patch with none.) > > On Tue, 21 Aug 2007, Duncan Murdoch wrote: > >> Denham Robert wrote: >>> For various reasons, > > I think it is only courteous to mention some good reasons if you want to > take up people's time. > >>> it suits our workplace to have a cygwin version of R. I am pretty >>> sure that cygwin is still not a supported environment for R, but we >>> have managed to compile R-2.5.1 under cygwin without too many dramas. > >>> Our procedure is described below. We still have a few problems >>> compiling libraries without manually changing files from .so to .dll, > >>> but it seems ok. >>> >> I would expect other subtle problems as well, because Cygwin is not a >> normal Unix. I don't know whether any of these differences matter to >> R, but some things to look out for are: >> >> - you can't unlink a file while it is open >> - filenames are not case sensitive >> - file permissions have strange defaults (everything is executable) >> - I think the executable format still needs to be Windows format >> - There's no such thing as a ptty >> - You'll probably need X11 for graphics, and will lose support for >> Windows metafile output (wmf) >>> >>> I was wondering whether this information is likely to be useful to >>> others, and if we should spend any time looking in to ways in which >>> the configure/build/install code could be modified to allow a >>> standard install. >>> >> What is the advantage of building this? I don't think we want to >> support platforms just for the sake of supporting more platforms, but >> if there's a real need for it, that would be different. >> >> Duncan Murdoch >>> >>> Notes on building R under cygwin: >>> >>> export FFLAGS=-O3 >>> export CFLAGS=-O3 >>> export CXXFLAGS=-O3 >>> export OBJCFLAGS=-O3 >>> export FCFLAGS=-O3 >>> export LDFLAGS='-lblas -lg2c -lintl' >>> >>> export R_OSTYPE=unix >>> >>> ./configure --prefix=/opt/freeware/R/R-2.5.1 \ >>> --with-tcl-config=/usr/lib/tclConfig.sh \ >>> --with-tk-config=/usr/lib/tkConfig.sh \ --with-blas=-lblas \ >>> --with-lapack=-llapack \ --enable-R-shlib >>> >>> comment out Win32 in src/include/config.h and set Unix to 1, change >>> .so to .dll. change .so to .dll and in Makeconf. >>> in src/extra/xdr/rpc/types.h comment out defn of malloc. >>> >>> Change .so to .dll in Makefile's >>> >>> edit Makeconf and set R_OSTYPE to unix >>> >>> make -j2 >>> >>> when blas doesn't link, re-run command with -lblas -lg2c on end and >>> change output to .dll >>> >>> edit Rstrptime.c and change wcstod to atof. >>> >>> in modules: >>> when X11 and internet falls over add -lintl to link line. add -lg2c >>> and -lblas to lapack >>> >>> comment out library/base/R/library.R lines 47-51 to avoid arch check >>> which seems to go wrong! >>> >>> make -j2 >>> make install >>> >>> edit /opt/freeware/R/R-2.5.1/lib/R/etc/Makeconf and add '-lintl >>> -lg2c -lblas' to the end of ALL_LIBS so the module building works. >>> Change .so to .dll also (can't see how to to this for the build >>> tho...) >>> >>> >>> Our cygwin info is: >>> sysname release version >>> "CYGWIN_NT-5.1" "1.5.20s(0.155/4/2)" "20060527 19:21:22" >>> >>> >>> >>> >>> Robert Denham >>> Environmental Statistician >>> Remote Sensing Centre >>> Telephone 07 3896 9899 >>> www.nrw.qld.gov.au <http://www.nrw.qld.gov.au/> >>> >>> Department of Natural Resources & Water QScape Building, 80 Meiers >>> Road, Indooroopilly Qld 4068 >>> >>> ********************************************************************* >>> *** The information in this email together with any attachments is >>> intended only for the person or entity to which it is addressed and >>> may contain confidential and/or privileged material. >>> Any form of review, disclosure, modification, distribution and/or >>> publication of this email message is prohibited, unless as a >>> necessary part of Departmental business. >>> If you have received this message in error, you are asked to inform >>> the sender as quickly as possible and delete this message and any >>> copies of this message from your computer and/or your computer system > >>> network. >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
