[MacPorts] #59728: py37-pyobjc-cocoa: ValueError: invalid literal for int() with base 10: ''

[MacPorts]

#59728: py37-pyobjc-cocoa: ValueError: invalid literal for int() with base 10: ''
------------------------------+--------------------
  Reporter:  angelog0         |      Owner:  (none)
      Type:  defect           |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:  2.6.2
Resolution:                   |   Keywords:
      Port:  py-pyobjc-cocoa  |
------------------------------+--------------------

Comment (by ryandesign):

 Hmm. This should work.

 The `data` it's parsing here is the output of `/usr/bin/xcrun -sdk macosx
 --show-sdk-path`. That should return the full SDK path on Xcode 5 and
 later, and the log shows you're on macOS 10.13 with Xcode 10.1. What
 happens when you run this manually?

 It should return something like
 `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk`.
 The parsing code takes the last path component (`MacOSX10.14.sdk`), strips
 off the first 6 characters (`MacOSX`) and the last 4 characters (`.sdk`),
 which should leave just the version number (`10.14`), which is split on
 `.` and the two parts are cast as integers. In your case, this seems to be
 empty.

 Is it possible that on your system it is returning the unversioned SDK
 path
 `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk`?
 I think we've seen that before, but I don't think we ever found out why
 that happens to some people.

 It is still questionable that the build system is trying to determine the
 latest SDK version. MacPorts already tells ports what SDK use. Ports
 usually should not second-guess MacPorts about that.

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