compiler based on Xcode version (was: Re: [80130] branches/release_2_0)

[Ryan Schmidt]

On Jul 4, 2011, at 22:56, jmr at macports.org wrote:

> Revision: 80130
>          http://trac.macports.org/changeset/80130
> Author:   jmr at macports.org
> Date:     2011-07-04 20:56:34 -0700 (Mon, 04 Jul 2011)
> Log Message:
> -----------
> merge r80088 from trunk:
> choose default configure.compiler based on Xcode version (#30009)


> +    global xcodeversion macosx_deployment_target
> +    if {$xcodeversion == "none" || $xcodeversion == ""} {
> +        return gcc
> +    } elseif {[rpm-vercomp $xcodeversion 4.0] >= 0} {
> +        return llvm-gcc-4.2
> +    } elseif {[rpm-vercomp $xcodeversion 3.2] >= 0 && $macosx_deployment_target != "10.4"} {
> +        return gcc-4.2
> +    } else {
> +        return gcc-4.0

The "heads-up" here is going to be that if a port is going to use libtool, then libtool must be built using the same compiler being used to build the current port. (Otherwise you get the dreaded "unable to infer tagged configuration" error; search the issue tracker for many previous occurrences back when we switched the compiler from "gcc" to a specific gcc.) So, for example, users who have already had Xcode 4 on Snow Leopard will have a libtool built using gcc-4.2. Once they upgrade to MacPorts 2.0.0 they'll be using llvm-gcc-4.2, and anything they try to build using libtool will fail, until they rebuild libtool with llvm-gcc-4.2.

To avoid such problems we could increase the revision of libtool after MacPorts 2.0.0 is released, to force a rebuild. But to ensure that users upgrade to MacPorts 2.0.0 first, the port would need to basically require MacPorts 2.0.0, and I'm not sure how to detect the MacPorts version from within a Portfile.