Setting -mcpu and -mtune on Tiger with gcc-4.2 exposes a bug in one of the
system headers, causing certain builds to fail. This can be fixed by
adding -faltivec to CFLAGS.
See: http://trac.macports.org/ticket/34213
Old logic doesn't include revision. This fixes that, and passes the
whole formula prefix path to avoid duplicating the path-construction
logic.
Closes#80.
Signed-off-by: Andrew Janke <andrew@apjanke.net>
Previously, superenv did not try to filter -I or -L flags
based on the list of requested dependencies; as a result, buildsystems
which opportunistically discover Homebrew-installed libraries were able
to link against them even under superenv.
This adds a list of all requested dependencies to the superenv environment,
and compares all -I and -L flags against those; any Cellar and opt paths
found which resolve to unrequested dependencies are filtered out.
SDK 10.10 isn't something that exists for Xcode 7, so stop looking for
it and rely on MACOSX_DEPLOYMENT_TARGET instead.
See PR Homebrew/homebrew#50137 Yosemite build failure
ClosesHomebrew/homebrew#50355.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
`Library/ENV` like `Library/Homebrew` is part of Homebrew basecode. It
should be able to be accessed during the `brew tests`.
By adding HOMEBREW_ENV_PATH variable, we allow test suit to locate these
codes.
HOMEBREW_MAKE_JOBS can be a multidigit number. The regex should match
the entire number not just the last digit.
ClosesHomebrew/homebrew#50016.
Signed-off-by: Tim D. Smith <git@tim-smith.us>
In theory, letting these be set once wasn't an awful idea because it allows
users choice on where Perl modules end up.
In reality, as we've moved closer to sandboxing and at the same time accepted more
perl binding options into formulae it has been exposed as something of a hellraiser.
It's not that uncommon for Perl users to set a custom `INSTALL_BASE` in the ENV which
means we end up with quite a few formula that fail hard with this sort of error:
```
Only one of PREFIX or INSTALL_BASE can be given. Not both.
```
The other common error, which we discovered via sandboxing, is that the Perl modules
end up outside Homebrew's control which means we don't automatically remove them
when the package is removed. Sandboxing blocks this, which means when we eventually
move to enable that by default for users as well as CI it'll quickly become a
prominent issue.
Raise an error when attempting to create universal binaries with a GCC
that can't do so.
ClosesHomebrew/homebrew#46630.
Signed-off-by: Baptiste Fontaine <batifon@yahoo.fr>
add guard in Formula#file_modified? to prevent git popup
add guard in Superenv.bin before calling MacOS::Xcode.version
add guard against missing Xcode/CLT in Xcode.uncached_version
return nil instread of 0 in uncached_version when Xcode/CLT are not present, to distinguish from linuxbrew behavior
checks against pour_bottle? and needs_relocation?, add guard around keg.relocate_install_names to check pour_bottle?/needs_relocation? as well
needs_relocation? becomes skip_relocation?, use cellar attr to indicate relocation instead of does_not_need_relocation
MacOS.can_build? becomes MacOS.has_apple_developer_tools?
It's not clear whether it returns MAKEFLAGS with or without -j<n>, and
neither is particularly useful behavior, given you can easily get the
exact value by calling ENV["MAKEFLAGS"]. So let's not commit to this
API.
The xcrun script should be skipping the ENV directory when it scans
$PATH looking for tools to run. Unfortunately, the script compares the
paths found to the real path of the ENV directory (following symlinks),
but superenv was adding the nominal path to $PATH, not following
symlinks. As a consequence, platforms with Xcode < 4.3 would get into
infinite loops when trying to call non-system versions of gcc, as xcrun
calls the ENV version of gcc-X.X which calls xcrun and so on forever.
This commit changes superenv to follow symlinks when determining the bin
path to use.
FixesHomebrew/homebrew#33731.
ClosesHomebrew/homebrew#40062.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
