Refs http://stackoverflow.com/questions/9762943
The system ln no longer outputs anything. Though the user can force its output with a --verbose of course. So in cases where it's not the usual of: not writable or existing file, we can ask the user to run with --verbose. I don't particularly like hiding its output, but it just confused the error IMO since it is creating a relative symlink the output was weird every time I've seen it in tickets.
I made a print wrapper so that the brew-link output doesn't get mucked up if an exception is thrown.
Rationale: Let's not have duplicate-names. Insisting on only one directory lets the filesystem enforce this unique-naming criteria for us.
We special-case adamv/alt for now, until we remove it.
Rationale: well, it should always have been like this!
However now we are opening ourselves up to more-mixed installations of formula not maintained by us, it's important that
GFortran chokes when it is passed CPU flags specific to Clang. This change
ensures the environment variables `FCFLAGS` and `FFLAGS` contain the same CPU
flags that would be set for the GCC compiler.
FixesHomebrew/homebrew#10424.
FixesHomebrew/homebrew#10744.
ClosesHomebrew/homebrew#10774.
Signed-off-by: Charlie Sharpsteen <source@sharpsteen.net>
All logic has been copied into a new method `set_cpu_flags` that accepts an
additional argument, `flags`, which contains a list of environment variables
for which the CPU flags are to be adjusted.
`set_cpu_cflags` now recalls `set_cpu_flags` and passes `cflags_flags` as the
first argument.
Signed-off-by: Charlie Sharpsteen <source@sharpsteen.net>
`ENV` methods that modify environment variables, `prepend`, `append` and
`remove`, can now accept lists of flags as well as a single flag.
The list of flags affected by `append_to_cflags` and `remove_from_cflags` are
now definied in a shortcut method `cc_flag_vars`.
Signed-off-by: Charlie Sharpsteen <source@sharpsteen.net>
If it exists, ARGV.kegs will return the Formula.prefix keg for each rack examined.
So for ARGV=[wget, foo] and the following Cellar (wget/1.11, wget/1.12, foo/1.0) you'll get [wget/1.12, foo/1.0] from ARGV.kegs provided 1.12 is the formula version of wget.
In fixing this I also made it so that ARGV.kegs will return the LinkedKeg if the symlink is set. Which is almost always is. This neatly avoids most multiple-kegs issues.
FixesHomebrew/homebrew#10685.
The :force behavior for ENV.gcc has been the default for some time, and
was used to force vanilla gcc in case the gcc symlink pointed at
llvm-gcc; for ENV.clang, this doesn't mattera as clang is just clang.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
The clang frontend ignores a number of options that are accepted by gcc
and llvm-gcc. However, it produces a warning for each unused argument at
each invocation, which can result in many lines of noise, e.g.
clang: warning: argument unused during compilation: '-rdynamic'
Since these arguments do not affect compilation, let's just silence the
warnings by passing '-Qunused-arguments' to clang by default.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
These now return an Array of all the target destinations.
Previously, if a single argument was passed a single non-
Array was returned.
This behavior has been changed so that an Array is always returned
even for a single argument.
Updated the test.
Hopefully this won't break any custom code out there.
Also xcrun can only exist at /usr/bin/xcrun.
Most of these edges are non-buildable environments, but I didn't know that when writing it, so it may as well stay, since it still does make brew --env more correct.
Using xcrun as a proxy to execute the compiler tools is per its design. This means you can't treat ENV['CC'] as a path anymore, but I think I found the cases this was being expected and corrected them. It was not proper anyway to assume the variable was a path, it can be anything. Like a proxy. Like xcrun.
Also more thoroughly clear ENV.
If we're going to unset GREP_OPTIONS we may as well unset this one too,
as it causes similar issues. Recent autoconf unset both of these.
FixesHomebrew/homebrew#8165.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
This was probably a stupid decision in the first place. Who wants lengthy compile times for debatable gain? Apple use Os in all Xcode projects, so I'm guessing its the best choice.
Also I have long suspected the Image Magick performance issues Homebrew is supposedly susceptible to were because of O3.
