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>
We don't penalise existing users; if ~/Library/Caches/Homebrew already exists and is writable, we select that.
This is the correct choice, the cache should be the same directory whichever user is used and whatever instance of brew is invoked.
The Cache directory is set to 0777 this allows any user to write to it and fixesHomebrew/homebrew#10857.
This version number is arbitrary, and only used to differentiate versions
in bug reports.
There have been enough changes to compiler detection since 0.8 that it makes
sense to bump the version here.
Several issues have been caused by conflicts between the options
Homebrew passes to curl and those read from $HOME/.curlrc. Passing '-q'
will force curl to ignore settings in that file.
Suggested in Homebrew/homebrew#9027.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
The code was sucking. To the extent that maintenance was hard. It's a lot
easier to work with code that is sensibly split at sensible boundaries. So
now it is more like that.
But the refactor is minimal. Because we don't want you to have more merge
hell than absolutely necessary.
If you merge you will need to pay attention to brew.h.rb (as it is deleted)
and bin/brew (as command logic is gone). It will be painful, but you will just
have to help git out by moving any changes around manually.
Note compatibility.rb. It ensures that any function renames or removals don't
break anything. We're pretty serious about backwards compatibility. And that's
because we encourage you to hack around with the innards. And we couldn't do
that if we would then just make stuff disappear behind your back.
The Homebrew version number is mainly useful for bug reports. Since it is
included in "brew --config" output, it is an easy way to see roughly how
new the a user's version of Homebrew is.
Bumping the micro version now, in anticipation of some more version-changing
events in the near future.
Changes in this version include:
* Aliases are now defined by relative symlinks rather than in the
formulae themselves. Many commands are faster now that they don't
have to read every formula to find aliases.
* "url" now supports the same features as "head", including ":using"
and version specifiers for VCS systems.
* Files and methods marked for deprecation in 0.7 have been removed.
* The Formula DSL now supports "skip_clean :all" and "keg_only 'reason'"
Thus install.rb gets the path to the instantiating brew process rather than whichever is first in the PATH. Not to mention Homebrew doesn't *have* to be in the PATH.
