On Jul 4, 2011, at 22:56, [email protected] wrote:
> Revision: 80130
> http://trac.macports.org/changeset/80130
> Author: [email protected]
> 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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
