> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Prof Brian Ripley > Sent: Thursday, August 23, 2007 2:54 AM > To: Denham Robert > Cc: r-devel@r-project.org; Duncan Murdoch > Subject: Re: [Rd] compiling R under cygwin > > 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.
I'm not sure what you mean by "produce" above but one can easily setup (by mount option) cygwin to use "/" instead of "/cygdrive/" so that your example above will become "/c/path/to/file". That's if you insist on using drive letters. Otherwise w/ proper mounting (in cygwin) one can have "usual" *nix dir tree. Regards, Latchezar PS. I really like the idea of having (the same) bare terminal/command window interface to R anywhere as well as anything else (like admin tasks above) to be the same. So please put my vote (if you care) to have R Windows installation look the same as *nix (up to the point when you start R from Start button to have terminal version started instead of Rgui as it is now) and keep GUI candies separately for whoever wants/needs them. Sorry if that's been already done and I did not know about it. > > 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 > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
