`MacOS.sdk` and `.sdk_path` will now return the newest installed SDK
instead of nil if called on a system that doesn’t have an SDK for the
currently-installed OS. For example, Xcode 7 on OS X 10.10 does not
include the 10.10 SDK, only the 10.11 SDK; software can be built by
specifying both SDKROOT and MACOSX_DEPLOYMENT_TARGET.
* Pull SDK lookup code into a new `locator` class, which caches its
results
* SDKLocator only queries one SDK location, not all SDK locations
* Build a map of all installed SDKs inside that location, instead of
just the requested SDK
* Ask xcrun for --show-sdk-platform-path first so that all SDKs can be
found, instead of asking xcodebuild for a specific SDK
* Add a new `SDK` class, which tracks the version and the prefix; add a
new `MacOS.sdk` method which returns an `SDK` instance instead of a
bare path; MacOS.sdk_path still returns a bare path
Provide `OS::Mac.prerelease?` for pre-release checks and use it where
appropriate. This should simplify updating the test once a new OS X
release lands.
This also fixes a bug in `BuildError#dump`, where an empty warning
message was printed on El Capitan after a failed from-source build,
because the check there and the one in `check_for_unsupported_osx` were
out of sync.
ClosesHomebrew/homebrew#45257.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
add guard in Formula#file_modified? to prevent git popup
add guard in Superenv.bin before calling MacOS::Xcode.version
add guard against missing Xcode/CLT in Xcode.uncached_version
return nil instread of 0 in uncached_version when Xcode/CLT are not present, to distinguish from linuxbrew behavior
checks against pour_bottle? and needs_relocation?, add guard around keg.relocate_install_names to check pour_bottle?/needs_relocation? as well
needs_relocation? becomes skip_relocation?, use cellar attr to indicate relocation instead of does_not_need_relocation
MacOS.can_build? becomes MacOS.has_apple_developer_tools?
Add these new errors, and guards in formula installation and
cmd/{,un,re}install to match, move can_build? to the MacOS module,
flatten conditions, remove redundant can_build? check
reinstate removed (doctor) check
It’s Christmas. New stable OS X version, new Swift version, new Xcode,
new CLT and a new Clang version.
ClosesHomebrew/homebrew#38468.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Presume this will need to wait for the bots to be updated, but Xcode
6.2 has landed.
ClosesHomebrew/homebrew#37549.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
More Yosemite changes. Within two weeks or so, Xcode should be made
available on the App Store, at which point 10.9 will need to go from
“5.1.1” to “6.0” but whilst Yosemite is in Beta *everyone* should be
using the Xcode Beta builds according to Apple, so Yosemite should be
on 6.1 for the foreseeable, even when Apple releases Xcode 6.0 to 10.9
& below. 6.1 is still using the same Clang version number at this point.
ClosesHomebrew/homebrew#32201.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Since ae177adb2bd55ee5ad6367e7639c4cf0c774b63a, we can safely assume
that xcrun works, and a functioning xcrun will search dev_tools_path and
xctoolchain_path, so we can stop doing extra work here.
On CLT-only 10.7 and 10.8, xcrun will not work, but all the tools will
be in /usr/bin, which we check before invoking xcrun. Further, in this
case, dev_tools_path will be /usr/bin, and xctoolchain_path will not
exist, so the fallbacks here are unnecessary.
It is activated by the same mechanism as the Homebrew/versions compilers
which now check if the GCC formula uses the same, correct version.
References Homebrew/homebrew#28418.
