This is used to indicate a formula is a version of another formula.
This will be used to provide a consistent interface for older formulae
versions and replaces the use of `conflicts_with`.
Not quite a mass replacement as I've used OS X and Mac OS X where
describing specific older versions and added compatibility methods
for things in the DSL.
`Formula#keg_only?` could fail if it was invoked on a formula with a
`:provided_until_xcode43` or `:provided_until_xcode5` reason given to
`keg_only`, if neither the Command Line Tools nor Xcode was installed.
Check whether Xcode is installed before querying the Xcode version.
Closes#317.
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.
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.
ClosesHomebrew/homebrew#18374.
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.
While at it, make it use class methods instead; no reason to instantiate
an object for this.
Eventually there should be some functional tests for the individual
strategies as well.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
