The OpenStruct initializer accepts both symbols and strings, but any
nested hashes will only allow access via string keys, so let's always
construct the object with strings for consistency.
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.
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.
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.
Will this break anything? It shouldn't; Formula will always be loaded
before Tab anyway. But really there is a design problem here, Tab
shouldn't have any hardcoded references to Formula. I think this is
fixable, but callers of for_formula will need to be checked first.
- Store in the tab if a bottle was poured for the build.
- Add an additional line of output to `brew info` outputting whether
the formula was built from source or poured from a bottle.
ClosesHomebrew/homebrew#18430.
ClosesHomebrew/homebrew#18475.
The array of options that is passed to the spawned build process is a
combination of the current ARGV, options passed in by a dependent
formula, and an existing install receipt. The objects that are
interacting here each expect the resulting collection to have certain
properties, and the expectations are not consistent.
Clear up this confusing mess by only dealing with Options collections.
This keeps our representation of options uniform across the codebase.
We can remove BuildOptions dependency on HomebrewArgvExtension, which
allows us to pass any Array-like collection to Tab.create. The only
other site inside of FormulaInstaller that uses the array is the #exec
call, and there it is splatted and thus we can substitute our Options
collection there as well.
