When Mojave was in beta we made it so that High Sierra bottles would
automatically be used on Mojave. Let's make this the default in general:
older bottles will be used on newer versions of macOS when a newer
bottle is not available.
This should make it easier for taps to bottle single versions of bottles
which will work more widely and to give us breathing room whenever a new
version of macOS is released.
Currently this only applies to the `wine` formula which will have the
`or_later` removed in a Homebrew/homebrew-core PR.
Question: should we use an `odeprecated` for the use of `or_later`?
Fix the error:
Error: wrong number of arguments (given 1, expected 2)
/projects/btl_scratch/sjackman/brew/Homebrew/Library/Homebrew/exceptions.rb:550:in `block in initialize'
/projects/btl_scratch/sjackman/brew/Homebrew/Library/Homebrew/exceptions.rb:559:in `map'
Java, XQuartz and the CLT separate header package aren't required for
everyone's Homebrew usage or a default macOS development install.
As a result, only show then in `brew config` when they are actually
installed.
Use the environment variables set by `brew test-bot`. Eventually we'll
disable Travis CI running CodeCov so move `TRAVIS` references to
`HOMEBREW_TRAVIS_CI` so it doesn't need whitelisted.
Also, fix `azure-pipelines.yml` so it's testing the correct version of
Homebrew/brew (the one checked out in the `pwd`).
Rather than having to manually keep track of what version each thing in
here is and copy files around by hand on update let's use Bundler's
standalone mode and careful use of `.gitignore` to help us do it.
This means a `bundle update --standalone` will allow us to update all
gems in vendor.
We could consider vendoring other gems this way in future but I'd
suggest only doing this for gems with no dependencies or at least gems
with no native extensions. The only gem this applies to that we
currently use is `ruby-prof` and I'm not convinced it's widely used
enough to warrant vendoring for everyone. Perhaps that's another
criteria: it should be functionality that's used by non-developer
commands and/or normal Homebrew usage.
Unlike macOS, Linux installations can be installed/deployed on a
variety of hardware. The HOMEBREW_ARCH environment variable
allows the end user to set a custom -march=... option for the
compiler. If the variable is not set, it defaults to "native".
This only applies on Linux; on macOS, behavior remains unchanged.
Adjust the rules based on the current codebase. Remove various enable,
disables and default values that are unnecessary. Add more comments
explaining why. Make minor changes needed to enable a few more rules.
Use 124 max line length everywhere. Also, reduce tap max line length to
189 as Homebrew/homebrew-core has that as a maximum now. In future
Homebrew/homebrew-core will also be reduced to 124 maximum line length.
`-Os` produces sometimes bigger binaries on Linux.
Also, llvm built with `-Os` is really slow at runtime for Linux.
Using `-02` aligns us with what Debian does, and as we are compiling most of our stuff with gcc (and not clang), it makes sense to use `-02` on Linux.
`-Os` does probably slightly different things when used on mac with llvm, compared to when it is used with gcc on Linux.
