[PATCH] Let the default compiler be configurable

[Ryan Schmidt]

On Jun 11, 2011, at 14:08, Jack Howarth wrote:

> FYI, my path-prefix-clang patches were just committed to fink cvs so that on 10.7 and later
> the default compiler for cc/gcc is symlinked to a compiler wrapper for clang and for c++/g++ to
> the same for clang++. This behavior can be overridden with SetCC/SetCXX. Sounds like what you want
> to do with MacPorts 

You've suggested a compiler wrapper before, but we've managed without one so far in MacPorts and I don't see a reason to change it now. I'm especially not sure what a compiler wrapper has to do with the topic of this thread. Unless you're suggesting that MacPorts would always use a compiler wrapper, and that that wrapper would then call the user's chosen default compiler. If so, what benefit do you believe this would offer over just calling the user's chosen default compiler directly?

> (although I would suggest defaulting to clang/clang++ on 10.7).

The default for MacPorts has always been the default for what Apple ships with Xcode. Previously this was easy since Xcode always used gcc, so we just looked at the /usr/bin/gcc symlink to see what version of gcc it pointed to, and coded that into MacPorts defaults. Do we know what Xcode in Lion uses / will use? Is it llvm-gcc -- as we suspected some time ago when we tentatively programmed that into MacPorts, and which I believe is what has just gone out as Macports 2.0.0 beta 1 -- or is it clang?

> The llvm-gcc
> compiler development is pretty stagnant and important fixes like that for http://llvm.org/bugs/show_bug.cgi?id=9571
> aren't going to be backported to llvm-gcc in Xcode any time soon if ever. Since the WWDC Xcode release, the
> only blocker, http://llvm.org/bugs/show_bug.cgi?id=9862, has been fixed. All of the other issues that I have run
> into building fink packages with clang 3.0svn have either been language compliance issues (eg main can't return unsigned int)
> or actual latent programming errors that clang's optimizers expose.