enable 'aqua' graphics for R

[adfernandes (Andrew Fernandes)]

R needs a Fortran compiler, and hence the macports-gcc-* compilers are used by default to build it. However, none of these compilers can handle the apple-compiler specific files required by the aqua build.

The attached patches fix that, allowing the Quartz graphics device on 32-bit and 64-bit builds of R. It is a little bit of a hack so I'm not sure if it should be a default variant.

The only caveat is that I have only tested on 10.6 and, due to the way the headers work, I don't think it will work on 10.5.

This is important as the quartz graphics subsystem is 2-3 orders of magnitude faster than the x11 backend - literally. When you are plotting thousands of points, lines, and symbols, this is really important.

What the patch does is two-fold. First, it patches src/include/R_ext/QuartzDevice.h to add a definition of __INTEL_COMPILER around

#define __INTEL_COMPILER
#include <ApplicationServices/ApplicationServices.h>
#undef __INTEL_COMPILER

so that the apple-specific CF_FORMAT_FUNCTION CF_FORMAT_ARGUMENT macros in CFString.h are defined to nulls. The FSF gccs cannot handle the actual definition of these macros. It looks like gcc-4.6 will be patched to accept them, but until then... I searched all the apple SDK files, and the 10.6 CFString.h file is the only place where the __INTEL_COMPILER macro is used. Of course, this is not guaranteed for the future, but since Intel's compiler is mostly gcc-compatible, I think this is safe.

Second, the patch forces the objective-c compiler to be apple's own. It is the only one that can compile the qdCocoa.m file for the quartz device. This is the only objective-c file in the entire R distribution.

I've run a lot of plotting through this, mixing x11 and quartz devices, with many font, symbol, and drawing tests, and it all looks fine to me (10.6.4, gcc-4.5) with no hangs, problems, or crashes.

[adfernandes (Andrew Fernandes)]

Just tested it on 10.6.4 using the default gcc-4.4 variant; works fine.

[kjell.konis@…]

Maintainer here. I tried to add aqua support once before and the problem then was that, when linked against the Foundation and CoreFoundation frameworks, R crashed anytime a package used C++ for file input/output (and perhaps for other things too). Anyway, I just tried this out with the attached patch and so far have not been able to produce a crash. I'm going to continue experimenting but if it doesn't appear to cause any problems I will include the patch in the next update to the port (next couple of days - R 2.12.1 was just released yesterday).

[adfernandes (Andrew Fernandes)]

Gross; sounds like that was a c++/stdlib/dynamic-runtime-link problem, and those are horrible to diagnose if even possible.

That being said, I have a lot of c++/boost/fortran custom extension modules and they seem to work fine... maybe the problem was fixed in some FSF compiler rev or R update.

Thanks for testing, BTW - these things can be painful!

Cheers, -Andrew.

[kjell.konis@…]

It looks like grDevices.so is the only thing that ends up getting linked to any Apple frameworks. This shouldn't cause any problems with user package code so I think it's safe to include the aqua variant. The attached R2121-Port.diff updates the port to version 2.12.1 and adds the contributed aqua variant. Thanks for the patch.

[adfernandes (Andrew Fernandes)]

Excellent - thanks for all the hard work!

Cheers, -Andrew.

[adfernandes (Andrew Fernandes)]

Heh. Almost forgot - committed in r74793.