Print path of first detected Git instead of executing it. This is hidden
behind a `--homebrew=print-path` argument that is unlikely to conflict
with any existing or future Git flags.
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>
Using `git` from `Formula#install` can cause an exec bomb if used in a
formula with `env :userpaths` because that causes both `Library/ENV/4.3`
and `Library/ENV/scm` to be in PATH, both of which contain a `git`
binary that is the same SCM wrapper. Those will mutually exec each other
indefinitely as they fail to detect that they are the same wrapper.
Extend the exec-bomb protection to check the paths after all symbolic
links have been expanded to prevent this situation.
Fixes#43.
FixesHomebrew/homebrew-core#133.
FixedHomebrew/homebrew-core#143.
Closes#46.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
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.
"--fast-math" caused build failure with clang for
homebrew/science/delly-0.7.2
Apparently, clang only likes this option when it's referred to as
"-ffast-math"
ClosesHomebrew/homebrew#50507.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
`/usr/bin/<tool>` will be a popup stub under such configuration.
The idea is to let `scm/git` to handle all of git location resolution
throughout Homebrew codebase.
Some things can break in hard to debug ways if users or build scripts
set these variables, causing our otherwise quite robust Ruby wrappers
to fail. In theory, we could also use `--disable-rubyopt`, but this is
not supported in Ruby 1.8 (and we still care about it).
Use the same interpreter for the shims that is also used to run the main
Homebrew process (the one invoked via `brew`). The magic basically lies
in executing `ruby` with the `-x` option (supported since at least 1.8)
and in the following shebang line.
This matches the version shipped with 10.10.5.
The list of supported features/protocols was obtained
using `curl-config`:
```
features="`curl-config --features`"; echo "${features//$'\n'/ }"
protocols="`curl-config --protocols`"; echo "${protocols//$'\n'/ }"
```
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
ClosesHomebrew/homebrew#46073.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
If this was set at build-time (i.e. by the Ruby 1.8.7 buildsystem) then
`cc` could be passed arguments and fail to run.
ClosesHomebrew/homebrew#45890.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Removing all sysroot flags is ok until a non-OS X SDK is needed. In
that case, builds can fail due to the non-OS X SDK being overwritten or
overridden by the OS X SDK.
Sysroot flags are now only stripped if they are an OS X SDK. This is
reliant on only OS X SDKs containing the string "macosx", so this will
break if if the wrong SDK shows up. However, the chances of that
happening seem low, as Apple probably doesn't want to introduce
something OS X that doesn't work with OS X, so it should be robust for
the near future.
This could break in an environment without the command line tools. The
fix for that is a bit more involved, though, so that will have to go
later.
ClosesHomebrew/homebrew#44312.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
native pkg-config support for zlib and sqlite to elimate the need
to pass flags to configure or make stages in formulae.
ClosesHomebrew/homebrew#34765.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Yosemite is having the same issues as Homebrew/homebrew#24590 in the past on upgraded machine. Bump to pod2man5.18.
ClosesHomebrew/homebrew#33436.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
