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.
Dependency names retain the "tap prefix", e.g. the "homebrew/dupes"
part of "homebrew/dupes/zlib". However formula objects do not, and this
is desired because we do not record the tap name as part of the
installation prefix.
So we need to ensure the correct dep names are passed to superenv,
otherwise it will not add the correct directories to various environment
variables.
Given the current state of OS X compilers, the original fails_with
behavior is becoming less useful, mostly resulting in build failures
each time the compiler is updated. So make the following changes:
When a build is specified, we retain the old behavior: switch compilers
if the available compiler is <= the build, don't switch if it is > the
build.
When no build is specified, unconditionally switch compilers, and don't
output the advice message. This allows us to mark formulae as
perpetually failing, avoiding the need to update formulae each time a
new compiler build is made available.
As a bonus, this makes the logic much easier to reason about.
ClosesHomebrew/homebrew#18175.
Given the following dependency tree:
foo
bar (bottled)
baz (build-time only)
We skip installing baz because it is a build-time dependency of
something that is bottled. However, during the build of foo, this filter
is not applied because the dependent-dep relationship is not considered
at this stage. If baz wasn't installed prior to this build, fixopt(baz)
will fail.
Further, build-time deps are tightly coupled to the formula they are
specified by, and we shouldn't rely on them coming from dependencies
several levels down.
FixesHomebrew/homebrew#17697.
