- Name of the brewed formula in "Summary" heading.
- At the beginning of the summary line a 🍺 is given out
(but only on Lion or above). This acts as a nice
visual marker for the end of a brew-ing process.
- When brewing a dependency, the name is highlighted in green.
- `oh1` is bold, too (like ohai).
ClosesHomebrew/homebrew#16020.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Originally written for tigerbrew, but useful enough for core.
Replaces the shelled-out which in utils.rb with a native-ruby
equivalent, which is moderately faster.
ClosesHomebrew/homebrew#16659.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
This has to be a last resort right? If all we show is that link (plus preceding un-deletable output) and they don't click it then maybe we should just close the ticket and hope they'll use MacPorts instead.
All logs are now stored from each command executed in Formula.install.
Error output is truncated to five lines in an attempt to not overwhelm the user and to encourage users to read the error output and report the bug properly. Maybe we can get that figure up from 70% to 90%.
Let's not show weird error messages when user interrupts during various stages of brew initialization.
Tested by doing `for x in $(brew search); do brew install $x; done` and pressing CTRL-C at random short intervals.
FixesHomebrew/homebrew#12779. ClosesHomebrew/homebrew#12784.
utils.rb invokes bash as a non interactive shell to run the editor
when you run brew edit.
Non-interactive shells are not intended to capture user input and for running scripts. Whilst the invocation of the editor is a script the actual editor is intended for accept user input so this is an issue with brew and not emacs.
This causes issues with emacs which has different behaviors when not running under an interactive shell.
Signed-off-by: Max Howell <mxcl@me.com>
Some programs fail where they would otherwise succeed if stdout or stderr is
closed. For example, using mpicc from the mpich2 formula:
quiet_system 'mpicc', '--version'
Fails with:
LLVM ERROR: IO failure on output stream.
While
system 'mpicc', '--version'
Succeeds.
ClosesHomebrew/homebrew#13253.
Signed-off-by: Charlie Sharpsteen <source@sharpsteen.net>
Undoing parts of the hot fix 78b9e8548e771a59e382e6f13339664ec5498391.
The only thing missing was to check for `system "/usr/bin/xcrun -find make 1>/dev/null 2>&1"`
and then it's safe to call locate.
This commit restores the original functionality but without the risk for recursion
and improves the logic of `MacOS.locate`. See below.
To important changes in this commit:
- For Xcode _and_ CLT: don't add the SDK and leave things as before.
So if `MacOS.clt_installed?`, then no `SDKROOT` and `-L` and `-I`
directories are set in `ENV.macosxsdk`.
- Improved the logic for `MacOS.locate` for Xcode-only situations
by assuring that the xcode-select path is correct. This is done
by checking that `bin/make` exists and is executable. Otherwise it
was possible to set xcode-select to an empty dir.
This check is done in `MacOS.sdk_path` too.
We are now able to use Xcode wherever it is and can work even, if
xcode-select is set to invalid values. (Remember some users don't
have sudo access and that is needed to fix xcode-select).
Some minor whitespace fixes.
Minor backtick fix in doctor.rb's printout.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
According to a user on IRC with a brand-new Mac, xcode-select is preconfigured
to /Developer out of the box even though that doesn't exist on modern Xcode.
So we shouldn't trust that it makes any sense.
Under certain circumstances, MacOS.locate and MacOS.dev_tools_path would call
each other recursively. This was limited to systems with Xcode minus the CLT.
See Homebrew/homebrew#13012.
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>
- Reimplement archs_for_command on top of the new Mach-O methods
- Move ArchitectureListExtension to mach.rb
- Add a test for the ArchitectureListExtension
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
'which' only returns a Pathname or nil, and doesn't care about anything
sent to stderr, so just silence it by default and combine the two
methods.
ClosesHomebrew/homebrew#12115.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
A common source of build problems on Xcode 4.3+ is outdated compilers,
usually when a user has installed over top of an old version and hasn't
installed the CLT. Since the compilers from the previous Xcode are still
around, brew doctor wouldn't complain.
This adds a hash containing a list of the canonical compiler versions
for supported versions of Xcode, and adds a check against that to determine
whether a given installation has any compilers which are out of date.
ClosesHomebrew/homebrew#11518.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
