[macports-base] 01/02: portconfigure: Don't fall back on macosx if we are unable to find an appropriate versioned SDK

[Ryan Schmidt]

> On Sep 28, 2017, at 19:52, Jeremy Huddleston Sequoia wrote:
> 
>> On Sep 28, 2017, at 15:54, Ryan Schmidt wrote:
>> 
>>> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
>>> in repository macports-base.
>>> 
>>> 
>>> https://github.com/macports/macports-base/commit/69c745b2d71ac333d21da953497fd6ae903ce242
>>> 
>>> commit 69c745b2d71ac333d21da953497fd6ae903ce242
>>> 
>>> Author: Jeremy Huddleston Sequoia <jeremyhu at macports.org>
>>> AuthorDate: Mon Sep 4 15:19:04 2017 -0700
>>> 
>>> 
>>>  portconfigure: Don't fall back on macosx if we are unable to find an appropriate versioned SDK
>>> 
>>>  Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu at macports.org>
>>> 
>>> ---
>>> src/port1.0/portconfigure.tcl | 12 ++++++++----
>>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/src/port1.0/portconfigure.tcl b/src/port1.0/portconfigure.tcl
>>> index 4b9f02e..a93e05d 100644
>>> --- a/src/port1.0/portconfigure.tcl
>>> +++ b/src/port1.0/portconfigure.tcl
>>> @@ -419,10 +419,14 @@ proc portconfigure::configure_get_sdkroot {sdk_version} {
>>>       return $sdk
>>>   }
>>> 
>>> -    if {![catch {set sdk [exec xcrun --sdk macosx --show-sdk-path 2> /dev/null]}]} {
>>> -        ui_warn "Unable to determine location of the macOS ${sdk_version} SDK.  Using the default macOS SDK."
>>> -        return $sdk
>>> -    }
>>> +    # TODO: Support falling back to "macosx" if it is present?
>>> +    #       This leads to problems when it is newer than the base OS because many OSS assume that
>>> +    #       the SDK version matches the deployment target, so they unconditionally try to use
>>> +    #       symbols that are only available on newer OS versions..
>>> +    #if {![catch {set sdk [exec xcrun --sdk macosx --show-sdk-path 2> /dev/null]}]} {
>>> +    #    ui_warn "Unable to determine location of the macOS ${sdk_version} SDK.  Using the default macOS SDK."
>>> +    #    return $sdk
>>> +    #}
>> 
>> But this doesn't really help, does it? Xcode 8 only contains the 10.12 SDK, so when running on OS X 10.11 the only SDK you can use is a mismatched one. Similarly with Xcode 9 which only contains the 10.13 SDK even when running on macOS 10.12.
>> 
>> So, what does the code now do in these situations where an SDK matching the OS version does not exist?
> 
> For systems that do not have the DevSDK (the part of the Command Line Tools package that installs the headers into /usr/include, etc.) installed, we will use a real SDK.  If the version of the SDK inside of the selected Xcode.app is newer (eg: 10.13 when running on 10.12), we will look for the matching SDK in /Library/Developer/CommandLineTools/SDKs.  If none is found, we err out.  Other systems (eg: homebrew) went down the path of trying to support newer SDKs, but that's a big pile of mess that I don't want to get into.

I agree with not trying to use newer SDKs on older OSes. It's why I've kept our 10.11 buildbot worker on Xcode 7, and our 10.12 buildbot worker on Xcode 8. But I'm having trouble with some of what you wrote.

/usr/include and /Library/Developer/CommandLineTools/SDKs are both installed by the same installer package -- the command line tools. So I don't understand "If none is found, we err out." If these checks are only occurring if /usr/include doesn't exist, why bother checking /Library/Developer/CommandLineTools/SDKs at that point, since there is no circumstance in which the user could get into the situation where /Library/Developer/CommandLineTools/SDKs exists but /usr/include does not, except for the user manually deleting one of them? Or is this just to accommodate the manual copying of SDKs you mention below?


> For Joe User running on macOS 10.12 with Xcode 9, I suggest installing the DevSDK (via the CLTools package from developer.apple.com).  For Jane Developer interested in testing this out, it just takes some manual setup:
>   1) Do not install the CLTools package (hopefully obvious, but worth noting as it's not easy to remove it once installed)
>   2) Run from Terminal:
>      sudo mkdir -p /Library/Developer/CommandLineTools/SDKs/
>      sudo cp -a /path/to/Xcode-8.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk /Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk
> 
> If you are running 10.12 with Xcode 8.x or 10.13 with Xcode 9.x, things should "just work" without installing the CLTools package.  I have been using MacPorts without a DevSDK on all of my 10.12+ machines for almost a year now without much issue.  The only remaining gotchas that I'm aware of are in gcc (due to upstream bugs that have URLs referenced in the Portfile) and the issue of "newer" SDKs in newer Xcodes (which is why I just decided to not support that).