Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x. 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". Best, Anirban
GCC v. LLVM
14 messages · Anirban Mukherjee, Marc Schwartz, Simon Urbanek +5 more
1 day later
On Thu, 10 Mar 2011, Anirban Mukherjee wrote:
Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x. 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".
It did at one point. However, note that R is not just a C program: it has important components in Fortran. The R project simply does not have the resources to treat Apple specially: R is written in strict conformance to language standards to maximize portability at minimum cost. So whataever technology Apple (or anyone else) use for their compilers should have no impact *provided* they follow standards. The impact is more likely to come with contributed packages. Too many people write packages as if g++ were a language standard (including some much self-promoted authors), and their work is unlikely to work anywhere else.
Best, Anirban
Brian D. Ripley, ripley at stats.ox.ac.uk 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
On Mar 9, 2011, at 8:26 PM, Anirban Mukherjee wrote:
Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x.
For some definition of "released" - it's not really available to OS X users in general. For all practical purposes it's still a beta.
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
2 days later
On Mar 11, 2011, at 9:01 AM, Simon Urbanek wrote:
On Mar 9, 2011, at 8:26 PM, Anirban Mukherjee wrote:
Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x.
For some definition of "released" - it's not really available to OS X users in general. For all practical purposes it's still a beta.
Simon, Perhaps I am missing an implicit distinction being made, but XCode 4.0 is generally available to anyone on OSX, albeit there is a distinction from the prior versions. Up until now, you could sign up for a *free* Apple Developer program account and download XCode. You did not have to pay the $99 U.S. for an annual membership, which also gave you access to the various SDK's required for OSX and iOS. This is how I have been obtaining XCode for the past two years for free, since moving from Fedora. The model has now changed with 4.0, where you can either: 1. Pay the $99 U.S. annual fee and download XCode from http://developer.apple.com/xcode/ 2. Go to the App Store on OSX and pay $4.99 U.S. to obtain XCode that way from http://itunes.apple.com/us/app/xcode/id422352214?mt=12&ls=1 Clearly, the second option would be the most cost effective for general users, especially if they are not going to be building apps to make them available in the OSX or iOS App Stores. It is no longer free, but to pay $4.99 U.S. for the toolkit is arguably a steal. What am I missing in your statement above regarding general availability to OSX users? Also, are there plans afoot to move to XCode 4.0 for OSX builds of R? Thanks and regards, Marc
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
Marc,
On Mar 13, 2011, at 11:18 AM, Marc Schwartz wrote:
On Mar 11, 2011, at 9:01 AM, Simon Urbanek wrote:
On Mar 9, 2011, at 8:26 PM, Anirban Mukherjee wrote:
Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x.
For some definition of "released" - it's not really available to OS X users in general. For all practical purposes it's still a beta.
Simon, Perhaps I am missing an implicit distinction being made, but XCode 4.0 is generally available to anyone on OSX, albeit there is a distinction from the prior versions. Up until now, you could sign up for a *free* Apple Developer program account and download XCode. You did not have to pay the $99 U.S. for an annual membership, which also gave you access to the various SDK's required for OSX and iOS. This is how I have been obtaining XCode for the past two years for free, since moving from Fedora. The model has now changed with 4.0, where you can either: 1. Pay the $99 U.S. annual fee and download XCode from http://developer.apple.com/xcode/ 2. Go to the App Store on OSX and pay $4.99 U.S. to obtain XCode that way from http://itunes.apple.com/us/app/xcode/id422352214?mt=12&ls=1 Clearly, the second option would be the most cost effective for general users, especially if they are not going to be building apps to make them available in the OSX or iOS App Stores. It is no longer free, but to pay $4.99 U.S. for the toolkit is arguably a steal. 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).
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
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
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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Support Fink and MacPorts. -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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
********************** "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"
Hi Simon,
On Mar 13, 2011, at 11:27 AM, Simon Urbanek wrote:
Marc, On Mar 13, 2011, at 11:18 AM, Marc Schwartz wrote:
On Mar 11, 2011, at 9:01 AM, Simon Urbanek wrote:
On Mar 9, 2011, at 8:26 PM, Anirban Mukherjee wrote:
Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x.
For some definition of "released" - it's not really available to OS X users in general. For all practical purposes it's still a beta.
Simon, Perhaps I am missing an implicit distinction being made, but XCode 4.0 is generally available to anyone on OSX, albeit there is a distinction from the prior versions. Up until now, you could sign up for a *free* Apple Developer program account and download XCode. You did not have to pay the $99 U.S. for an annual membership, which also gave you access to the various SDK's required for OSX and iOS. This is how I have been obtaining XCode for the past two years for free, since moving from Fedora. The model has now changed with 4.0, where you can either: 1. Pay the $99 U.S. annual fee and download XCode from http://developer.apple.com/xcode/ 2. Go to the App Store on OSX and pay $4.99 U.S. to obtain XCode that way from http://itunes.apple.com/us/app/xcode/id422352214?mt=12&ls=1 Clearly, the second option would be the most cost effective for general users, especially if they are not going to be building apps to make them available in the OSX or iOS App Stores. It is no longer free, but to pay $4.99 U.S. for the toolkit is arguably a steal. 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).
I think that the key issue is that XCode 4 is 10.6 only in so far as installation, which in turn means Intel based Macs only (and of course target builds for the mobile A4/5 CPUs). For some reason, I thought that I had seen that it would still be able to generate universal binaries, but upon further checking, that does not appear to be the case. Thus, as long as one needs to build for older OSX versions and for PPC platforms, it will not be suitable. It seems clear that Apple has made a strategic decision regarding future platform support. Presumably in time, that becomes a non-issue, as with any transition in OS and HW support. The other decisions, such as Java and Flash are interesting and will of course, play out in time. The dynamics between Apple and Adobe/Oracle make for interesting and sometimes, conspiratorial dialog.
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).
No rush and I don't have it yet. I was more trying to get a sense of direction for CRAN. However, as I note above, I was under the mistaken impression that XCode 4 could create universal binaries. Thus, as long as you need to be able to build them for end useRs on multiple OSX versions and CPUs, moving to it does not make sense. FORTRAN support is of course, yet another reason. Thanks Simon, Marc
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
'Universal' is a moveable feast. For Tiger, it seemed to be 4 archs (i386, x86_64, ppc, ppc64), We now have 3, and at some point soonish there will be 2 (no ppc) once Leopard support goes. I've not seen a (powered up) PowerPC machine for at least a year, but quite a few 10.5 systems (indeed, I have one, mainly to continue to be able to build/test software I might distribute). My guess is that 10.7 this summer will ship with Xcode 4 (Xcode is a collection of tools, not just an IDE). At that point we may need to decide exactly what Mac platforms we will support with binary builds. Already it is moot if we need i386 builds: hardware that does not run x86_64 is now several years old (and is probably running Tiger).
On Sun, 13 Mar 2011, Marc Schwartz wrote:
Hi Simon, On Mar 13, 2011, at 11:27 AM, Simon Urbanek wrote:
Marc, On Mar 13, 2011, at 11:18 AM, Marc Schwartz wrote:
On Mar 11, 2011, at 9:01 AM, Simon Urbanek wrote:
On Mar 9, 2011, at 8:26 PM, Anirban Mukherjee wrote:
Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x.
For some definition of "released" - it's not really available to OS X users in general. For all practical purposes it's still a beta.
Simon, Perhaps I am missing an implicit distinction being made, but XCode 4.0 is generally available to anyone on OSX, albeit there is a distinction from the prior versions. Up until now, you could sign up for a *free* Apple Developer program account and download XCode. You did not have to pay the $99 U.S. for an annual membership, which also gave you access to the various SDK's required for OSX and iOS. This is how I have been obtaining XCode for the past two years for free, since moving from Fedora. The model has now changed with 4.0, where you can either: 1. Pay the $99 U.S. annual fee and download XCode from http://developer.apple.com/xcode/ 2. Go to the App Store on OSX and pay $4.99 U.S. to obtain XCode that way from http://itunes.apple.com/us/app/xcode/id422352214?mt=12&ls=1 Clearly, the second option would be the most cost effective for general users, especially if they are not going to be building apps to make them available in the OSX or iOS App Stores. It is no longer free, but to pay $4.99 U.S. for the toolkit is arguably a steal. 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).
I think that the key issue is that XCode 4 is 10.6 only in so far as installation, which in turn means Intel based Macs only (and of course target builds for the mobile A4/5 CPUs). For some reason, I thought that I had seen that it would still be able to generate universal binaries, but upon further checking, that does not appear to be the case. Thus, as long as one needs to build for older OSX versions and for PPC platforms, it will not be suitable. It seems clear that Apple has made a strategic decision regarding future platform support. Presumably in time, that becomes a non-issue, as with any transition in OS and HW support. The other decisions, such as Java and Flash are interesting and will of course, play out in time. The dynamics between Apple and Adobe/Oracle make for interesting and sometimes, conspiratorial dialog.
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).
No rush and I don't have it yet. I was more trying to get a sense of direction for CRAN. However, as I note above, I was under the mistaken impression that XCode 4 could create universal binaries. Thus, as long as you need to be able to build them for end useRs on multiple OSX versions and CPUs, moving to it does not make sense. FORTRAN support is of course, yet another reason. Thanks Simon, Marc
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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Brian D. Ripley, ripley at stats.ox.ac.uk 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
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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
********************** "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"
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Hi all, AFAIK: my best guess is that the $5 price tag is due to the accounting regulations. Non-subscription sales recognize revenue at time of sale. Future upgrades then need to be "sold". I am guessing with Lion, we will see Xcode 4. I see two main concerns: a. As Simon brought up, Fortran support is missing from LLVM. Long term that is a problem. b. gcc 4.2 is getting old, and at some point of time, R and/or "packages" such as Rcpp, will require an updated compiler. I think its anyone's guess as to when that will happen. (I don't want to lump the base distribution of R with the packages, but generally its nice that there is one recognized toolchain across R and all its packages that everyone uses for everything. It would be nice to be able to retain that.) Guess we will have to wait and see how things evolve. Doesn't sound like anyone wants/needs to preempt a move from gcc. But, at least I suspect, its inevitable. Best, Anirban -- Anirban Mukherjee | Assistant Professor, Marketing LKCSB, Singapore Management University 5056 School of Business, 50 Stamford Road Singapore 178899 | +65-6828-1932
On Mar 14, 2011, at 6:47 AM, Simon Urbanek wrote:
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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
********************** "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"
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
4 days later
Anirban Mukherjee <anirban.mukherjee <at> gmail.com> writes:
Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x. 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". Best, Anirban
Just saw the following post on Mac OS X hints entitled: Restoring PPC, SDK 10.4/10.5 and GCC 4.0 Support to Xcode4 http://hints.macworld.com/article.php?story=20110318050811544 According to the author, this already appeared on Stack Overflow so perhaps many have already seen it. Is it a method to be recommended?
Ken Knoblauch Inserm U846 Stem-cell and Brain Research Institute Department of Integrative Neurosciences 18 avenue du Doyen L?pine 69500 Bron France tel: +33 (0)4 72 91 34 77 fax: +33 (0)4 72 91 34 61 portable: +33 (0)6 84 10 64 10 http://www.sbri.fr/members/kenneth-knoblauch.html
On Mar 18, 2011, at 1:22 PM, Ken Knoblauch wrote:
Anirban Mukherjee <anirban.mukherjee <at> gmail.com> writes:
Folks, I was wondering what the forward plans are for R on Mac vis-a-vis apple-gcc/Clang. Xcode 4 was just released with LLVM 2.x. 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". Best, Anirban
Just saw the following post on Mac OS X hints entitled: Restoring PPC, SDK 10.4/10.5 and GCC 4.0 Support to Xcode4 http://hints.macworld.com/article.php?story=20110318050811544 According to the author, this already appeared on Stack Overflow so perhaps many have already seen it. Is it a method to be recommended?
You can always use older SDKs, that has been true for both Mac OS X and iOS - I don't have an issue with that (it's especially useful in the iOS world ;)). However, hacking Xcode4 to accept the old compilers sounds little radical to me (we don't use gcc4.0 and don't plan to support 10.4 anyway so it is not needed for R). It's definitely not something I would recommend for the casual user. But then, a casual used has no need for it, so it all sounds very hypothetical to me ;). Cheers, Simon