[88779] trunk/base/src/port1.0/portconfigure.tcl
jberry at macports.org
jberry at macports.org
Wed Jan 11 08:36:40 PST 2012
Revision: 88779
http://trac.macports.org/changeset/88779
Author: jberry at macports.org
Date: 2012-01-11 08:36:39 -0800 (Wed, 11 Jan 2012)
Log Message:
-----------
Avoid an immediate error if xcrun can't find a compiler; just return a potentially bad tool path out of the developer directory, and let calling code figure out that the compiler is no good. This better matches previous behavior.
Modified Paths:
--------------
trunk/base/src/port1.0/portconfigure.tcl
Modified: trunk/base/src/port1.0/portconfigure.tcl
===================================================================
--- trunk/base/src/port1.0/portconfigure.tcl 2012-01-11 16:23:52 UTC (rev 88778)
+++ trunk/base/src/port1.0/portconfigure.tcl 2012-01-11 16:36:39 UTC (rev 88779)
@@ -427,16 +427,19 @@
# Find a developer tool
proc portconfigure::find_developer_tool {name} {
- # Call xcode's xcrun to find the named tool.
- # If this doesn't work reliably (or across enough xcode versions) we
- # may need to fall-back to using ${developer_dir}/usr/bin in some
- # instances (this doesn't work with current builds of Xcode 4.3).
+ global developer_dir
+
+ # Use xcode's xcrun to find the named tool.
set xcrun [findBinary xcrun $portutil::autoconf::xcrun_path]
if {[catch {set toolpath [exec ${xcrun} -find ${name}]} result] == 0} {
return ${toolpath}
- } else {
- return -code error "${result}"
}
+
+ # If xcrun failed to find the tool, return a path from
+ # the developer_dir. The tool may not be there, but we'll
+ # leave it up to the invoking code to figure out that it
+ # doesn't have a valid compiler
+ return "${developer_dir}/usr/bin/${name}"
}
# internal function to find correct compilers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-changes/attachments/20120111/53988efe/attachment.html>
More information about the macports-changes
mailing list