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.
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.
This sets cpp to use the compiler as cpp, and works with scripts which
pass values to cpp on stdin as well as with file arguments.
ClosesHomebrew/homebrew#22155.
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.
When a formula `depends_on :python` *and* `depends_on :python3`
the `modify_build_environment` method sets the PYTHONPATH
and the Python 3.x requirement then fails because it finds
the sitecustomize.py from Python 2.x in the PYTHONPATH.
Options collections are backed by Sets, and thus trying to push a new
option with a name that duplicates an existing option cannot succeed.
Later, we can exploit this behavior and remove some conditionals.
... and not just installed ones. Of course, strictly speaking,
reinstalling not-yet-installed formulae makes semantically little
sense, but the big win is that we can tell people (after we have
resolved an issue) to `brew reinstall <formula>` and even if a user
has removed that formula in the meantime, reinstall will do the right
thing. Basically adding --force to uninstall. I think this makes
reinstall more robust.
... and not just installed ones. Of course, strictly speaking,
reinstalling not-yet-installed formulae makes semantically little
sense, but the big win is that we can tell people (after we have
resolved an issue) to `brew reinstall <formula>` and even if a user
has removed that formula in the meantime, reinstall will do the right
thing. Basically adding --force to uninstall. I think this makes
reinstall more robust.
