- 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 Homebrew/homebrew#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 Homebrew/homebrew#21887.

Runs post-install jobs in case they failed or need rerun for any reason.

See Homebrew/homebrew#21720.

Closes Homebrew/homebrew#22205.

Signed-off-by: Adam Vandenberg <flangy@gmail.com>

Closes Homebrew/homebrew#22196.

Signed-off-by: Adam Vandenberg <flangy@gmail.com>

Fixes Homebrew/homebrew#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.