This can happen on e.g. fossil where the dependency HEAD requires having
an install of fossil in order to check it out. Bit of a silly edge case
but this handles it.
FixesHomebrew/homebrew#25605
When decided what dependencies should be part of the build environment
(and have appropriate entries added to variables like PKG_CONFIG_PATH),
we select the entire dependency tree except for
(1) inactive optional and recommended deps (2) indirect build-time deps
(i.e., build-time deps of other deps)
There is a third category that sould be excluded: dependencies of direct
build-time deps. These are irrelevant to the build, and including them
can cause unexpected linkages.
When an exception is raised in the build process, it is marshaled and
sent to the main process over a pipe. The marshaled exception has
a reference to the formula, so the formula and all objects it references
are marshaled as well.
Previously this did not include dependencies, as they were stored only
on the class and not referenced by an instance variable. However, now
they are stored on SoftwareSpec instances, to which the formula *does*
have a direct reference, so they must be marshalable.
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.
When expanding dependencies, repeated deps are treated as equal and all
but the first are discarded when #uniq is called on the resulting array.
However, they may have different sets of options attached, so we cannot
assume they are the same.
After the initial expansion, we group them by name and then create a new
Dependency object for each name, merging the options from each group.
FixesHomebrew/homebrew#20335.
New `depends_on :python` Dependency.
New `depends_on :python3` Dependency.
To avoid having multiple formulae with endings -py2 and -py3,
we will handle support for different pythons (2.x vs. 3.x)
in the same formula.
Further brewed vs. external python will be transparently supported.
The formula also gets a new object `python`, which is false if
no Python is available or the user has disabled it. Otherwise
it is defined and provides several support methods:
python.site_packages # the site-packages in the formula's Cellar
python.global_site_packages
python.binary # the full path to the python binary
python.prefix
python.version
python.version.major
python.version.minor
python.xy # => e.g. "python2.7"
python.incdir # includes of python
python.libdir # the python dylib library
python.pkg_config_path # used internally by brew
python.from_osx?
python.framework?
python.universal?
python.pypy?
python.standard_caveats # Text to set PYTHONPATH for python.from_osx?
python.if3then3 # => "" for 2.x and to "3" for 3.x.
Further, to avoid code duplication, `python` takes an optional
block that is run twice if the formula defines depends_on
:python AND :python3.
python do
system python, 'setup.py', "--prefix=#{prefix}"
end
Read more in the Homebrew wiki.
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.
