This behaves like recursive_deps, but the resulting list consists of
Dependency objects instead of Formula objects. The list maintains the
installable order property of recursive_deps.

While in the area, add some comments clarifying the purpose of related
methods.

Eventually a common interface could be factored out into a module, but
for now this will suffice.

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").

We want to be able to use Option objects in place of strings and have
this be transparent. Defining to_str means that methods like
Kernel#system and Kernel#exec will be able to perform an implicit
conversion.

Closes Homebrew/homebrew#14359.

References Homebrew/homebrew#13951.

Superenv normally filters out "-m32" flag, preventing 32bit builds.
Some software, however, still only work in 32bit mode.

If ENV.m32 is called, superenv does not filter out the "-m32" flag.
Also note, superenv, does not explicitly add the -m32 flag and
expects the build system of the software to know when and where to
provide this flag.

Closes Homebrew/homebrew#16350.

Signed-off-by: Adam Vandenberg <flangy@gmail.com>

Closes Homebrew/homebrew#16607.

Closes Homebrew/homebrew#17267.

Signed-off-by: Adam Vandenberg <flangy@gmail.com>

Closes Homebrew/homebrew#16457.

We already (correctly) allow -Wl, style linker arguments to pass
through; extend this to -Wp, (preprocessor) and -Wa, (assembler).

Fixes Homebrew/homebrew#17252.

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.

To match the recent renaming of that wiki article.

Closes Homebrew/homebrew#17249.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>

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.

In addition to

  env :userpaths
  env :std

requirements can now do

  env do
    append 'PATH', '/some/path/to/bin'
    # and more
  end