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.

Closes Homebrew/homebrew#22210.

Signed-off-by: Misty De Meo <mistydemeo@gmail.com>

Closes Homebrew/homebrew#22138.

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

On PPC, -mcpu is the preferred equivalent to -march.