If the environment variable HOMEBREW_TEST_GENERIC_OS is set ensure that
neither Mac nor Linux-specific code is loaded. This allows easier
testing of cross-platform code on OS X and will make it easier to port
Homebrew to platforms other than OS X and Linux.
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.)
Generally it seems user agents are all `software/version` but ours is
not. Also, set the user agent in a way that it's shared between Bash
and Ruby code.
Closes https://github.com/Homebrew/legacy-homebrew/pull/50480.
Don't use ensure to do the final check because it won't affect the
return value of the overall function.
Thanks to @xucheng for catching this bug.
ClosesHomebrew/homebrew#50536.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
SDK 10.10 isn't something that exists for Xcode 7, so stop looking for
it and rely on MACOSX_DEPLOYMENT_TARGET instead.
See PR Homebrew/homebrew#50137 Yosemite build failure
ClosesHomebrew/homebrew#50355.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
Resolves an issue where xcode-select output with a terminal slash leads
to superenv failing to strip system library paths from ccld-style
invocations.
FixesHomebrew/homebrew#49731. Discussion in Homebrew/homebrew#50154.
The current approach of suppressing all output regardless of what the
error is makes it very hard to debug any issues and misread but valid
Mach-O files will be silently interpreted as non-Mach-O files instead.
Prefer to fail if we are a Homebrew developer or running on the bot
(`HOMEBREW_DEVELOPER=1`), so that problems will be noticed and fixed
before the silent failure leads to hard-to-diagnose user problems.
ClosesHomebrew/homebrew#48817.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
- and branch for dylib_id_and_dylibs
- add branches for dylib id changing and change_install_name
- rename MachO module to HomebrewMachO to prevent namespace clashes
with MachO in ruby-macho. this will eventually be replaced entirely
with direct calls to ruby-macho methods
- break ruby-macho implementation out into separate RubyMachO module,
and include either RubyMachO or CctoolsMachO (the original
implementation) based on the HOMEBREW_RUBY_MACHO env var
- move ArchitectureListExtension and RubyMachO into separate files
- create {ruby_,cctools_,,}relocate.rb for isolation of different
methods of mach-o relocation (ruby-macho vs. cctools)
- fill in require_install_name_tool? for ruby_relocate.rb
- rename {ruby_,cctools_,,}relocate.rb to keg, isolate requires in
os/mac
ClosesHomebrew/homebrew#45001.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
remove old mach.rb, replace with cctools_mach.rb and prune ELF case
move ArchitectureListExtension to separate file ELF support is
maintained in Linuxbrew
`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
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>
