py36-pyqt5 Failed to determine details of Qt installation.

[Ryan Schmidt]

On Sep 27, 2019, at 06:04, Carlo Tambuatco wrote:

> I filed a ticket on this issue already and included a logfile for it, but I thought there's no harm in asking the mailing list for a quick solution...
> 
> I upgraded to macports 2.6.0 today. During a routine upgrade of my 
> ports, the py36-pyqt5 port failed to configure, possibly due to a 
> problem with the recent XCode 11 upgrade...?
> 
> From logfile:
> 
> Error: Failed to determine the detail of your Qt installation. Try again using
> the --verbose flag to see more detail about the problem.
> Querying qmake about your Qt installation...
> Determining the details of your Qt installation...
> /opt/local/libexec/qt5/bin/qmake -o cfgtest_QtCore.mk cfgtest_QtCore.pro
> Project ERROR: Could not resolve SDK Path for 'macosx10.14' using --show-sdk-path
> 
> 
> This is the first time something like this has happened. No problems before the XCode 11 upgrade.
> 
> I upgraded to XCode 11 a few days ago, and as someone else pointed out, XCode removed the MacOS10.14.sdk and replaced it with MacOS10.15.sdk. 
> What I did to try and resolve it was create a MacOSX10.14.sdk symlink. 
> Is py36-pyqt5 one of those ports that has a hard-coded path to the 10.14 SDK, and somehow isn't fooled by the symlink I created or something?

We are discovering, due to the Xcode 11 upgrade, just how many places in MacPorts the path to the 10.14 SDK got baked into files where we didn't mean for it to be. There are many other mailing list threads and tickets being filed with us about this. Until this is all ironed out, your simplest course of action would be to uninstall Xcode 11 and reinstall Xcode 10.

I cannot advocate creating a MacOSX10.14.sdk symlink. The 10.14 and 10.15 SDK are not the same thing. Subverting the system into believing they are can only cause you problems down the road.