Handle macOS Homebrew on ARM#9117
Handle macOS Homebrew on ARM#9117MikeMcQuaid merged 3 commits intoHomebrew:masterfrom MikeMcQuaid:handle-arm
Conversation
MikeMcQuaid
requested review from
a team,
Bo98,
claui,
fxcoudert and
mistydemeo
- Output `brew doctor` and `brew install` messages noting this configuration is (currently) unsupported and encourage use of Rosetta instead - Output Rosetta 2 usage in `brew config` on ARM (whether in Rosetta 2 or not) - Check the architecture of (newly installed) dependencies and ensure they are using the correct architecture. - Don't allow installing macOS Intel Homebrew in macOS ARM Homebrew default prefix (and vice versa - Actually write out the architecture of dependencies to the tab rather than generating and throwing them away - Set and document the expected default prefix for macOS Intel Homebrew, macOS ARM Homebrew (`/opt/homebrew`) and Homebrew on Linux While we're here: - Don't say Big Sur is a prerelease version but still make it clear we don't support it (yet). - Don't reference non-existent IRC channel
Bo98
left a comment
Bo98
left a comment
There was a problem hiding this comment.
(I've not tested the FormulaInstaller changes yet.)
Library/Homebrew/install.rb
Outdated
| elsif Hardware::CPU.arm? && HOMEBREW_PREFIX == HOMEBREW_DEFAULT_PREFIX | ||
| odie "Cannot install in Homebrew on ARM processor in Intel default prefix (#{HOMEBREW_PREFIX})!" |
There was a problem hiding this comment.
How do existing DTK users migrate? This error will appear for everyone who has tested ARM so far so it perhaps would be useful to point them somewhere.
I'm not entirely sure what this restriction does to help us. We already discourage using non-default prefixes so I'm not sure how this is any different? We can block mixed installations through other, better means (like the FormulaInstaller changes).
There was a problem hiding this comment.
How do existing DTK users migrate? This error will appear for everyone who has tested ARM so far so it perhaps would be useful to point them somewhere.
@Bo98 They'll need to create and setup a new installation in a different location. We recommend one in the installation documentation. Should we do so here, too?
I'm not entirely sure what this restriction does to help us.
It avoids having ARM installs and Intel installs mixing. We don't have a way of enforcing that otherwise as the arch only starts being written to the tab as-of this PR.
We already discourage using non-default prefixes so I'm not sure how this is any different?
I think it's better to actively forbid it because it allows side-by-side installations. I can see the use-case for having two side-by-side installations on ARM until we have complete bottle coverage (which will take years).
Co-authored-by: Bo Anderson <mail@boanderson.me>
|
Thanks for this necessary work, Mike, and on a tight deadline. |
| def in_rosetta? | ||
| # since the `sysctl` flags don't change behaviour under Rosetta 2. | ||
| def in_rosetta2? | ||
| intel? && physical_cpu_arm64? |
There was a problem hiding this comment.
It seems Apple's recommended way to detect Rosetta 2 is to check sysctl.proc_translated.
5 participants
brew doctorandbrew installmessages noting this configuration is (currently) unsupported and encourage use of Rosetta insteadbrew configon ARM (whether in Rosetta 2 or not)/opt/homebrew) and Homebrew on LinuxWhile we're here:
This needs to be merged and in a tagged release before Big Sur is released so please prioritise testing and reviewing this ASAP CC @claui @Bo98 @fxcoudert @mistydemeo