This is in part designed to handle situations described in https://github.com/Homebrew/legacy-homebrew/issues/42273
where we tell someone to install a special dependency, but because we (rightly, IMO)
resolve special dependencies first users can end up being told to execute a command
on a tool that isn't yet installed and isn't immediately obvious how to install it.
In the situation raised there, with the `sile` formula people are being told to
`luarocks install xyz` but we hadn't installed Lua for them first, so they just
get a `command not found: luarocks` message. Perhaps it should be obvious enough
how to install said tools by looking at the formula's dependencies,
but it's not a huge burden on us to make life easier than that.
Shuffled over from https://github.com/Homebrew/legacy-homebrew/pull/42576.
This test wasn't running by default, so we missed that it wasn't
actually being executed - or that it was failing when running in the
testing environment.
As far as I can tell this is not, and has not, been used either in core
or in any tap, third party or otherwise, so just remove the feature and
its test.
It made less sense to call a method `java_version` when it returns
boolean value.
ClosesHomebrew/homebrew#45501.
Signed-off-by: Xu Cheng <xucheng@me.com>
The Emacs shell sets $EMACS to "t" for detection purposes, but it causes
builds to fail when they attempt to call Emacs using the variable.
FixesHomebrew/homebrew-emacs#30.
ClosesHomebrew/homebrew#45495.
Signed-off-by: Alex Dunn <dunn.alex@gmail.com>
This reverts commit 85271644b0083cbc0fd6fea71120d1ad859fbc2a.
Alex noticed that setting PYTHONPATH causes weirdness if we depend_on
something which may be optionally built --with-python3; PYTHONPATH
unexpectedly contains python3 modules in the depending formula if
the formula upon which it depends was built --with-python3 even
though the depending formula may only use python2.
ClosesHomebrew/homebrew#43724. ClosesHomebrew/homebrew#43744.
Install it as a dependency unless already satisfied by Xcode.
require cctools_requirement
cctools_requirement should be satisfied by cctools present in opt
add build_env => false to the satify block options in CctoolsRequirement
Dependency is another similar, related class and it's super confusing
to have some Requirements that are named *Dependency.
ClosesHomebrew/homebrew#38891.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Per requirements.rb:
> XXX If the satisfy block returns a Pathname, then make sure that it
> remains available on the PATH. This makes requirements like
> satisfy { which("executable") }
> work, even under superenv where "executable" wouldn't normally be on the
> PATH.
> This is undocumented magic and it should be removed, but we need to add
> a way to declare path-based requirements that work with superenv first.
Fixeshomebrew/homebrew-python#170.
ClosesHomebrew/homebrew#38448.
We want the apr requirement to act as a build-time requirement in case
it is satisfied (that is, the CLT is installed), as the resulting
binaries will link to the system libapr which is always present.
When it is *not* satisfied by the CLT, and we need to install the
formula, we have to treat it as a runtime dependency since the resulting
binaries will link to it.
FixesHomebrew/homebrew#36301.
FixesHomebrew/homebrew#36438.
ClosesHomebrew/homebrew#36443.
If apr is installed, we still want to grab it during dependency
resolution in case we need to pass options to the generated dependency.
In other words, it doesn't make sense for the satisfiable condition to
include the default formula, as the default formula is the fallback for
when the requirement is *not* satisfied.
Migrates Apr from Homebrew/Apache to Homebrew/Homebrew, adds a
requirement to allow people to use this Apr instead of requiring
people to download the full CLT package. Tested against subversion
with consistent success.
ClosesHomebrew/homebrew#34987.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Also, tweak the XQuartz requirement to not show 0.0.0 versions being required.
ClosesHomebrew/homebrew#35254.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
