Declarations of dependencies, options, and resources in the DSL only
apply to specs that have already been initialized. For example, given
this snippet:
url ...
sha1 ...
depends_on 'foo'
devel do
url ...
sha1 ...
end
The dependency 'foo' will be recorded for the stable spec, but not the
devel spec, since it was not initialized prior to the call to
depends_on.
While it is considered best practice to declare all specs (stable,
devel, head, and bottle) prior to other declarations, there is nothing
that enforces this ordering, so when it happens it can be confusing and
hard to debug.
To prevent this, we can initialize all specs up front. This comes with
a performance penalty for commands that load all formulae into memory,
but that is probably outweighed by what we gain in correctness.
FixesHomebrew/homebrew#23425.
Comparing two objects should not raise an exception, even if they have
different types.
The semantics of #== are now the same as #eql?, so make one an alias.
When subformulae are initialized without a name parameter, Homebrew
assigns the name "__UNKNOWN__". This may cause collisions in the cache.
Currently CurlDownloadStrategy and its descendants handles this by
extracting the basename form the URL and using that as the cached
filename. However, other strategies simply raise an exception.
We can improve the other strategies by URL-encoding the URL string and
using that as the cached directory name.
Note that this happens very rarely, especially now that resources (which
always have a name) are preferred to subformulae. The most common case
is a subformula that specifies a head download.
ClosesHomebrew/homebrew#22949.
When DownloadStrategyDetector.detect is given a second argument, and
that argument is not a symbol or an AbstractDownloadStrategy subclass,
it is silently ignored, and we fall back to guessing the strategy based
on the URL.
This means I can do
url 'http://foo.com/bar.tar.gz', :using => Class.new
and things will appear to work, even though I have clearly passed an
invalid value for :using.
A more useful behavior is to raise an exception for unknown strategy
specifications.
Still in alpha state.
Handles defaults and merging changes with new versions.
Enable by setting the HOMEBREW_GIT_ETC environment variable.
ClosesHomebrew/homebrew#15751.
ClosesHomebrew/homebrew#17713.
Allow `build.with?` and similar methods to be used during the test
phase. The BuildOptions (`build`) are initialized with the
`Tab.used_options` unless explicitly overwritten on the command line.
So basically `build.with?` works in `def install` and in `test do` as
one would naively expect. (For the test, gramatically it should be
`built.with?` but who cares)
If a formula was installed `--with-python`, now the tests are also
run `--with-python`. This enables us to use the `python do ... end` in
a meaningful manner.
Using `python do ... end` blocks for the tests, because the bot.brew.sh has
system python per default and we need to set the PYTHONPATH for the test.
Potentially to different values for Python 2.x and 3.x.
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.
