Opened 3 years ago
Last modified 3 years ago
#63139 new enhancement
Prefer MacOSX11.sdk if available else prefer newest MacOSX11.*.sdk
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.7.1 |
Keywords: | bigsur | Cc: | mojca (Mojca Miklavec) |
Port: |
Description
On macOS 11 (12, etc.), MacPorts should pick the MacOSX11.sdk (MacOSX12.sdk, etc.) symlink if it exists (which it does in Xcode 12.5 and later) rather than a more specific SDK version that might disappear in a future Xcode update (such as MacOSX11.3.sdk).
If the major version SDK symlink does not exist, then we should pick the newest version number SDK that exists and passes the sanity check (i.e. if MacOSX11.0.sdk and MacOSX11.1.sdk exist, it should prefer the 11.1 SDK) as I mentioned in comment:ticket:61866:16.
Change History (3)
comment:1 Changed 3 years ago by mojca (Mojca Miklavec)
Cc: | mojca added |
---|
comment:2 follow-up: 3 Changed 3 years ago by mojca (Mojca Miklavec)
comment:3 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to mojca:
Ryan, hasn't this already been addressed?
Not as far as I can see. The code currently in base is:
# find a "close enough" match for the given sdk_version in sdk_path proc portconfigure::find_close_sdk {sdk_version sdk_path} { # only works right for versions >= 11, which is all we need set sdk_major [lindex [split $sdk_version .] 0] set sdks [glob -nocomplain -directory $sdk_path MacOSX${sdk_major}*.sdk] foreach sdk [lsort -command vercmp $sdks] { # Sanity check - mostly empty SDK directories are known to exist if {[file exists ${sdk}/usr/include/sys/cdefs.h]} { return $sdk } } return "" }
To me it looks like it sorts all found SDKs in ascending version order (e.g. "11" first, if it exists, then "11.0" if it exists, then "11.1" if it exists, etc.). I am suggesting that the order in which we check should be changed: first the major version (e.g. "11") if it exists, then in descending version order (e.g. "11.3", then "11.1", then "11.0").
Ryan, hasn't this already been addressed? At least when building perl this now seems to work as expected (if it wasn't for the fact that all the binaries have been built before the fix was there).