----- Original Message ----- > From: "Duncan Murdoch" <murdoch.dun...@gmail.com> > Cc: r-devel@r-project.org > Sent: Thursday, March 12, 2015 10:17:23 AM > Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not > multilib) > > I've just uploaded a minor update (3.3.0.1957) to Rtools33, adding > the > cygpath.exe utility. That utility converts between Windows style > paths > like D:/Rtools and Cygwin style paths like /cygdrive/d/Rtools. It > may > be useful in configuration files if your external library expects to > find gcc on the path, since Rtools no longer puts it there. Assuming > you want to use the Rtools toolchain, you can construct the path to > the > gcc directory in your Makevars.win file as > > $(cygpath $(RTOOLS))gcc492_$(WIN)/bin > > (where RTOOLS and WIN are macros from RHOME/etc/*/Makeconf that > should > already have been read.) >
I had some problems with this. In the Bioconductor package zlibbioc, for example (which wraps zlib) there is a lower-level "Makefile.gcc" inside src/zlib-1.2.5/win32 which contains: PREFIX = ifeq "$(WIN)" "64" CC = $(PREFIX)gcc -m64 else CC = $(PREFIX)gcc -m32 endif First of all, even though I have cygpath installed, using it as you suggest does not work, and does not seem to be necessary. Secondly, although $(WIN) is visible to the ifeq statement, it can't be expanded, that is to say, changing PREFIX to PREFIX = "$(RTOOLS)gcc492_$(WIN)/bin/" doesn't work, and the error shows that gcc is being looked for in a path that ends with gcc492_/bin/ , in other words, the $(WIN) does not expand. However, changing to this: ifeq "$(WIN)" "64" PREFIX = "$(RTOOLS)gcc492_64/bin/" CC = $(PREFIX)gcc -m64 else PREFIX = "$(RTOOLS)gcc492_32/bin/" CC = $(PREFIX)gcc -m32 endif Works just fine. It's odd that the value of $(WIN) can be "seen" in order to correctly execute the "ifeq", but it can't be expanded. There are a number of fairly important packages in Bioconductor (and in CRAN too I imagine) that wrap C/C++ libraries and they all probably need some tweaking like this. I'm a little concerned that it's not such good practice to change third party code in this way, it makes maintenance just a little harder. It would be nice if maintainers could just add the latest version of the library to their packages without changing anything. But if making these changes is the only option, then so be it. Dan > Thanks to JJ Allaire for the prompting on this. > > Duncan Murdoch > > ______________________________________________ > 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
