| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Instead we use which with a custom PATH.
|
|
|
|
The implementation of #eql? and #hash should ensure that if a.eql?(b),
then a.hash == b.hash, but #eql? itself should not *depend* on #hash.
For example, given
class Thingy
def eql?
instance_of?(other.class) && hash == other.hash
end
def hash
[name, *tags].hash
end
end
if #hash produces a collision for different values of [name, *tags], two
Thingy objects will appear to be eql?, even though this is not the case.
Instead, #eql? should depend on the equality of name and tags directly.
|
|
|
|
This hack was necessary since requirements were not checked again
in the forked build process, but now they are, and calling it again
after the build environment has been set up can produce incorrect
results. In fact, if it happens to return false the second time,
the env modification will be skipped altogether.
|
|
|
|
Closes #20239.
|
|
Fixes #19857.
|
|
|
|
|
|
This allows default resolution of requirements without user intervention.
Closes #19627.
|
|
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.
|
|
This was meant to support:
env do |req|
append_path 'PATH', req.some_method
...
end
i.e., the block was evaluated in the context of ENV. But it turned out
to be not so useful after all, so I'm ripping it out before something
actually depends on it.
|
|
|
|
The name attribute of requirements is used when generating options for
the :optional and :recommended dependency tags.
Unless otherwise specified, the name attribute of a Requirement will be
populated by stripping any module prefixes from the beginning and
"Dependency" or "Requirement" from end of the class name and downcasing
the result.
Closes #17759.
|
|
|
|
Expand requirements recursively while applying the same optional? and
recommended? filters that dependencies are run through. Options
generated by requirements are now checked against the correct list of
requirements, eliminating the temporary "best guess" logic in the
installer.
|
|
When a formula's dependency tree contains more than one X11 dependency,
they are de-duplicated by comparing the min_version attribute. However,
this can result in broken dependency trees if one of the X11Dependency
objects was actually specified as e.g. `:libpng`.
In practice, this only matters when one or more of the dependencies has
additional metadata that makes it distinct from the rest, i.e. an
:optional or :recommended tag.
To combat this, make these special, "partial" X11 dependencies instances
of different classes so that they are not de-duped.
It will still be necessary, at the time when requirements are expanded
by the installer, to de-duplicate any remaining X11 dependencies after
applying the optional/recommended filters in order to avoid duplicated
modifications to the environment (as ENV.x11 is not idempotent).
c.f. #17369.
|
|
|
|
|
