Copy these files/folders to a .bottle directory under the Cellar for installation
elsewhere at pouring time.
Temporarily disable HOMEBREW_GIT_ETC methods until fixed.
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.
* When a versioned keg_only formula installs the same set of executables
or libraries as a unversioned formula that links to $HOMEBREW_PREFIX,
install_name_tool will prefer to use the linked paths for files in
keg_only formula. This breaks software that should link to the
keg_only formula but links to the unversioned one instead.
* Add an additional "options" parameter with keg_only field to specify
the correct install path for keg_only formulae.
Still in alpha state.
Handles defaults and merging changes with new versions.
Enable by setting the HOMEBREW_GIT_ETC environment variable.
ClosesHomebrew/homebrew#15751.
ClosesHomebrew/homebrew#17713.
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.
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.
An "optional build-time dep" is unlikely, but possible, and I happen to
notice this wasn't handled correctly while digging around in the deps
code over the last few days.
It doesn't really make logical sense that this method returns both the
fetched path (or sometimes nil!) and the downloader, so just return the
path (again, or nil!) and callers that want the downloader can ask for
it separately.
