On 2011-7-6 03:05 , Ryan Schmidt wrote: > 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.
So wait, does that mean that libtool can't be used by ports that have to change configure.compiler for whatever reason? - Josh _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
