Added checks on doctor.rb for:
* Missing git origin
* git origin not pointing at mxcl/homebrew
Tests use `git config --get remote.origin.url`.
Also added printout of origin to --config.rb.
FixesHomebrew/homebrew#14399.
ClosesHomebrew/homebrew#17117.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
We support three configurations: Xcode-only, CLT-only, and Xcode with
CLT. Our configuration output should correctly reflect this.
While MacOS::Xcode.version has to continue to return a guess if Xcode is
not installed in order to maintain backwards compatibility, this is an
implementation detail that we don't need to expose to the user. And it
makes `brew --config` output confusing.
So let's only print the "Xcode" line when an actual Xcode installation
is present. This makes it easy to quickly figure out which of the three
possible configurations the user is running.
Addresses Homebrew/homebrew#14941, more or less.
Rather than build the whole output in a string, print each item as we
go. This gives the illusion of improved responsiveness by delaying the
expensive method calls until after the faster output.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Apple's X11 is XQuartz, but this can be confusing, and is ultimately
unnecessary for debugging purposes.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
In order to better support Xcode-only systems, where X11 libs and
executables live under /usr/X11 but headers live in the SDK, move the
x11_* helper methods into a new module.
This allows us to keep some of the CLT/Xcode-only and Apple X11/XQuartz
logic hidden from outside code, like ENV.x11.
Since Apple's X11 is actually XQuartz, name the module "MacOS::XQuartz".
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>
Rationale: some users insist on replacing the /usr/bin/ruby symlink
to point to another ruby on their system, which may break homebrew.
Use the full Framework path instead, which is less likely to be tampered with.
This also reorganizes the brew --config checks to reflect the different path.
FixesHomebrew/homebrew#12009.
ClosesHomebrew/homebrew#12333.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
Symptom: If no python/ruby/perl is in your path, then `which x`.chomp
returns an empty string and `unless ""` is still true. So, N/A is never
displayed. Instead, ruby's Pathname.new("").realpath returns the cwd.
(I consider this realpath behavior a ruby bug) Fix: use empty?
ClosesHomebrew/homebrew#10027.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Let's choose the first \d{2,} as the build number, as it is the most
likely to indicate significant changes, and we need something to use for
comparison when selecting compilers.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
The recommended compiler versions printed from `brew-config` are out
of date and misleading. The recommendation is always "Run the latest
version of Xcode available for your platform".
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.
