| Age | Commit message (Collapse) | Author |
|---|
|
For example `brew search homebrew/science` to get a list of all formulae
from that tap, even if not yet tapped.
`brew search <user>/<repo>/<substr>` or
`brew search <user>/<repo> <substr>` to grep for `<substr>`
inside of the tap `<user>/<repo>`.
|
|
- Show a one liner that will append to
the user's ~/.bash_profile. In 95% this will be
ok and we assume zsh people are smart enough
to know what they have to do.
|
|
Improve robustness of `PYTHONPATH` by first unsetting it (during
`satisfy`) so that the `PythonInstalled` can get the `python.version`
and so forth and then, after that, setting the `PYTHONPATH` to our
`global_site_packages`.
In the `python_helper` we append to the `PYTHONPATH` so if that var has
been set in a formula, it is respected.
Brew audit does no longer complain about setting the
`ENV['PYTHONPATH']`.
|
|
that live in the `libexec` dir of a `Cellar`.
|
|
|
|
If a formula is passed with a relative path, the build process might
try to expand it in the wrong directory, where it doesn't exist.
Fixes #22266.
|
|
This reverts commit 7db9ef9650a44ef8155bf66efd88703e580057b0.
|
|
|
|
ENV.compiler is called outside setting up the build environment, where
values unsupported for user input might have been specified - for
example, GNU GCC executables.
|
|
There are now a few possible C++ standard libraries a given build could
be using, with subtle incompatibilities and possibility of breakage
when mixed. This makes sure that the dependency chain was compiled in
a compatible manner.
Fortunately all of the Apple compilers use the same libstdc++, and we
don't yet support building with libc++, so this will primarily only
nag users trying to use GNU gcc who already have software installed
with Apple compilers.
Future TODOs:
* Add general support for building with libc++ (compatibility checking
already handled here)
* Possibly track formulae which actually build C++ bindings, so that
users aren't bothered by spurious nagging re: interpreted languages,
pure-C software, etc.
|
|
There are subtle incompatibilities between Apple's libstdc++ and the
libstdc++ used by the various GNU GCC formulae. In addition, we'll
likely also be supporting libc++ in the future, and that's also
incompatible with the other stdlibs.
Tracking it in the tab lets us make sure that dependencies are all
built against the same stdlib to avoid subtle breakage.
|
|
The parent process doesn't have access to the selected compiler, which
will be important in the next commit.
Fortunately the child process already has a filtered and massaged
ARGV, so it has enough information to build the tab itself.
|
|
This adds support for non-Apple GCC compilers in the fails_with code.
A fails_with block for a non-Apple compiler looks like:
fails_with :gcc => '4.8.1' do
cause 'Foo'
end
Non-Apple compilers don't have build numbers, so compiler failures are
based on version strings instead.
Internally non-Apple compilers can be distinguished because they are
passed around as strings instead of symbols.
In addition, this alters the priority list for compilers, with the
following changes:
* Apple GCC 4.2 and LLVM-GCC swap positions, with GCC now taking
priority. (Maybe LLVM-GCC should just go away.)
* Non-Apple GCC compilers are ranked below GCC 4.2 but above LLVM-GCC
and Apple GCC 4.0.
|
|
|
|
|
|
Warn users and point them to `brew postinstall` (which can provide a
backtrace).
Closes #21887.
|
|
Runs post-install jobs in case they failed or need rerun for any reason.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See #21720.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes #22205.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
|
|
Closes #22196.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
|
|
Fixes #22221.
|
|
This unifies the logic for selecting a compiler between superenv and
stdenv. A variation of superenv's `determine_cc`, which now returns a
symbol, has been moved into the shared ENV extension. Stdenv uses the
result of this directly (as it's always used symbols), while superenv
translates that back into a compiler string.
This also has the effect of disabling HOMEBREW_USE_(gcc|llvm|clang) in
stdenv, which have already been marked as deprecated for some time, and
enables the HOMEBREW_CC= environment variable syntax from superenv in
stdenv.
|
|
|
|
Closes #22210.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
|
|
Closes #22138.
|
|
Closes #22202.
|
|
|
|
This allows overriding the "oldest CPU" behaviour - for instance, to
build Intel bottles for a newer CPU than Core 2, to build a PPC bottle
with or without Altivec on the same computer, etc.
|
|
|
|
Otherwiese a `Cellar/.DS_Store` may lead to an error about
`.ds_store.rb` not found during `brew upgrade`.
|
|
An issue could arise when brewing a formula that
has Python 2.x and 3.x support and 2.x is the system Python
but 3.x is a brewed one. The idea about prepending was that
user configured PYTHONPATH could be used in formulae.
Now, instead and if needed, inside the `python do` block
one can still append to PYTHONPATH.
|
|
If `depends_on :python => ['modulename', :optional]` then the generated
option is now `--with-python-modulename`, so that it is possible to
actually make depending on python modules optional.
Further, `brew options` becomes more meaningful.
|
|
|
|
|
|
|
|
|
