py310-pyqt5-webengine upgrade broken on port version 2.10.1 on Ventura 13.6.7

[Alex11N]

Build fails at:

Generating the Makefiles...
/opt/local/libexec/qt5/bin/qmake -recursive PyQtWebEngine.pro
sip-build-3.10: '/opt/local/libexec/qt5/bin/qmake -recursive PyQtWebEngine.pro' failed returning 3
Project ERROR: Could not resolve SDK Path for 'macosx13.3' using --show-sdk-path

main.log attached. Like py37-pyqt5-sip this will have lt be removed from my ports dir.

[Alex11N]

main.log for py310-pyqt5-webengine 5.15.7_0

[Alex11N]

Sorry, typo - was meant to be port 2.10.1 it title, fixed

[reneeotten (Renee Otten)]

please attach the full main.log file. The port builds correctly for me locally on Sonoma 14.6.1 (23G93), but also for Ventura on the build bots it also build fine (see ​here).

We have seen this error message before (see, for example, Trac ticket 68415) and most of the time it's related to the XCode version that is installed. Please check what you get as output from

xcrun --sdk macosx13.3 --show-sdk-path

and look which SDKs you have actually installed:

ls -l /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs

I don't think we have a clear handle on how to resolve these type of issues, you could try to reinstall XCode. But the fact that it works on the buildbots suggests there is some mismatch on your local system.

[Alex11N]

Thanks for your reply, Renee. I did attach the full main.log file - that is all that there was.

Running your 'xcrun' statement:

xcrun --sdk macosx13.3 --show-sdk-path 
2024-08-19 18:56:45.667 xcodebuild[29919:924387] Writing error result bundle to /var/folders/k3/v_brdxcj2nvdw11hzzbrxhph0000gn/T/ResultBundle_2024-19-08_18-56-0045.xcresult
xcodebuild: error: SDK "macosx13.3" cannot be located.
2024-08-19 18:56:49.341 xcodebuild[29925:924654] Writing error result bundle to /var/folders/k3/v_brdxcj2nvdw11hzzbrxhph0000gn/T/ResultBundle_2024-19-08_18-56-0049.xcresult
xcodebuild: error: SDK "macosx13.3" cannot be located.
xcrun: error: Failed to open property list '/Users/alexnewman/Documents/Programming/MacPorts/gsokoban source code/syasokoban/syasokoban-2.0.1/macosx13.3/SDKSettings.plist'
2024-08-19 18:56:52.489 xcodebuild[29928:924708] Writing error result bundle to /var/folders/k3/v_brdxcj2nvdw11hzzbrxhph0000gn/T/ResultBundle_2024-19-08_18-56-0052.xcresult
xcodebuild: error: SDK "macosx13.3" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'macosx13.3'

then

ls -l /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
total 0
drwxr-xr-x  7 root  wheel  224 14 Nov  2023 MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10 13 Jan  2024 MacOSX14.2.sdk -> MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10 13 Jan  2024 MacOSX14.sdk -> MacOSX.sdk

I have absolutely no idea why 'ls' is reporting MacOSX14.2.sdk: in fact, 'Xcode Version 15.2 (15C500b)' is installed.

I'll try the uninstall/reinstall method of Xcode and see what that does.

[Alex11N]

It's possible that I didn't update port correctly at some point when upgrading macOS versions, but I would have thought that port would have complained at some point.

I'll attached a another copy of main.log, resulting from another abortive run.

I'll look into what system-version of port I have, next.

[Alex11N]

main.log (complete) for abortive py310-pyqt5-webengine build

[jmroot (Joshua Root)]

It's (unfortunately) normal for Xcode to only provide the SDK for the latest OS version as of when that Xcode version was released. The Command Line Tools should have the SDK for the OS version you are running on (under /Library/Developer/CommandLineTools/SDKs). This is one of the reasons why we recommend installing the CLTs and not just Xcode.

[Alex11N]

I've always used xcode-select to install the CLTs (and recently found that I can install the CLTs without Xcode installed).

Right. I've:

1. deleted and 'clean-ish' re-installed Xcode and rebooted;

2. deleted (completely hosed) and reinstalled the CLTs

