| Age | Commit message (Collapse) | Author |
|---|
|
* CPU functions now exist in Hardware::CPU
* Added compatibility functions in compat/hardware_compat.rb
* Names are less specific to Mac hardware, e.g. CPU.family instead of
Hardware.intel_family
* Hardware::CPU.family works for both Intel and PowerPC
* New helper methods on CPU, like .sse4? and .altivec?
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
|
|
Reader methods for specific checksum types have been absent from the
Formula class for some time, so there isn't any reason to expose them in
SoftwareSpec, either.
Thus, these methods now only act as setters, and #checksum should be
used to access the constructed Checksum object.
|
|
|
|
The existing case-statement with nested if-statements is gross and hard
to extend. Replacing it with a priority queue simplifies the logic and
makes it very easy to add new compilers to the fails_with system, which
we will likely want to do in the future.
|
|
Given the current state of OS X compilers, the original fails_with
behavior is becoming less useful, mostly resulting in build failures
each time the compiler is updated. So make the following changes:
When a build is specified, we retain the old behavior: switch compilers
if the available compiler is <= the build, don't switch if it is > the
build.
When no build is specified, unconditionally switch compilers, and don't
output the advice message. This allows us to mark formulae as
perpetually failing, avoiding the need to update formulae each time a
new compiler build is made available.
As a bonus, this makes the logic much easier to reason about.
Closes Homebrew/homebrew#18175.
|
|
This has two parts:
1. Bottles are temporarily relocated on bottling and tested if that is
sufficient for them to contain no longer reference the prefix or
cellar. If so, they are marked as relocatable.
2. On installation if bottles are marked as relocatable they will be
relocated using install_name_tool to the current prefix and cellar.
Closes Homebrew/homebrew#18374.
|
|
Closes Homebrew/homebrew#16344.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
|
|
Closes Homebrew/homebrew#18371.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
|
|
This makes it easy to test things that vary depending on this constant
without editing testing_env.rb.
|
|
|
|
|
|
Closes Homebrew/homebrew#17735.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
|
|
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
|
|
* Remove legacy url syntax.
* Use revision instead of version.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
|
|
|
|
|
|
|
|
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 Homebrew/homebrew#17759.
|
|
|
|
The :libtool dep is implicitly a build-time dep; :libltdl can be used
for software that uses the ltdl library at runtime.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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. Homebrew/homebrew#17369.
|
|
Closes Homebrew/homebrew#17317.
|
|
|
|
Fixes Homebrew/homebrew#17434.
|
|
Closes Homebrew/homebrew#14270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This way they can be skipped when installing bottles.
|
|
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.
|
|
Optional deps are not installed by default but generate a corresponding
"with-foo" option for the formula. Recommended deps _are_ installed by
default, and generate a corresponding "without-foo" option.
|
|
|
|
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").
|
|
|
|
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
|
