On 23/08/2007 3:33 PM, Latchezar (Lucho) Dimitrov wrote: > > >> -----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.
The issue is compatibility with other Windows programs. /path/to/file works in lots of Windows programs, and is interpreted relative to the current drive. In the common situation where the user only has one partition which is mounted as C:, it works (as long as they didn't switch to a CD or USB drive). /c/path/to/file wouldn't work anywhere but in Cygwin or similar. Duncan Murdoch > > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
