Hacker News Reader

Comment by jordigh | Hacker News Reader

I don't think it's your choice what you hook underneath Xcode. I think it's Apple's choice. Since Xcode is non-free, you can't modify it to use something else will-nilly.

All of the fancy static analysis that Xcode does is completely tied to clang, for example. Its debugger front-end is tied to lldb's idiosyncratic interface. It's not something that you can just easily replace with non-Apple compilers.

View on HN

  All of the fancy static analysis that Xcode does is completely tied to clang, for example.

Xcode doesn't do static analysis; Clang/LLVM does, and it's perfectly possible to do it from the command line, or embed it in other tools. (This is an example of the difference between LLVM's modular library architecture and GCC plugins — LLVM doesn't insist on being ‘on top’.)

So it is easily replaceable? You could easily tell xcode to use gcc if gcc supported the same kind of static analysis? How would you do this?

I don't work for Apple and have never seen Xcode source, but my guess (based on what I would do) would be that Xcode invokes Clang/LLVM as libraries rather than a standalone binary, in order to keep persistent state. In principle GCC could present such an interface, but in practice FSF policies prevent it. The point is that the static analysis can be used directly or by other tools (there is a web interface, for instance); it is not restricted to Xcode.

So... it's not apparently possible without modifying the source code. So like I said originally, what Xcode is using for static analysis is apparently Apple's choice, not yours nor mine.

Yes; what's the point? Nobody's making you use Xcode (I don't), and nobody's stopping you using the Clang/LLVM features like static analysis outside of Xcode. If you want, you're free to call clang's static analysis from GNUstep's Xcode clone¹ (assuming GNUstep's license allows that; LLVM's certainly does), or any other IDE or editor.

¹https://github.com/gnustep/gnustep-xcode

Yes it's replaceable. I've used it with newer builds from the open source project. They even provide binaries and instructions: http://clang-analyzer.llvm.org/xcode.html

If by replaceable you mean using some other analyzer, I'd say it's not easily replaceable but if you can produce an analyzer that produces similar output and that's has the same options, then sure. clang in fact did that sort of thing with their gcc driver.

If GCC supported that (and if Xcode supported GCC's support of it), you'd probably tell Xcode to use it the same way you tell Xcode to build with GCC instead of clang: You'd select the option in your project settings.

Nobody's made the claim that Xcode is some kind of magical dynamic IDE that supports arbitrary hypothetical features of arbitrary hypothetical versions of arbitrary compilers that you can mix and match on the fly.

Nevertheless it is the case that Xcode allows you to select between clang and GCC 4.2 backends.

GCC support in XCode has been less and less GCC and more and more just the LLVM cleverly disguised as GCC. With XCode5 there is nothing left from the actual GCC project, even gdb has been entirely replaced with lldb. So now if you chose GCC in XCode you're not really using GCC at all.

Those are merely features of the IDE. The compiler used for actual building is configurable per project.

>"Its debugger front-end is tied to lldb's idiosyncratic interface. It's not something that you can just easily replace with non-Apple compilers."

What I going to say might not be true any more, since the last time I worked on Xcode was roughly two years ago. But by then I worked as a mobile game developer and at the studio we happily compiled in both GCC and LLVM. Actually we preferred to use gcc and gdb since LLVM debugger was very buggy at that time.

This is how you could install gcc to work with XCode 4.3

http://stackoverflow.com/questions/9353444/how-to-use-instal...

And I wouldn't call LLVM/Clang an Apple's compiler, since it is contributed by people from Google too.

> And I wouldn't call LLVM/Clang an Apple's compiler, since it is contributed by people from Google too.

It's about as much of an Apple compiler as gcc is an FSF compiler.

All true, but that makes Xcode a proprietary IDE, not a proprietary compiler. Apple doesn't make a proprietary compiler.

Reply on news.ycombinator.com