- Previously I thought that comments were fine to discourage people from
wasting their time trying to bump things that used `undef` that Sorbet
didn't support. But RuboCop is better at this since it'll complain if
the comments are unnecessary.
- Suggested in https://github.com/Homebrew/brew/pull/18018#issuecomment-2283369501.
- I've gone for a mixture of `rubocop:disable` for the files that can't
be `typed: strict` (use of undef, required before everything else, etc)
and `rubocop:todo` for everything else that should be tried to make
strictly typed. There's no functional difference between the two as
`rubocop:todo` is `rubocop:disable` with a different name.
- And I entirely disabled the cop for the docs/ directory since
`typed: strict` isn't going to gain us anything for some Markdown
linting config files.
- This means that now it's easier to track what needs to be done rather
than relying on checklists of files in our big Sorbet issue:
```shell
$ git grep 'typed: true # rubocop:todo Sorbet/StrictSigil' | wc -l
268
```
- And this is confirmed working for new files:
```shell
$ git status
On branch use-rubocop-for-sorbet-strict-sigils
Untracked files:
(use "git add <file>..." to include in what will be committed)
Library/Homebrew/bad.rb
Library/Homebrew/good.rb
nothing added to commit but untracked files present (use "git add" to track)
$ brew style
Offenses:
bad.rb:1:1: C: Sorbet/StrictSigil: Sorbet sigil should be at least strict got true.
^^^^^^^^^^^^^
1340 files inspected, 1 offense detected
```
When Homebrew/homebrew-core#107517 is merged, builds will no longer be
able to find `python@3.9` as `python3`. This is also what is likely to
happen to `python@3.10` when we add a `python@3.11`.
This is likely to break many builds, so let's make sure they can keep
finding a `python3` for formulae that don't have a dependency on the
latest Python3.
This is arguably something we should've done earlier: it also means that
builds that go looking for an unversioned `python` end up finding our
Python3 (whenever present in the build environment) instead of, say,
`/usr/bin/python` which is typically Python2.
This adds GCC's runtime lib directory to the RPATH of every build on
Linux (unconditionally!).
This is useful for three things:
1. It fixes versioned GCC linkage for formulae that users build from
source instead of pouring from a bottle. We currently only handle
bottle installs. See #13633.
2. It helps minimise the GCC dependency explosion. When a formula has a
Linux-only GCC dependency, then all its dependents that link with
some GCC runtime library (typically `libstdc++`) must, before this
change, also adopt a GCC dependency. This is a consequence of our
injecting GCC's runtime library directory into RPATH only when a
formula is built with GCC (this is done through the specs file). We
can avoid the need to do this by always injecting this path instead.
3. This enables us to automatically install Homebrew GCC whenever the
user's GCC is too old and the formula may need it. Without this
change, auto-installing GCC is not that useful because formulae that
need it may not know to look for our GCC, unless the formula already
happened to be built with our GCC. With this change, these formulae
will always be able to find our GCC when it is installed. This is
particularly useful for when we start building with a version of GCC
that is much closer to the latest than we currently do.
This approach comes with at least two drawbacks:
1. We will see spurious linkage warnings in CI about an undeclared
dependency with linkage as soon as Homebrew GCC is installed, because
formulae will link with our GCC instead of the host's. Users will
also see a similar complaint if they do `brew linkage`.
2. This leans _very_ heavily on GCC delivering backward compatibility of
their runtime libraries. If they do not, we could see different
behaviour across different CI runs for the same formula depending on
whether Homebrew GCC is installed.
It's worth noting that item 3 in the "useful" list above may rely on
features not yet implement in `brew`.
Bison no longer remembers the path to `m4` as of
Homebrew/homebrew-core#84931. Since superenv does not put runtime
dependencies of build dependences in `PATH`, we now need to help Bison
find `m4` by setting `M4` in the environment.
See also Homebrew/homebrew-core#85260.
- This also required auto-fixes for Layout/EmptyLinesAroundBlockBody and
Layout/InconsistentIndentation once the auto-fixer had got rid of the
"redundant begin"s.
`-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.
- atomic_write: close file before renaming to prevent error:
'Device or resource busy'
- ensure_writable: preserve executable bit
- new elf? and dynamic? methods
