Rob, It is true I have been momentarily confused and Prof. Ripley clarified this (the reason for th confusion is that if you upgrade from Xcode 4 to Xcode 5, llvm-c++-4.2 does not get removed). Follow his directions in the post, and your user will be fine.
But taking a step back, as a package author, this is really not something you should ever worry about. It is up to the user to make sure his system is functioning (this is a quite important principle). And in this case, I think it is fair to say that it is unfortunate that Apple decided to remove this compiler from a stock Xcode 5, but it is hard for the people building the CRAN binary to predict the future. If things like this ever happens again, you can be sure that the Mac binary people will figure out a solution to this problem (like they did now). [ If llvm-c++-4.2 could not be downloaded from Apple, they might have had to release new binary ]. Using two different compilers may sometimes work by chance, but it may also sometimes give you very arcane error messages. It is certainly not guaranteed to work and should in general always be avoided. Best, Kasper On Wed, Oct 9, 2013 at 4:03 AM, Prof Brian Ripley <rip...@stats.ox.ac.uk>wrote: > This is documented in the current manuals: please read them. I posted how > to get the compilers used for the CRAN binary, on this list when Xcode 5 > was released (it is for Mountain Lion only): > > https://stat.ethz.ch/**pipermail/r-sig-mac/2013-**September/010327.html<https://stat.ethz.ch/pipermail/r-sig-mac/2013-September/010327.html> > > Otherwise see e.g. http://cran.r-project.org/doc/** > manuals/r-patched/R-admin.**html#OS-X-packages<http://cran.r-project.org/doc/manuals/r-patched/R-admin.html#OS-X-packages>. > > > > On 09/10/2013 08:07, Robert Bruggner wrote: > >> Hi Kasper, >> >> Thank you very much for your reply. >> >> Just to clarify, the situation I'm describing is one in which a user has >> downloaded XCode 5 and installed the command line tools so that they can, >> in theory, compile and install packages from source. However, the compiler >> supplied by XCode5 (Apple LLVM 5.0) is different from the one specified in >> the R 3.0.2 binary Makeconf file (llvm-g++4.2) and hence, despite having an >> installed compiler, they cannot build packages because R attempts to use >> llvm-g++4.2 (which does not exist, even with the XCode command line tools >> installed). I don't know if this is a big problem but I suspect that any >> Mac OS X user who now starts with a fresh install binary install of R and >> XCode5 command line tools will not be able to build and install C/C++ >> packages from source without first modifying the Makeconf file (or >> ~/.R/Makeconf) to point to the new compiler supplied by XCode5. >> >> What I was hoping to use configure for was to detect the compiler (Apple >> LLVM 5.0) that is now distributed with XCode5 and thus, enable users to >> compile packages from source after they'd installed the XCode command line >> tools. However, I don't think I appreciated the problems with compiling a >> package with a compiler different from that which was used to build the R >> binary - thank you for that info. Does that mean that the only good option >> is to submit the package to CRAN so it can be compiled into a binary with >> the same compiler that's used to build the Mac OS X R binary distribution? >> >> Thank you again for all your help! >> >> Cheers, >> >> -Rob >> >> >> On Oct 8, 2013, at 5:57 PM, Kasper Daniel Hansen < >> kasperdanielhan...@gmail.com> wrote: >> >> Rob, >>> >>> What you should do, is _always_ inherit the compiler which was used to >>> build R. That is the 'Right' way to go and it is what will happen per >>> default if you are using Makevars to compile you package. If you need to >>> use configure, there are hints in R-exts and we can help more specifically, >>> preferably you have a package somewhere. This way you do not run into >>> (weird) problems which can arise when you use different compilers for R and >>> your package. >>> >>> The issue you are seeing right now on the Mac is that some users will >>> not be able to compile packages from source using their system. For most >>> users, if you distribute your package via CRAN / Bioconductor they will >>> have the option of receiving a binary version of the package and therefore >>> do not need a C++ compiler. In addition, even if you want them to install >>> from source, using a configure script will (most likely) not really help at >>> all - if they don't have the Xcode supplied compiler, they are extremely >>> unlikely to have any other compiler installed on their system. And really, >>> if a user is using the CRAN binary of R and wants to install a package from >>> source, it is really their responsibility to setup their system to do so. >>> In summary, I don't think you will help anyone with a configure step trying >>> to locate an alternative compiler. >>> >>> Finally, you can get the Xcode compiler by starting up Xcode, go to >>> preferences -> Downloads and then click on "install command line tools". >>> It is irritating you have to do this, but that is the situation. >>> >>> Best, >>> Kasper >>> >>> >>> On Tue, Oct 8, 2013 at 3:00 PM, Robert Bruggner <rbrugg...@gmail.com> >>> wrote: >>> Hi all, >>> >>> I'm developing a package that needs to be compiled on installation but >>> am unsure how to ensure that the proper C++ compiler is invoked when >>> installing this package from source. Is there anyway to, at build time, >>> auto-detect and set the available compiler using configure / Makevars? >>> >>> More specifically, I'm using the CRAN-provided binary of R 3.02 running >>> on Mac OS 10.8.5 with XCode 5 installed. By default, the Makeconf included >>> with the R installation ($RHOME/Resources/Makeconf) has CXX set as: >>> >>> CXX = llvm-g++-4.2 -arch x86_64 >>> >>> However, as llvm-g++-4.2 is no longer distributed with XCode5, package >>> installation fails when I attempt to install from source with an expected >>> "llvm-g++-4.2: command not found" message. >>> >>> I see that one solution is to manually set CXX in the ~/.R/Makevars >>> file. However, I'm wondering if it's possible to have the combination of a >>> configure script / Makevars.in automatically detect and set the CXX >>> variable upon installation. >>> >>> As I have it specified currently, my configure.ac script use the >>> AC_PROG_CXX macro to detect and set CXX. >>> https://github.com/nolanlab/**Rclusterpp/blob/dev/configure.**ac<https://github.com/nolanlab/Rclusterpp/blob/dev/configure.ac> >>> >>> Then, in my Makevars.in, I attempt to specify the value of CXX detected >>> by the configure script >>> https://github.com/nolanlab/**Rclusterpp/blob/dev/src/**Makevars.in<https://github.com/nolanlab/Rclusterpp/blob/dev/src/Makevars.in> >>> >>> I can then run the configure script manually and, in the produced >>> Makevars file, it appears to detect and set CXX to the proper complier, >>> i.e.: >>> >>> CXX=g++ -arch x86_64 >>> >>> However, when I then try and install the package, it seems to default >>> back to the using llvm-g++-4.2 as the compiler and thus, installation fails. >>> >>> I of course could be approaching this in completely the wrong way. Any >>> suggestions on how I might be able to auto-detect and set the appropriate >>> compiler at build time? >>> >>> -Rob >>> >>> ______________________________**_________________ >>> R-SIG-Mac mailing list >>> R-SIG-Mac@r-project.org >>> https://stat.ethz.ch/mailman/**listinfo/r-sig-mac<https://stat.ethz.ch/mailman/listinfo/r-sig-mac> >>> >>> >> >> [[alternative HTML version deleted]] >> >> >> ______________________________**_________________ >> R-SIG-Mac mailing list >> R-SIG-Mac@r-project.org >> https://stat.ethz.ch/mailman/**listinfo/r-sig-mac<https://stat.ethz.ch/mailman/listinfo/r-sig-mac> >> >> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Professor of Applied Statistics, > http://www.stats.ox.ac.uk/~**ripley/<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-SIG-Mac mailing list > R-SIG-Mac@r-project.org > https://stat.ethz.ch/mailman/**listinfo/r-sig-mac<https://stat.ethz.ch/mailman/listinfo/r-sig-mac> > [[alternative HTML version deleted]] _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
