Sent from my iPhone...
> On Sep 29, 2017, at 04:50, Ryan Schmidt <[email protected]> wrote: > > >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> >>>> --- >>>> 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? Currently, one can accomplish this by either manually copying from Xcode 8 or by installing just the sub-package that contains the SDK from Xcode 8’s CLTools package. The CLTools package is a meta package that contains the latest SDK, the DevSDK, and the toolchain as separate packages. One can get just the 10.12 SDK package by extracting it from the meta package. Both approaches are not something I want to request of users, which is why for now, I suggest users continue using the DevSDK and interested developers can do this to help address any issues encountered. As I mentioned earlier, the only currently known issue is with gcc, so I think it is quite usable. >> 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). >
