* 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
The order ought not to matter, but GCC can fail with -arch i386 -arch
x86_64 (producing an error like "FATAL:Bad fx_size (0x8) in
fix_to_relocation_info()") but succeed with -arch x86_64 -arch i386.
ClosesHomebrew/homebrew#45401.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
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?
Ensures we capture Clang's fourth-digit when it exists. This seems to be on pre-release
versions of OS X only, but is the cause of the misdetection of CLT up-to-date status
on 10.11 several weeks ago.
For full explanation, see Homebrew/homebrew#42261.
ClosesHomebrew/homebrew#42261.
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>
It seems that "com.apple.pkg.CLTools_Base" was only used for one
release. New releases are using "com.apple.pkg.CLTools_Executables"
again.
FixesHomebrew/homebrew#33063.
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>