3. reinstalled macports 2.10.1 using the package downloaded from the website as opposed to 'selfudate', in an attempt to get bash to take up the PATH additions (it didn't, so i did it by hand in ~/.bash_rofile)

4. ran 'sudo port -v migrate' on my installation: 'port' then deleted everything that was @active and repopulated the installation with its snapshot-1. It's notable that very few ports out of the few hundred installed actually went through the build process - things like clang and llvm that used to take hours to compile were simply dropped into place pre-built. One exception to this was PY310-PYQT5-WEBENGINE (there were a few others whose names I couldn't/didn't catch) - and the build failed at the same macos13.3.sdk choke-point.

5. ran 'sudo port -v install py310-pyqt5-webengine' after the migration had finished and it FAILED TO BUILD AGAIN, for exactly the same reason, i.e _{the macOS13.3.SDK - which is part of the latest CLT that I forced xcode-select to download and install.}

The initial failed build attempts that generated this trac ticket were using zsh as my terminal shell; the migration sequence and the last 'webengine' build were running on /opt/local/bin/bash in terminal.

It looks as though there is nothing that I can do to to fix the macos13.3.sdk problem as far as I know: the locations are as Apple has decreed, and almost everything else that I've built-installed on my macports setup have been fine. 'py310-pyqt5-webengine' is definite outlier. I don't understand why the SDK subdir in the CLT directory has versions up to 13.3 but NOT 14.x - other than that Apple hasn't updated the CLTs in (quite) a while. The CLTs seem to add an extra level of complexity since the SYSTEM has what appears to be the same build tools, etc, embedded witihn it.

This is doing what's left of my meagre head in.

[jmroot (Joshua Root)]

Could be that DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer', which is set as a result of use_xcode yes in the Portfile, makes xcrun unable to find SDKs provided by the CLTs. As I'm sure has been noted before, it would be a lot easier if Qt just let us tell it which SDK path to use.

[Alex11N]

Replying to jmroot:

Could be that DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer', which is set as a result of use_xcode yes in the Portfile, makes xcrun unable to find SDKs provided by the CLTs. As I'm sure has been noted before, it would be a lot easier if Qt just let us tell it which SDK path to use.

Is there a licencing (i.e., legal) requirement that we stick strictly to the portfile? Who actually creates it? I would have thought that it would have been up to the maintainer's discretion as to what went into the portfile.

As a slightly related query, is there a useful book on the 'autotool' complex? Most of my problems are dealing with vagaries of configure/autoconf/make/m4, etc. I know that 'make' and relatives and m4 aren't 'autotools' as such, but given my currently lack of understanding about how the build machinery works they almost might just as well be. Actual pogram code is one thing - the build process is another bucket of snakes entirely. It appears to me that the suite changes relatively frequently so what is one year's flavour is different the next, so maybe a book isn'tthe right thing to be asking about.

[jmroot (Joshua Root)]

Yes, the maintainer is in charge of what goes in the Portfile. This error is coming from qmake. It's possible in theory to patch that, but it's potentially a lot more work than you might think. That may be the correct fix here.

use_xcode yes was added to this Portfile in response to #65107, which is the same symptom for possibly the opposite reason.

[Alex11N]

output of qmake on PyQtWebEngine.pro in PyQtWebEngine-5.15.7

[Alex11N]

Running qmake on PyQtWebEngine.pro, I got the following output in the opt/local/share/doc/py311-django/docs/.qmake.stash file - since python3.11 was the current Python3 set using 'port select'

The .stash file showed that qmake was picking up the correct SDK in this artificial and isolated instance:

QMAKE_MAC_SDK.macosx.SDKVersion = 14.2
43
QMAKE_MAC_SDK.macosx.Path = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk

See relevant attached file for full output.

Changing the current Python to 3.10 made no difference at all to a subsequent overall port build of PyQtWebengine.

Attempting to install py39-pyqt5-webengine also fails at the same point. Qt5 is beginning to make my teeth wriggle.

[reneeotten (Renee Otten)]

@Alex11N - sorry for the trouble, but as noted here and in other tickets about this it's very hard do debug/fix all the possible variations someone might have on their computer... As I said, it works for me locally and it seems to work on the buildbots. You could try to remove the use_xcode yes line from the Portfile and see if that fixes it in this specific occurrence for you.

Just to be clear: I am and will not be working on this. If you or someone else finds a more robust way of telling QMake where to look and what SDK to use that would be great and if so, please submit a PR.

[Alex11N]

Hello Renee, I meant to report back yesterday about the results of changing the portfile to 'use_xcode no', but it's possible that I made a comment into the other thread #65107, by mistake. In any event, it still failed.

I also tried building the port - via another port for which py310-pyqt5-webengine is a dependency )py310-eric-ide) - on another machine running on Sonoma that I'd recently set MacPorts up on, so it had a relatively clean and sane environment to work in. The whole thing went without a hitch except ('webengine' portfile left in its original state) that I had to install Xcode itself, the py310-pyqt5-webengine build sequence complaining that it required the full version of Xcode and please install it. Once downloaded and the EULA agreed to, that was fine too, and the whole project including the py31-pyqt5-webengine installed withoui further problems. (The fact that Eric6 failed to run, with a crash report, isn't relevant here as it was QScintilla that broke at run-time.)

That suggests a problem inside my ports install - I'm going to 'uninstall' everything in it and start again from scratch on the first machine (I doid the same with the sencond machine when the Erric IDE failed to run. iTerm2 was having run-time crashes as well - luckly for me I use Geany as a code editor, so this hasn't affected anything anything badly excpet for taking up time. Debugging practise isn't too much of a watse of time, though - up to a point!

If I get any further with this I'll do as you suggest and post a PR.