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>
