Having it be the same under cygwin as it is for other UNIX systems would be ok but for the native Windows port R should behave like other Windows applications, not like UNIX applications.
On 8/23/07, Latchezar (Lucho) Dimitrov <[EMAIL PROTECTED]> 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. > > 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
