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.
Currently we handle options in several ways, and it is hard to remember
what code needs an option string ("--foo"), what needs only the name
("foo") and what needs an Option object.
Now that Option objects can act as strings and be converted to JSON, we
can start using them instead of passing around strings between Formula
objects, Tab objects, and ARGV-style arrays.
The Options class is a special collection that can be queried for the
inclusion of options in any form: '--foo', 'foo', or Option.new("foo").
Simplify access to the different forms of a formula's build options by
making options into real objects rather than strings, and expose both
the 'name' and 'flag' form.