There are subtle incompatibilities between Apple's libstdc++ and the
libstdc++ used by the various GNU GCC formulae. In addition, we'll
likely also be supporting libc++ in the future, and that's also
incompatible with the other stdlibs.
Tracking it in the tab lets us make sure that dependencies are all
built against the same stdlib to avoid subtle breakage.
This adds support for non-Apple GCC compilers in the fails_with code.
A fails_with block for a non-Apple compiler looks like:
fails_with :gcc => '4.8.1' do
cause 'Foo'
end
Non-Apple compilers don't have build numbers, so compiler failures are
based on version strings instead.
Internally non-Apple compilers can be distinguished because they are
passed around as strings instead of symbols.
In addition, this alters the priority list for compilers, with the
following changes:
* Apple GCC 4.2 and LLVM-GCC swap positions, with GCC now taking
priority. (Maybe LLVM-GCC should just go away.)
* Non-Apple GCC compilers are ranked below GCC 4.2 but above LLVM-GCC
and Apple GCC 4.0.
Options collections are backed by Sets, and thus trying to push a new
option with a name that duplicates an existing option cannot succeed.
Later, we can exploit this behavior and remove some conditionals.
On Unix, the path separator is ':', whereas on Windows,
it is ';'. This is the first of a series of patch to bring
macbrew's and winbrew's codebases closer together.
The main places the magic constant ':' was being used were:
- the $PATH environment variable
- CMAKE-related environment variables
- pkg-config related environment variables
ClosesHomebrew/homebrew#21921.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
A tapped formula is a ruby file present:
- in the root of the tap
- in directory of the tap called Formula
- in a directory of the tap called HomebrewFormula
And nowhere else. This corrects an overzealous definition of tapped
formula in the updater. (the correct definition has been in Pathname
since e613cbe5783cea2abb8100b56c22126a1ab6b9f2)
Refs Homebrew/homebrew#19743.
ClosesHomebrew/homebrew#21087.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
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.
This hack was necessary since requirements were not checked again
in the forked build process, but now they are, and calling it again
after the build environment has been set up can produce incorrect
results. In fact, if it happens to return false the second time,
the env modification will be skipped altogether.
