Allow XCode without the Command Line Tools to
work with homebrew, so it's not necessary
to register an Apple Dev ID and/or go to the
XCode prefs and download the CLT. Yay!
Further, this commit allows to use the CLT
solely (without the need for XCode).
Saves quite some megs.
(Some furmulae require xcodebuild)
Of course XCode together with the CLT is still
fine and has been tested on 10.7 and 10.6
with Xcode 4 and Xcode 3.
Only on Lion or above, tell the user about the options,
which are
- Xcode without CLT
- CLT without Xcode
- both (ok, it's not directly stated, but implicit)
So if no Xcode is found and we are on Lion or above,
we don't fail but check for the CLTs now.
For older Macs, the old message that Xcode is needed
and the installer should be run is still displayed.
If the CLT are not found but Xcode is, then we
print out about the experimental status of this setup.
ClosesHomebrew/homebrew#10510.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
Keg#fix_install_names punts if bad install names reference dylibs that
aren't "nearby". Enable this machinery to fix more complex directory
hierarchies by searching everything under 'lib' for the bad name's
basename.
Additionally, teach it to correctly handle Mach-O bundle files.
FixesHomebrew/homebrew#12810.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Some libraries do not have the .dylib extension (e.g. Qt framework
libs), but need to have their install names rewritten to prevent other
packages from breaking due to upgrades. Use the new Pathname#dylib?
instead.
FixesHomebrew/homebrew#6065.
My pre-emptive fix that avoided calling Pathname.ensure_writable because I was not convinced it worked broke this function due to incorrect logic.
The lesson is, don’t write pre-emptive fixes. Wait until you've seen the bug first. All code has bugs in, so write less. I'm an idiot sometimes.
FixesHomebrew/homebrew#2709.
By forcing dylibs to have an install_name id that is the HOMEBREW_PREFIX path, ie. the symlink’s path. Stuff that links to these dylibs will use this id and thus by immune to upgrades of underlying libraries.
Thus whatever keg is "current" ie. linked, will be the library that is used by the tool.
This fix is not retroactive. So there will still be breakage for existing installations of stuff.
The fix_install step in install is moved after the link step as the symlinking
is required to determine the eventual ids for each dylib.
