Since the Tab is written in the build process, the formula's build
object will have the correct args attached to it already, so we don't
need to reconstruct it.
Symlinks in opt and LinkedKegs point directly at a keg in the cellar, so
only resolving one symlink should suffice, and make it clear what path
we are actually interested in.
When decided what dependencies should be part of the build environment
(and have appropriate entries added to variables like PKG_CONFIG_PATH),
we select the entire dependency tree except for
(1) inactive optional and recommended deps (2) indirect build-time deps
(i.e., build-time deps of other deps)
There is a third category that sould be excluded: dependencies of direct
build-time deps. These are irrelevant to the build, and including them
can cause unexpected linkages.
This moves stdlib tracking after the install completes, which allows
the tracking to have access to the actual stdlib in use.
This unfortunately means that builds can error out *after* a build,
resulting in wasted time; however, it reduces false positives, and the
overall user experience is still likely to be better this way.
After a formula is built, scan all mach-o files for dynamic links
to see if any of them point to a C++ stdlib (libc++ or libstdc++).
If one of them is linked, record that information in the formula's tab.
This replaces the old behaviour where all files were assumed to be C++
code, and stdlibs were always tracked regardless of whether they were
actually linked against.
This also modifies the way that tabs are written - now tabs are written
with the stdlib field null, and values are only written if an stdlib
is detected.
This moves the CompilerSelector fails_with logic into the build
environment setup, making the compiler selection available before
performing actions that depends on knowing what the compiler is, e.g.
setting up PATH.
ENV.setup_build_environment now optionally takes a Formula argument
to provide the information necessary to do the fails_with, and the new
ENV.validate_cc! extracts the fails_with logic from Build.install.
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.
