You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 8, 2022. It is now read-only.
It looks like platform-wise every version of macOS is treated as a single target: darwin amd64.
I know this maps to the model used by the Go programming language, but homebrew clearly distinguishes packages for the different releases of macOS. This will probably start to matter when you define packages that link against system libraries.
Is there a design goal to address this problem?
The text was updated successfully, but these errors were encountered:
I haven't figured out how to determine which major OS release you're on, but we can certainly look into Homebrew core to figure out how they do it for MacOS. Once that's determined, we can then see how we can translate that to Windows and Linux. So yes, it'd be nice to solve this problem. For now the assumption is only the latest major OS releases are supported: Windows 10, High Sierra and... w/e flavour of Ubuntu/Debian is the latest.
If I'm reading the code right, the assumption is that the latest version of Homebrew supports bottles compiled on High Sierra by default, but there is no system in place to determine the underlying major OS release Homebrew is running on. That is configured separately through $HOMEBREW_MACOS_VERSION (or $HOMEBREW_OSX_VERSION for backwards compatibility), likely configured through the install script. That doesn't seem too hard to implement if someone wants to take a crack at it :)
It looks like platform-wise every version of macOS is treated as a single target: darwin amd64.
I know this maps to the model used by the Go programming language, but homebrew clearly distinguishes packages for the different releases of macOS. This will probably start to matter when you define packages that link against system libraries.
Is there a design goal to address this problem?
The text was updated successfully, but these errors were encountered: