> On Oct 1, 2017, at 22:55, Ryan Schmidt <[email protected]> wrote: > > > On Oct 2, 2017, at 00:39, Leonardo Brondani Schenkel wrote: > >> On 2017-09-29 13:30, Ryan Schmidt wrote: >>> I don't know if I'm the author of the mail you're thinking of, but I've >>> surely commented on this matter before. It's Jeremy Huddleston Sequoia's >>> work on master I was referring to. >>> I haven't tested that work. But at least with MacPorts 2.4.1 I perceived >>> that not having an SDK matching the running OS version would be a problem >>> for some ports, so I didn't update our OS X 10.11 buildbot worker from >>> Xcode 7 to 8, and similarly I won't update our macOS 10.12 worker from >>> Xcode 8 to 9. >> >> Yes, that's right. The mail I have seen was about some commits from Jeremy, >> now you reminded me. Thanks. >> >> What if MacPorts outputted a warning when there's a SDK mismatch (maybe >> pointing users to the right version of Xcode to use)? In my case, when Xcode >> was updated I didn't know it had the 10.13 SDK until ports started failing, >> and it would have saved me a bit of troubleshooting. Is it a worthwhile idea >> to implement? > > That sounds ok to me, but I gather that Jeremy still thinks that should not > be necessary.
If you install the DevSDK (which is part of the Command Line Tools Package), then there's not really a need to stay on Xcode 8. The relevant system headers are installed to / by that package, and those are used instead of the macOS 10.13 SDK by almost all ports (there are possibly a few that do weird things, but the vast majority that follow best practices will "just work"). It's been that way for years, and I haven't noted any issues reported about that. If you have mismatched SDK/host versions *AND* you do not have the DevSDK installed, we err out.
