While it may suffice to merge string and non-reserved tags by forming a
union of all tags of dependencies of the same name, this approach fails
to work for the reserved tags. These are now merged such that the most
restrictive tag (meaning sometimes an empty tag) is preserved.
The previous behavior caused essential dependencies to be omitted and
builds to fail in response. E.g., multiple `:fortran` dependencies with
tags `[]`, `[:recommended]`, and `[:optional]` would have been expanded
and merged to `"gcc"` with tags `[:recommended, :optional]`, causing it
to be no longer seen as a required dependency.
ClosesHomebrew/homebrew#47040.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
The general idea is that merging multiple dependencies of the same name
should produce the strictest tag instead of a (meaningless) union of the
reserved tags. For example, if a dependency is both a `:recommended` and
an `:optional` dependency at different points in the dependency tree,
the resulting merged dependency should be tagged as `:recommended`.
Handle all other reserved tags in the same spirit.
This means that dependencies can be merged but still maintain all
their option names.
ClosesHomebrew/homebrew#46916.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
By always passing around a single, unnested array rather than splatting
and then defensively flattening and compacting things, we can avoid
allocating a bunch of unnecessary arrays. This gives a performance boost
of roughly 4% when enumerating 2500 formulae, and has the side effect of
cleaning up the dependency API.
Formulae can now pass build options to dependencies. The following
syntax is supported:
depends_on 'foo' => 'with-bar'
depends_on 'foo' => ['with-bar', 'with-baz']
If a dependency is already installed but lacks the required build
options, an exception is raised. Eventually we may be able to just stash
the existing keg and reinstall it with the combined set of used_options
and passed options, but enabling that is left for another day.
The DependencyCollector tests are really integration tests, while the
rest are closer to real unit tests. Split them up so that the tests can
be run in isolation on a per-class basis.
