py311-pyqt5 does not install

[josephsacco]

System: OSX 12.6.2, SDK12

See below.

-Joseph

:debug:destroot Executing proc-post-org.macports.destroot-destroot-0
:debug:destroot Executing proc-post-org.macports.destroot-destroot-1
:debug:destroot Executing portdestroot::destroot_finish
:debug:destroot Fixing glibtool .la files in destroot for py311-pyqt5
:error:destroot No files have been installed in the destroot directory!
:error:destroot Please make sure that this software supports 'make install DESTDIR=${destroot}' or implement an alternative destroot mechanism in the Portfile.
:error:destroot Files might have been installed directly into your system, check before proceeding.
:error:destroot Failed to destroot py311-pyqt5: Staging py311-pyqt5 into destroot failed
:debug:destroot Error code: NONE
:debug:destroot Backtrace: Staging py311-pyqt5 into destroot failed
:debug:destroot     while executing
:debug:destroot "$postrun $targetname"

[josephsacco]

py311-pyqt5 log file

[rufty (Bill Hill)]

The problem seems to be destroot doing a "make" instead of a "make install".

After "sudo port build py311-pyqt5":

sudo ln -s /opt/local/Library/Frameworks/Python.framework/Versions/3.11/bin/sip-distinfo /opt/local/bin/sip-distinfo-3.11-3.11-3.11 #Another problem

cd \ /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyqt5/py311-pyqt5/work/PyQt5-5.15.7/build

sudo make \

INSTALL_ROOT=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyqt5/py311-pyqt5/work/destroot install #Note install

sudo rm /opt/local/bin/sip-distinfo-3.11-3.11-3.11 #Tidy up

sudo port install py311-pyqt5

Only tested as far as a PyQt5 "Hello, World!!!" button.

[jsalort (Julien Salort)]

I realised the same thing earlier today. Changing destroot.cmd to make install instead of make in the Portfile fixes the issue. But I wanted to check that the change does not break other variants before submitting a PR.

[josephsacco]

Julien,

That works. Thanks...

One other little nit: I encountered an SDK problem when building on an older iMac running MacOS 12.6.2. The build requires SDK 12. The Xcode installation has only SDK13:

drwxr-xr-x  7 root    wheel  224 Dec 14 10:09 MacOSX.sdk
lrwxr-xr-x  1 root  wheel  10 Dec 14 10:06 MacOSX13.1.sdk -> MacOSX.sdk
lrwxr-xr-x  1 root  wheel  10 Nov  2 10:17 MacOSX13.sdk -> MacOSX.sdk

Whereas, the installation of CommandLine Tools on my system has multiple SDKs:

lrwxr-xr-x   1 root  wheel   14 Dec 14 11:13 MacOSX.sdk -> MacOSX13.1.sdk
drwxr-xr-x  11 root  wheel  352 May  1  2021 MacOSX10.15.sdk
drwxr-xr-x   8 root  wheel  256 Nov 17 16:41 MacOSX11.3.sdk
lrwxr-xr-x   1 root  wheel   14 Nov 17 16:37 MacOSX11.sdk -> MacOSX11.3.sdk
drwxr-xr-x   4 root  wheel  128 Dec 14  2021 MacOSX12.0.sdk
drwxr-xr-x   7 root  wheel  224 Nov 17 16:41 MacOSX12.1.sdk
drwxr-xr-x   7 root  wheel  224 Dec 14 11:14 MacOSX12.3.sdk
lrwxr-xr-x   1 root  wheel   14 Dec 14 11:13 MacOSX12.sdk -> MacOSX12.3.sdk
drwxr-xr-x   3 root  wheel   96 Dec 14 11:14 MacOSX13.0.sdk
drwxr-xr-x   7 root  wheel  224 Nov 12 16:18 MacOSX13.1.sdk
lrwxr-xr-x   1 root  wheel   14 Dec 14 11:13 MacOSX13.sdk -> MacOSX13.1.sdk

The Portfile contains code that forces the use of Xcode:

    # https://trac.macports.org/ticket/65410
    if { ${os.platform} eq "darwin" && (( ${os.major} >= 15 && ${os.major} <= 16 ) || ${os.major} >= 20 ) } {
        use_xcode   yes
    }

What to do?

I ran two experiments that both worked:

• Comment out the use_xcode stuff in the Portfile
• Leave the use_xcode stuff in the Port file add SDK12 to Xcode.

Someone who better understands this might want to take a look at this.

-Joseph

[reneeotten (Renee Otten)]

Replying to jsalort:

I realised the same thing earlier today. Changing destroot.cmd to make install instead of make in the Portfile fixes the issue. But I wanted to check that the change does not break other variants before submitting a PR.

It looks like “python.pep517” is set to “yes” for Python 3.11 by the “python” PG. that will likely requore some changes if one passes arguments to the “setup.py” using the traditional installation method. To be fair, trying to switch to PEP517 should be done but I am not sure of it’s absolutely required yet for Python 3.11 and/or if it should be done by default (yet) in the PortGroup. Perhaps trying to explicitly set “python.pep517 no” in the Portfile would work for now.

I can check when I get home tonight ; I couldn’t figure out why the py311 subport didn’t build but this at least gives a pointer to follow up on…

[jsalort (Julien Salort)]

Replying to reneeotten:

It looks like “python.pep517” is set to “yes” for Python 3.11 by the “python” PG. that will likely requore some changes if one passes arguments to the “setup.py” using the traditional installation method. To be fair, trying to switch to PEP517 should be done but I am not sure of it’s absolutely required yet for Python 3.11 and/or if it should be done by default (yet) in the PortGroup. Perhaps trying to explicitly set “python.pep517 no” in the Portfile would work for now.

I just tried to leave destroot.cmd unchanged but add python.pep517 no, and it fixes the build issue as well. I will submit a PR once I checked that the other subports and variants are not affected (they shouldn't).

[reneeotten (Renee Otten)]

Replying to jsalort:

Replying to reneeotten:

It looks like “python.pep517” is set to “yes” for Python 3.11 by the “python” PG. that will likely requore some changes if one passes arguments to the “setup.py” using the traditional installation method. To be fair, trying to switch to PEP517 should be done but I am not sure of it’s absolutely required yet for Python 3.11 and/or if it should be done by default (yet) in the PortGroup. Perhaps trying to explicitly set “python.pep517 no” in the Portfile would work for now.

I just tried to leave destroot.cmd unchanged but add python.pep517 no, and it fixes the build issue as well. I will submit a PR once I checked that the other subports and variants are not affected (they shouldn't).

my computer is still building the py311 subport that started last night but the computer when to sleep... If that finishes correctly I will commit that change as the other subports will not be affected and thus should continue to work as-is.

[reneeotten (Renee Otten)]

In 35e83ee62a929127f7a9c08b155dbec5ba578823/macports-ports (master):

py311-pyqt5: do not use python.pep517

The python PG sets "python.pep517 yes" for Python 3.11; that breaks the
build of ports that use pass arguments to the traditional setup.py-style
builds.

Closes: #66589
Closes: #66611