[MacPorts] #57143: Unable to determine location of a macOS SDK

[MacPorts]

#57143: Unable to determine location of a macOS SDK
------------------------+--------------------
  Reporter:  ivanatina  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  base       |    Version:  2.5.99
Resolution:             |   Keywords:
      Port:             |
------------------------+--------------------
Changes (by ryandesign):

 * cc: kencu, ryandesign (added)


Comment:

 Replying to [comment:13 kencu]:
 > I'm thinking that (at least on fairly current Xcode versions) it might
 be best to always build against the newest SDK that is available, but with
 a deployment target to match the current OS. Is that newest SDK available
 always going to be MacOSX.sdk now? If so, that makes it easy.

 Yes, MacOSX.sdk is always the newest-available SDK. Yes, it would be
 better to use MacOSX.sdk rather than MacOSX10.14.sdk because these SDK
 paths get baked into the files that some ports install, and it would be
 better to bake in a path that will not disappear in a later version of
 Xcode. The fact that these paths get baked in was the reason why I had
 ultimately abandoned the idea of [ticket:41783 always using an SDK] last
 time I investigated it, but now that /usr/include is gone we have no other
 choice. Users will still run into problems if they get a binary from our
 server with [ticket:57252 baked-in Xcode-relative SDK paths] but the user
 has only installed the command line tools and not Xcode.

-- 
Ticket URL: <https://trac.macports.org/ticket/57143#comment:14>
MacPorts <https://www.macports.org/>
Ports system for macOS