On Nov 18, 2020, at 21:04, Chris Jones wrote:
> On 19 Nov 2020, at 2:31 am, Ryan Schmidt wrote:
>
>>> On Nov 18, 2020, at 20:28, Saagar Jha wrote:
>>>
>>>> On Nov 18, 2020, at 18:12, Ryan Schmidt wrote:
>>>>
>>>> Based on the fact that Apple has released a beta of macOS Big Sur 11.1
>>>> already, we can now see that Big Sur should be referred to as version 11,
>>>> not 11.0 (and it would be reasonable to expect that next year's macOS will
>>>> be version 12).
>>>>
>>>> If you are fixing any ports that had been coded to assume the macOS
>>>> version was always 10.x, be sure that you're not fixing it to simply
>>>> accept versions 10.x or 11.x. Instead, remove any assumption about the
>>>> version number so that you won't have to revisit the problem again every
>>>> year.
>>>>
>>>> When Josh released MacPorts 2.6.4 recently, he used the number 11.0 on the
>>>> Big Sur installer package. For the next version, we should use the version
>>>> number 11 to denote Big Sur.
>>>>
>>>> I did the same when naming the Big Sur buildbot machines and will change
>>>> them from 11.0 to 11 soon.
>>>>
>>>> Part of our decision to use "11.0" came from the way that Apple named the
>>>> SDK: MacOSX11.0.sdk. We will have to see if they change this to
>>>> MacOSX11.1.sdk in a future version of Xcode and the CLT. If they do, that
>>>> would represent a change from their previous strategy, and it would be a
>>>> problem for MacPorts because the SDK path gets baked into some ports.
>>>> Previously this was ok since the SDK path would stay the same for the life
>>>> of the OS version, but if it now changes during the life of the OS we may
>>>> find ourselves needing to rebuild some ports to update their SDK paths.
>>>>
>>>> We may also need to adjust how MacPorts selects the SDK version and SDK
>>>> path, depending on whether Apple changes the SDK name.
>>>>
>>>
>>
>>> The macOS SDK in Xcode 11.3 is MacOSX11.1.sdk.
>>
>> Presumably you mean Xcode 12.3.
>>
>> But ok, then this will suck, and users on Big Sur will need to make sure
>> that they use an Xcode version that has the right SDK for their *minor* OS
>> version.
>
> Maybe macports should move away from using the versioned sdk and just use
> the versionless link instead, which should also be present...
MacPorts should be falling back to MacOSX.sdk if the versioned one is not
available:
https://github.com/macports/macports-base/commit/73ee4b496ffb35ae8c57606580c8b2e7cd440b34
However we would rather use the versioned one to be sure it's the right
version. Software written specifically for Macs may be able to deal with a
newer-than-OS-version SDK, but most software in MacPorts isn't written
specifically for Macs and can't always cope with that.
