py37-pyobjc-cocoa: ValueError: invalid literal for int() with base 10: ''

[angelog0 (Angelo Graziosi)]

sudo port selfupdate
[...]
sudo port outdated
py37-pyobjc-cocoa              5.3_0 < 6.1_0
[...]
sudo port upgrade outdated
[...]
--->  Verifying checksums for py37-pyobjc-cocoa
--->  Extracting py37-pyobjc-cocoa
--->  Configuring py37-pyobjc-cocoa
--->  Building py37-pyobjc-cocoa
Error: Failed to build py37-pyobjc-cocoa: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyobjc-cocoa/py37-pyobjc-cocoa/main.log for details.
[...]

Attached the main.log.

[mf2k (Frank Schima)]

There is no need to compress such a small log file.

[mf2k (Frank Schima)]

Error appears to be:

:info:build Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyobjc-cocoa/py37-pyobjc-cocoa/work/pyobjc-framework-Cocoa-6.1" && /opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7 setup.py --no-user-cfg build 
:debug:build system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyobjc-cocoa/py37-pyobjc-cocoa/work/pyobjc-framework-Cocoa-6.1" && /opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7 setup.py --no-user-cfg build 
:info:build Traceback (most recent call last):
:info:build   File "setup.py", line 25, in <module>
:info:build     extra_link_args=["-framework", "CoreFoundation"],
:info:build   File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyobjc-cocoa/py37-pyobjc-cocoa/work/pyobjc-framework-Cocoa-6.1/pyobjc_setup.py", line 429, in Extension
:info:build     % (tuple(map(int, os.path.basename(data)[6:-4].split("."))))
:info:build ValueError: invalid literal for int() with base 10: ''
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyobjc-cocoa/py37-pyobjc-cocoa/work/pyobjc-framework-Cocoa-6.1" && /opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7 setup.py --no-user-cfg build 
:info:build Exit code: 1

[ryandesign (Ryan Carsten Schmidt)]

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.

[angelog0 (Angelo Graziosi)]

Here I am on macOS HS 10.13.6 because this MBP is Early 2011, so I could not upgrade to 10.14 nor 10.15. Xcode here is 10.1 (10B61) and A. Store - updates reports 11.2.1 as NOT COMPATIBLE.

Regarding the command you cite, I get:

$ /usr/bin/xcrun -sdk macosx --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

BTW, the same issue occurred few weeks ago ​https://trac.macports.org/ticket/59455...

[jmroot (Joshua Root)]

The patch fixing this was incorrectly removed in [efa98e6a9eb4435c0dff227164a963de05fe6e81/macports-ports] (also in the other pyobjc framework ports).

[michaelld (Michael Dickens)]

Guessing this was fixed in [d0fbfc1020b539e021ae43a8c48632ec9818d404/macports-ports] ... so I'm closing this ticket as fixed. If I'm mistaken, then please reopen and post a new build log.

[jmroot (Joshua Root)]

I don't see how it could be fixed given that it's the same version and still isn't applying the necessary patch.

[jmroot (Joshua Root)]

In 034c2dab79897acb524edce67a7987d8723a7f8f/macports-ports (master):

py-pyobjc: restore incorrectly removed patch

Fixes: #59728

[michaelld (Michael Dickens)]

Thanks for restoring the patch. A few info points: (1) I was able to build the ports cleanly without the patch, otherwise I wouldn't have committed them. (2) The patch didn't apply cleanly up front, so I did a quick look at the codebase to see if there was anything obvious about what happened to the file, and it was clear that much had changed. Such significant changes in codebase often mean that such patches are no longer required, and since (1) I just assumed this was the case. (3) That said, I could have looked more deeply into the new codebase to see if maybe the file was moved, which was the case. Every single subdirectory seems to have a file in it that needs patching if we're to have a port for it in MacPorts!

[jmroot (Joshua Root)]

Yes, the build failure only occurs for some configurations where xcrun -sdk macosx --show-sdk-path returns MacOSX.sdk (no version number). Yes there were conflicts introduced by the version 6.1 changes, which were mainly just formatting differences and changing from single to double quotes for some reason. Unfortunately you really can't assume that a patch is no longer needed just because it fails to apply.

The file wasn't moved upstream with the version update, it's just that each framework subdir was previously a separate port, all of which needed the patch.