This is the pattern we've been adopting for a while and it's a bit
cleaner. Let's remove all of the existing usage of the existing pattern
to avoid confusion when adopting the new one.
- 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
```
- Found with
`grep -rL "# typed: strict" Library/Homebrew | xargs grep -l "undef "`.
- This stops people from trying to bump them and
getting an error that they can't fix because
[it's a Sorbet limitation](https://sorbet.org/docs/error-reference#3008),
wasting contributor time.
Currently the codesign_patched_binary method may be called many
times for the same file when installing a keg.
This removes the calls to codesign_patched_binary from os/mac/keg
and adds a single call to the relocate_dynamic_linkage and
fix_dynamic_linkage methods in extend/os/mac/keg_relocate
to speed up keg installation.
`dyld` uses the target library's install name to work out whether this
is a Framework or a dylib, which affects how `dyld` searches for the
desired library.
We should therefore avoid confusing `dyld` by including the
`*.framework` part of the install name in the target dylib, which is
what this change does.
Here's a concrete example of what this changes. Before:
❯ otool -L /usr/local/bin/python3
/usr/local/bin/python3:
@loader_path/../Python (compatibility version 3.11.0, current version 3.11.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
After:
❯ otool -L /usr/local/bin/python3
/usr/local/bin/python3:
@loader_path/../../../../Python.framework/Versions/3.11/Python (compatibility version 3.11.0, current version 3.11.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
By retaining the `Python.framework` part of the install name, we make
sure that `dyld` knows that it should be looking for a framework rather
than a dylib.
This implements the TODO that I left as a comment from #15722.
In order to simplify the handling of deleting an absolute rpath that has
a relative duplicate (or vice-versa, i.e., a relative rpath with an
absolute duplicate), we relocate all rpaths first in one pass and then
delete the duplicates in a separate pass.
We currently rely on some lower-level (but still public) methods from
ruby-macho since the standard `#delete_rpath` method changes the order
in which rpaths are resolved. We can switch back to using
`#delete_rpath` when Homebrew/ruby-macho#555 is merged and released.
This should fix the failures seen for `julia` in Homebrew/core.[^1]
I've detailed a better/more comprehensive fix as a `TODO` in a comments.
However, the problems that the better fix would avoid are comparatively
unlikely, so I think we can try this one out for now while I work on
implementing the said fix.
[^1]: https://github.com/Homebrew/homebrew-core/pull/135398#issuecomment-1643041541
Doing `change_rpath(old, new, file)` will error if `new` is already an
rpath for `file`. When this happens, `old` is no longer needed, so we
can delete it.
Fixes a build failure at shivammathur/homebrew-php#1848.
Some formulae (e.g. `php`) use rpaths that reference Cellar paths
belonging to other formulae. Let's make sure these rpaths don't break by
making them use opt paths instead.
Stuff built by CMake evades this check because CMake normalises
`/private/tmp` (which is the default `HOMEBREW_TEMP`) to `/tmp`. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23251.
Let's fix that my taking this into account when `HOMEBREW_TEMP` is
`/private/tmp`.
ruby-macho chokes on changing duplicate RPATHs, so we need to strip the
duplicates before trying to relocate them.
This continues #11405. We need this to unblock
Homebrew/homebrew-core#91224.
While we're here, let's get rid of `HOMEBREW_RELOCATE_RPATHS`. We've
been using it for nearly a year with essentially no problems (barring
`pdnsrec`), so I think it is safe to do unconditionally.
Upon reflection, I realised that this is probably a bug in `ruby-macho`,
and should be fixed there instead.
Needs https://github.com/Homebrew/ruby-macho/pull/362.
This reverts commit e8b5eb7e42c925b7cc10c78a029b8c70e4d7965b.
Java-dependent formulae produce different bottles on macOS and Linux
because they have different values for `JAVA_HOME` (`opt_libexec` vs
`opt_libexec/"openjdk.jdk/Contents/Home"`).
Let's handle this difference by using the placeholder
`@@HOMEBREW_JAVA@@` in a bottle, like so:
#!/bin/bash
JAVA_HOME="${JAVA_HOME:-@@HOMEBREW_JAVA@@}" exec "@@HOMEBREW_CELLAR@@/clojure/1.10.3.998/libexec/bin/clojure" "$@"
While this should never be necessary for per-OS bottles, this could be useful for :all bottles where the OS it was built on uses a Perl version that doesn't exist on all macOS versions.
Homebrew/homebrew-core#77623 revealed two bugs. One in `ruby-macho`,
which turns out to be unable to delete duplicated `RPATH`s. This was
fixed with `ruby-macho` 2.5.1.
The second, which this commit fixes, is in our handling of duplicate
`RPATH`s. Since we iterate over each `RPATH`, attempting to relocate the
first duplicate fails since it will no longer exist after having
relocated the original.
Running `brew bottle` changes dylib IDs, install names, and rpaths into
placeholders for the bottle, creates a bottle tarball, and then changes
the placeholders back to their correct values.
With my refactoring in #11358, the behaviour of this relocation changed:
dylib IDs would no longer be changed back from placeholders into their
correct values after the creation of the bottle tarball.
- remove usage on macOS as we don't care about it there
- don't error out on incompatibility but still store stdlib on Linux
- remove (now) unused methods
