- Avoid near duplicate messages
- Provide correct CLT download instructions
Before:
```
$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: Your Command Line Tools are too outdated.
Update them from Software Update in System Settings.
If that doesn't show you any updates, run:
sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install
Alternatively, manually download them from:
https://developer.apple.com/download/all/.
You should download the Command Line Tools for Xcode 16.0.
Warning: A newer Command Line Tools release is available.
Update them from Software Update in System Settings.
If that doesn't show you any updates, run:
sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install
Alternatively, manually download them from:
https://developer.apple.com/download/all/.
You should download the Command Line Tools for Xcode 16.0.
Warning: Your Xcode (15.4) at /Applications/Xcode.app is too outdated.
Please update to Xcode 16.0 (or delete it).
Xcode can be updated from:
https://developer.apple.com/download/all/
Warning: Your Xcode (15.4) is outdated.
Please update to Xcode 16.0 (or delete it).
Xcode can be updated from:
https://developer.apple.com/download/all/
If 16.0 is installed, you may need to:
sudo xcode-select --switch /Applications/Xcode.app
Current developer directory is:
/Applications/Xcode.app/Contents/Developer
```
After:
```console
$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: Your Command Line Tools are too outdated.
Install the Command Line Tools for Xcode 16 from:
https://developer.apple.com/download/all/
Warning: Your Xcode (15.4) at /Applications/Xcode.app is too outdated.
Please update to Xcode 16.0 (or delete it).
Xcode can be updated from:
https://developer.apple.com/download/all/
```
- 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
```
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.
This is just a recipe for infinite loops. Plus, recursive references are
likely to be invalid, so we don't really gain much by attempting to
resolve them.[^1] (But we could if we made the logic here much more
complicated.)
Fixes a CI failure seen at Homebrew/homebrew-core#138323.
[^1]: See, for example, embree/embree#455.
We can add a small amount of logic to `#resolve_variable_name` that will
allow us to perform (limited) resolution of rpath references. This is
for informational purposes only: failing to resolve an `@rpath`
reference will not (and should not) result in `brew linkage` failures.
`dyld` will typically have more information than we do to resolve these
references, so not failing `brew linkage` when we fail to resolve an
`@rpath` reference is the right behaviour here.
As an example, before:
❯ brew linkage jpeg-turbo
System libraries:
/usr/lib/libSystem.B.dylib
@rpath-referenced libraries:
@rpath/libjpeg.8.dylib
@rpath/libturbojpeg.0.dylib
After:
❯ brew linkage jpeg-turbo
System libraries:
/usr/lib/libSystem.B.dylib
Homebrew libraries:
/usr/local/Cellar/jpeg-turbo/3.0.0/lib/libjpeg.8.dylib (jpeg-turbo)
/usr/local/Cellar/jpeg-turbo/3.0.0/lib/libturbojpeg.0.dylib (jpeg-turbo)
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.
