GCC v. LLVM

On Mar 13, 2011, at 4:37 PM, Roy Mendelssohn wrote:

Support Fink and MacPorts.

No, thanks, those cause more problems than solving anything and don't even support what we are talking about (and are entirely useless for releases). The question here is about Apple, not gcc. You can always build gcc (and in a much better way than Fink/MP) - that's not the point. This is about what Apple bundles with the system -- without compilers they are effectively not providing a unix system to the user, that's why I'm curious about the future. This is entirely a speculation, all currently released systems come with a set of compilers (even Xcode 3 has LLVM and clang).

Cheers,
Simon

-Roy
On Mar 13, 2011, at 12:58 PM, Yan Zhou wrote:

On Mar 13, 2011, at 7:44 PM, Berend Hasselman <bhh at xs4all.nl> wrote:

On 13-03-2011, at 17:27, Simon Urbanek wrote:

....
What am I missing in your statement above regarding general availability to OSX users?

Xcode 3.x is bundled with OS X and anyone can get updates through ADC. Xcode 4 is not, it is available for Mac developer program members only [or those that happen to buy it as you pointed out] and thus no longer available to all OS X users. Hence Xcode 4 is no longer suitable for projects that rely on its availability to all users. It's a really awkward situation -- the benefits in Xcode 4 are really for the developer, not the user, so it makes sense to charge the developer -- but since they don't separate compilers from the GUI it kills the unix feel of OS X for the user. I'm curious how this will shake out (and other recent decisions like dropping Java support).

Do I understand this correctly?
So the compilers are integrated completely in Xcode? 
Can the compilers be run from the Terminal in command line mode?
I rely on that.

Berend 

It can run on terminal as usual. You just need to pay for xcode4 to get it.

I think, or more as I hope, Apple will come out with a solution. R is not the only project relies on the availability of gcc, etc. Even some commercial software, for example intel compilers, relies on gcc and g++, since they don't have standard libraries and use libstdc++ instead. Another example is nvidia cuda. Though I am not familiar with things other than developer tools that rely on gcc/g++, but I am sure there are plenty of them.

Apple cannot say, "hi, you want to use third party software? That's all right, buy ours first!". That just does not make sense at all, though it's more or less kind of the style of apple, sadly.

Yan

Also, are there plans afoot to move to XCode 4.0 for OSX builds of R? 

I'm not sure what you mean exactly, but if you mean CRAN binaries then that's not an option because Xcode4 only supports OS X 10.6. As I said, Xcode4 is really pointless from the user's point of view so far, so there is no need to rush. (FWIW R and the GUI does compile with Xcode 4).

Cheers,
Simon

From what I
can tell, Apple will in the future only support Clang/LLVM. For now, I
believe they are still including the same gcc as with 3.2. But longer
term, the move seems to be to Clang/LLVM.

http://developer.apple.com/technologies/tools/whats-new.html
http://clang.llvm.org/

Does R build with Clang/LLVM? I know Clang is being developed with a
view to ensure GCC "compatibility".

As Brian pointed out, R doesn't care. The only annoying part for me as a Mac binary maintainer is that it means Apple has abandoned the only branch that supported Fortran back-end, so in the future we will not be able to provide native Fortran for Xcode. This has been known for a while and Apple's stance is that they don't care about Fortran, so in some (but not immediate) future we may be back to the mess of mixing compilers.

Note that LLVM and clang don't really have any real benefits for the R users so far. Tests suggest that they make some parts slower and we could not measure any overall benefit (unlike let's say on arm), so people were not rushing to llvm/clang so far. Apple's move to llvm/clang is really based on a political decision, not a technical one. The only benefit I see so far is what Brian mentioned as well that some people will have to realize that gcc is not the standard and can test on other compilers to find their bugs.

Cheers,
Simon

**********************
"The contents of this message do not reflect any position of the U.S. Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097

e-mail: Roy.Mendelssohn at noaa.gov (Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"