Handle macOS Homebrew on ARM #9117
Conversation
MikeMcQuaid
requested review from
mistydemeo,
Bo98,
claui,
fxcoudert and
a team
MikeMcQuaid
force-pushed
the
handle-arm
branch
2 times, most recently
from
bf558c5
to
2d86424
Compare
MikeMcQuaid
force-pushed
the
handle-arm
branch
from
2d86424
to
64d9645
Compare
- 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
MikeMcQuaid
force-pushed
the
handle-arm
branch
from
64d9645
to
5afff3f
Compare
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. |
| # since the `sysctl` flags don't change behaviour under Rosetta. | ||
| 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.
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