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.
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.
Move Formula.expand_dependencies into the Dependency class, and extend
it to allow arbitrary filters to be applied when enumerating deps.
When supplied with a block, expand_dependencies will yield a [dependent,
dependency] pair for each dependency, allowing callers to filter out
dependencies that may not be applicable or useful in a given situation.
Deps can be skipped by simple calling Dependency.prune in the block,
e.g.:
Dependency.expand_dependencies do |f, dep|
Dependency.prune if dep.to_formula.installed?
end
The return value of the method is the filtered list.
If no block is supplied, a default filter that omits optional or
recommended deps based on what the dependent formula has requested is
applied.
Formula#recursive_dependencies is now implemented on top of this,
allowing FormulaInstaller to exact detailed control over what deps are
installed. `brew missing` and `brew upgrade` can learn to use this to
apply the installed options set when expanding dependencies.
Move Formula.expand_deps and Formula#recursive_deps into compat, because
these methods do not respect the new optional and recommended tags and
thus should no longer be used.
When a requirement is specified like:
satisfy { which "foo" }
There is no reason that we should inject all of ENV.userpaths! into the
build environment. Instead, infer the directory to be added to PATH from
the Pathname that is returned.
This is another step towards condensing the "which program" requirements
down into a one-liner DSL element.
Instead of overriding #satisfied?, Requirement subclasses can specify
the condition in a block:
satisfy do
some_condition?
end
The contents of the block are evaluated in the context of the instance,
and so have access to instance variables and instance methods as before.
Additionally, it is wrapped in an ENV.with_build_environment block. This
can be disabled by passing :build_env => false to satisfy:
satisfy :build_env => false do
some_condition?
end
Not thread safe! But I don't think we care.
We want to evaluate the env DSL block in the context of ENV for asthetic
reasons, but we also want access to methods on the requirement instance.
We can use #instance_exec to pass the requirement itself into the block:
class Foo < Requirement
env do |req|
append 'PATH', req.some_path
end
def some_path
which 'something'
end
end
Also add a simplified version of Object#instance_exec for Ruby 1.8.6.
It is important that dep equality corresponds to the name attribute, but
we may want to use the Comparable interface to sort them by installation
order in the future. Code that needs to sort them alphabetically should
just use sort_by.
* Detect `latex' and `bibtex' commands.
* Recommend installing MacTeX when no LaTeX installation is found.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
Inheriting from Array (and other core types) is problematic:
- It exposes a very wide interface with many methods that are not
really relevant to the subclass.
- It can cause some weird side effects, as many Array operations are
in C and have hardcoded return values; for example, combining two
array subclasses returns a new Array instead of the subclass.
Avoid these problems using delegation and the Enumerable module where
applicable.
To allow
depends_on :x11 => :optional
and friends to work as expected, make requirements record any tags and
add special handling to the X11Dependency to record both a minimum
version and additional tags.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
ComparableSet only allows a single object of a given class,
choosing the object with the greatest value. This was mainly created
for Requirements, so that, e.g., two X11Dependencies of differing
strictness don't both end up in the same requirement set.
FixesHomebrew/homebrew#15240.
Clarify the error message arising from XCodeDependency so that users know
XCode.app is needed and that just installing the CLT does not count as
"installing XCode".
XQuartz isn't added to the default library paths so if something is
linked against a Homebrew libpng then it doesn't work against the
XQuartz libpng. The CLT provides X11 on Lion so don't request users
install XQuartz if it isn't needed on Mountain Lion.
FixesHomebrew/homebrew#14325.
Currently FormulaInstaller "forgets" about the requirements of
dependencies, as dependencies are recursively expanded by the first
FormulaInstaller instance, and then ignored by subsequent instances to
prevent duplicate installation attempts. These requirements then have
their messages displayed, but the fatal check is skipped and thus no
exception is raised.
Now that we have Formula#recursive_requirements, we can mirror what we
are doing with dependencies and recursively expand requirements up
front.
While at it, fix a bug in determining Requirement equality that resulted
in unique requirements being eliminated from a formula's set of
recursive requirements.
FixesHomebrew/homebrew#12290.
FixesHomebrew/homebrew#14084.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
In order to better support Xcode-only systems, where X11 libs and
executables live under /usr/X11 but headers live in the SDK, move the
x11_* helper methods into a new module.
This allows us to keep some of the CLT/Xcode-only and Apple X11/XQuartz
logic hidden from outside code, like ENV.x11.
Since Apple's X11 is actually XQuartz, name the module "MacOS::XQuartz".
conflicts_with is a thin wrapper around Requirement which simplifies
marking conflicts between formulae.
ClosesHomebrew/homebrew#13687.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
