Opened 22 months ago
Closed 21 months ago
#66589 closed defect (fixed)
py311-pyqt5 does not install
Reported by: | josephsacco | Owned by: | reneeotten (Renee Otten) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.0 |
Keywords: | Cc: | jsalort (Julien Salort), rufty (Bill Hill) | |
Port: | py-pyqt5 |
Description
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"
Attachments (1)
Change History (11)
Changed 22 months ago by josephsacco
comment:1 Changed 22 months ago by jmroot (Joshua Root)
Owner: | set to reneeotten |
---|---|
Port: | py-pyqt5 added; py311-pyqt5 removed |
Status: | new → assigned |
comment:2 Changed 21 months ago by jsalort (Julien Salort)
Cc: | jsalort added |
---|
comment:3 Changed 21 months ago by rufty (Bill Hill)
Cc: | rufty added |
---|
comment:4 Changed 21 months ago by 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.
comment:5 follow-up: 7 Changed 21 months ago by 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.
comment:6 Changed 21 months ago by 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
comment:7 follow-up: 8 Changed 21 months ago by reneeotten (Renee Otten)
Replying to jsalort:
I realised the same thing earlier today. Changing
destroot.cmd
tomake install
instead ofmake
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…
comment:8 follow-up: 9 Changed 21 months ago by 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).
comment:9 Changed 21 months ago by 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 addpython.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.
comment:10 Changed 21 months ago by reneeotten (Renee Otten)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
py311-pyqt5 log file