Not quite a mass replacement as I've used OS X and Mac OS X where
describing specific older versions and added compatibility methods
for things in the DSL.
A failure to change a dylib ID or install name would previously cause a
rather cryptic error message, that didn't include the name of the file
that caused the failure, unless `--debug` was specified. Make sure to
output this information in all cases before re-raising the exception.
On systems prior to 10.9, formulae that use CVS as a download source
check whether the installed Xcode already provides CVS to avoid adding
a dependency on the `cvs` formula. Unfortunately, if no Xcode is
installed the check fails with
undefined method `<' for nil:NilClass
causing the formula to become unloadable. This in turn causes some taps
to be untappable since #396 added the `readall` check on `tap`.
Closes#508.
Move some stuff formerly in `Library/ENV` around:
- Move `Library/ENV/$XCODE_VERSION` to `Library/Homebrew/env/super` as they are
all superenv wrappers and all symlinks to the same version. We never needed
the "separate shims for separate versions" functionality and it just adds
confusion.
- Move `Library/ENV/pkgconfig` to `Library/Homebrew/env/pkgconfig` to get more
things under `Library/Homebrew`
- Move `Library/ENV/scm` to `Library/scm` as these wrappers are not actually
used by or related to superenv (or stdenv) in any way.
Both the `CctoolsMachO` and `RubyMachO` module implement a common set of
methods that simplify querying `mach_data`. Move these into a shared
module, that gets included after either of these implementations is
loaded and included in `Pathname`.
This primarily benefits CLT-only systems where invoking the `xcodebuild`
wrapper in `/usr/bin` will fail (twice) with the following message:
xcode-select: error: tool 'xcodebuild' requires Xcode, but active
developer directory '/Library/Developer/CommandLineTools' is a command
line tools instance
Closes#198.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
Due to a typo, the range of LLVM build versions 2066 to 2325 were never
matched and thus Xcode 3.2.0 could never be inferred from that. (Only
relevant for legacy systems. Doesn't seem to have impacted any users.)
