When referencing `Hardware.processor_count`, `ENV.make_jobs` will return an
integer. If referencing the environment variable `HOMEBREW_MAKE_JOBS`, it
returned a string.
Now, the function always returns an integer.
FixesHomebrew/homebrew#12033.
When referencing `Hardware.processor_count`, `ENV.make_jobs` will return an
integer. If referencing the environment variable `HOMEBREW_MAKE_JOBS`, it
returned a string.
Now, the function always returns an integer.
FixesHomebrew/homebrew#12033.
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>
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>
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.
Useful when CXXFLAGS has diverged fom CFLAGS, e.g. via ENV.append, and
also it is nice for CXX to have symmetry with CC.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Allow the use of a Homebrewed gcc-4.2 in order to support homebrew-alt's
apple-gcc42 formula.
This also removes the :force filtering for the gcc-4.2 check error.
ClosesHomebrew/homebrew#9384.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
In later XCodes, gcc is a symlink to gcc-4.2 which is itself a symlink
to llvm-gcc, so it is necessary to resolve multiple symlinks.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
- Fix ENV.libxml2 to update CPPFLAGS rather than CFLAGS
- Methods ENV.{gcc*,llvm,clang} now reset CPU-specific optimization
flags on every call.
ClosesHomebrew/homebrew#8105.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
The compiler setting in the xcodeproj is overridden by the CC setting in the environment. This is a bit insane IMO since the xcodeproj itself has detailed decisions about what tools to use.
FixesHomebrew/homebrew#6406.
This is used with fails_with_llvm so that if GCC cannot be found (and we suspect this is the case with Xcode 4.2) the build will fail.
Quite possibly it should be the default.
FixesHomebrew/homebrew#7329.
FixesHomebrew/homebrew#7269.
FixesHomebrew/homebrew#7236.
Also quite a lot of tidy. This should all work fine.
I think we only started referring into xcode_prefix because LLVM used to not
be linked into /usr/bin. But for sure this is no longer true. If someone out
there doesn't link cc etc. into /usr/bin then I guess we can revise this patch
but it's not something we officially supported before, it was just an
accident.
I added a test step in the init code so that a working compiler will always be
selected. This is mainly a fallback for old Xcodes. Though a comment in
another area of the code suggested Xcode 3 on 10.5 doesn't have LLVM so…
It seems like latest build of Xcode 4.2 doesn't create "-4.2" links in /usr/bin. Because of this recipes fail with "configure: error: C compiler cannot create executables" error.
ClosesHomebrew/homebrew#7254.
ClosesHomebrew/homebrew#7276.
Signed-off-by: Max Howell <max@methylblue.com>
Amended to work as intended, since /usr/bin/cc is actually since Xcode 4.
Amended commit message. First line must be less than 72 characters! :P
