Poll: What compiler do you use for iOS development?
10 comments
Clang is the future. GCC is obsolete, and LLVM-GCC was just a temporary technology to help migrate from GCC to Clang. All new projects should absolutely be using Clang now, and any old projects that haven't already switched should seriously consider doing so.
Unfortunately, clang (and the shared llvm backend) are still fairly buggy. For example: http://blog.clickablebliss.com/2011/11/07/xcode-4-2-llvm-bui...
There's a bug in Xcode 4.2 (the latest stable release) that results in broken armv6 thumb FPU-related codegen. It's not hard to hit, either.
Since everything is based on LLVM now (including gcc-llvm), there's no way around this one (or other bugs) other than simply disabling thumb.
I'd personally rather stick to gcc4 for at least the next few clang/llvm release cycles, since the bugs are known. Unfortunately, straight GCC is no longer supported in Xcode.
There's a bug in Xcode 4.2 (the latest stable release) that results in broken armv6 thumb FPU-related codegen. It's not hard to hit, either.
Since everything is based on LLVM now (including gcc-llvm), there's no way around this one (or other bugs) other than simply disabling thumb.
I'd personally rather stick to gcc4 for at least the next few clang/llvm release cycles, since the bugs are known. Unfortunately, straight GCC is no longer supported in Xcode.
Is switching as simple as changing the project config to use the new compiler, or is code migration/change needed?
Depends on your code. For well-written code that conforms to standards, switching the compiler may be completely pain-free. For most code, you'll probably get a few warnings (since Clang's default warning set is different than GCC's). In rare occasions you'll hit an actual behavioral difference between GCC and Clang, but you'll typically only find those where you're already writing non-standards-compliant code.
Also, if you do get some warnings when you switch to Clang, I would recommend fixing them rather than trying to squelch the warnings. Clang's warning set is pretty well-thought-out and things it flags as warnings are typically indicative of bad code (or coding practices).
Also, if you do get some warnings when you switch to Clang, I would recommend fixing them rather than trying to squelch the warnings. Clang's warning set is pretty well-thought-out and things it flags as warnings are typically indicative of bad code (or coding practices).
You'll probably get some minor warnings here and there due the differences in the Parser. But in my experience, it's been relatively painless.
Have you tried building Boost for iOS?
For iOS? No. But I thought that as of this year, Clang's C++ support was good enough for Boost. Am I missing something?
why?
Why what?
Why is GCC obsolete for iOS/OS X dev? Because Apple will not be updating it in the future to track changes in the Objective-C language, runtime, and iOS and OS X platforms.
Why won't Apple be updating it? Because they've indicated that they are not comfortable with contributing to projects based on the GPL, version 3, and they do not wish to be stuck forever on the last version of GCC released prior to that licensing change.
Why is Clang the future? Because Apple has anointed it as compiler which will be receiving future updates to track changes in the Objective-C language, runtime, and iOS and OS X platforms.
Why should any old projects that haven't already switched seriously consider doing so? Because the divergence between GCC and Clang is only going to increase with time, and code which doesn't make that transition now will face a much costlier transition down the road as new features become Clang-only and as it becomes increasingly impossible to run the old versions of Xcode which use GCC and for said old versions of GCC to build binaries which run on future versions of iOS and OS X.
Why is GCC obsolete for iOS/OS X dev? Because Apple will not be updating it in the future to track changes in the Objective-C language, runtime, and iOS and OS X platforms.
Why won't Apple be updating it? Because they've indicated that they are not comfortable with contributing to projects based on the GPL, version 3, and they do not wish to be stuck forever on the last version of GCC released prior to that licensing change.
Why is Clang the future? Because Apple has anointed it as compiler which will be receiving future updates to track changes in the Objective-C language, runtime, and iOS and OS X platforms.
Why should any old projects that haven't already switched seriously consider doing so? Because the divergence between GCC and Clang is only going to increase with time, and code which doesn't make that transition now will face a much costlier transition down the road as new features become Clang-only and as it becomes increasingly impossible to run the old versions of Xcode which use GCC and for said old versions of GCC to build binaries which run on future versions of iOS and OS X.
Apple does not want to support two sets of tools forever, it would not be cost effective.
GCC is obsolete on Apple's platforms because Apple has chosen LLVM as the future basis of their tools. The reasoning was mostly technical, LLVM project also seems more nimble and aligned better with Apple's goals. Surely saner license did not hurt.
LLVM has technical benefits compared to GCC, biggest being modularity, speed and memory usage come second. Modularity helps Apple make Xcode a better IDE. You can already see stuff in Xcode that would have been very hard to make with less modular toolset, as GCC. I expect it to pick up after the transition period is over.
As an example they are using clang to parse the code for syntax highliting and code completion instead of a custom parser they used before. To use one codebase for parsing both in the IDE and compiler has inherent virtues.
LLVM is also used by Apple in other products in addition to of Xcode. OpenGL runtime and OpenCL tools come to mind, efforts in LLVM project have good return on investment.
Everyone, old or new projects should consider switching to clang, for speed and static analysis. Whether to use new objc features that require clang, is another question, in most cases it makes sense.
GCC is obsolete on Apple's platforms because Apple has chosen LLVM as the future basis of their tools. The reasoning was mostly technical, LLVM project also seems more nimble and aligned better with Apple's goals. Surely saner license did not hurt.
LLVM has technical benefits compared to GCC, biggest being modularity, speed and memory usage come second. Modularity helps Apple make Xcode a better IDE. You can already see stuff in Xcode that would have been very hard to make with less modular toolset, as GCC. I expect it to pick up after the transition period is over.
As an example they are using clang to parse the code for syntax highliting and code completion instead of a custom parser they used before. To use one codebase for parsing both in the IDE and compiler has inherent virtues.
LLVM is also used by Apple in other products in addition to of Xcode. OpenGL runtime and OpenCL tools come to mind, efforts in LLVM project have good return on investment.
Everyone, old or new projects should consider switching to clang, for speed and static analysis. Whether to use new objc features that require clang, is another question, in most cases it makes sense.
Ok, so it just needs to be done eventually, and there's no benefit per se to using Clang over GCC?
I ask because I'm an iOS dev and I don't know anything about this issue.
Why would the transition be much costlier later? More imperative I understand, but why more costly?
I ask because I'm an iOS dev and I don't know anything about this issue.
Why would the transition be much costlier later? More imperative I understand, but why more costly?
If you transition now, the incompatiblities for most apps are small to nonexistent.
If, say, you transition 3 years from now when GCC can't build a working binary for a new iOS ABI version that the App Store rules require all new submissions support, and the syntax clang supports has diverged from what GCC was accepting, that's more time needed and dollars lost for every minute the porting takes you.
But that's just a guess at the future. Clang/LLVM provides significant benefits today. Better error messages, better warnings, a seriously great static analyzer (given the constraints imposed by C's semantics), and Automated Reference Counting are just a few of them.
If, say, you transition 3 years from now when GCC can't build a working binary for a new iOS ABI version that the App Store rules require all new submissions support, and the syntax clang supports has diverged from what GCC was accepting, that's more time needed and dollars lost for every minute the porting takes you.
But that's just a guess at the future. Clang/LLVM provides significant benefits today. Better error messages, better warnings, a seriously great static analyzer (given the constraints imposed by C's semantics), and Automated Reference Counting are just a few of them.
One would hope Clang isn't going to drop support for syntax that it supports today, because that would be a backwards-compatibility issue. However, I do agree that switching earlier rather than later is better. At the very least, the longer you put off the switch, the more code you'll have written that may need to be adjusted to work properly under Clang.
MonoTouch
No downvotes because Miguel... we love you (and Mono et al. are really good pieces of technology)
[deleted]
Just out of curiosity, anyone know of a good CLI xcodebuild cheatsheet or reference?
I'm used to make/rake for most things, and would love NOT to have to load GUI Xcode every time I needed to rebuild an app...
I'm used to make/rake for most things, and would love NOT to have to load GUI Xcode every time I needed to rebuild an app...
I think you're just looking for the man page. There are blog posts out there showing how to set up CI builds, which will also get you started, but the man page isn't too long and is the authoritative reference for what xcodebuild will do.
I use LLVM mainly for the ability to put ivars in a class extension. I.E.
@interface MyClass() { MyNewIvar *ivar }
@end
@interface MyClass() { MyNewIvar *ivar }
@end
That is rather nifty, I think they can nowadays also be defined in the @implementation of a class.
I am not using ivars much, almost everything is a property. Too bad Apple scrapped the automatic synthesize feature.
I am not using ivars much, almost everything is a property. Too bad Apple scrapped the automatic synthesize feature.
I use Clang (IMO you should rename LLVM Compiler to Clang).
I find putting ivars in my implementation files keeps my headers extremely clean.
done
Misclicked on LLVM-GCC, meant to click on LLVM Clang.
Gambit Scheme.
coffeekit!
gezundheit!