I'm now working on multiple fronts to try to make a nice distribution package of what I'm calling the alpha version of PPQT2. And the world is fighting back at me hard. Here's some of the scrimmages over the last 24 hours.
Nuitka #1
In recent days the hard-working Kay Hayens has added more support for making standalone PyQt apps with his Nuitka compiler. It not only compiles one's Python code to C++ and compiles it, it also tries to pull in all related modules and DLLs into a single folder. There were (and continue to be) issues with Nuitka compiling Cobro, because Cobro uses QWebEngine. But PPQT2 does not, so I thought I'd give it a try.
Immediately the compiler died trying to handle the import of the sortedcontainers package. I reported this with a one-line test case on Friday afternoon. A few hours later, Kay had fixed the problem. Nuitka saw two paths to the same module, via /Library/Frameworks/Python.framework/Versions/3.4 and via the standard symlink, /Library/Frameworks/Python.framework/Versions/Current. Mishandling of imports. So that was fixed by Saturday morning.
Nuitka #2
So now the Nuitka compile goes all the way through the gathering and compiling and C++ compiles to the point where it is pulling in DLLs and then it fails because it can't find "qliboffscreen.dll" which does exist in the Qt plugins directory. Setting DYLIB_LIBRARY_PATH doesn't help. So I fire off another email this morning at 10:24am and get an answer at 10:32! With a suggestion on where in the Nuitka code I can start debugging the problem. ohhhkay then.
Ubuntu #1
After sending the note on Nuitka yesterday afternoon I fired up my Ubuntu 32-bit dev system and installed virtualenv, and made a VENV, and inside that I installed Qt5.4 and SIP and tried to install PyQt5.4.1. Unfortunately that didn't work.
PyQt has a very (very) elaborate config.py which tests lots of things and decides which modules it can build and sets up dozens of little make files. But it was deciding it could build only about 1/4 of the available modules. And of course it didn't say why.
So I started reading the code of its config.py. Turns out, it has a long list of modules and it tests whether it ought to build each one by creating a tiny C++ source file that just does a new to create an object of the corresponding Qt class. Then it uses popen to run qmake to run the compiler to compile that source, and if the compile works, it sets up to build the matching PyQt module. And if not, it silently omits that module from the build list.
So 3/4 of the modules in the list were not compiling. Why? Well, there is a --verbose switch. Turning it on displays the qmakes. And they were all failing because "cannot find -lGL".
WUT?
Google google google.
Ok, thats libgl.so, and it should exist, but just to make sure I bring up the Synaptic package manager and re-install libgl-dev. And I verify that there does exists a file:
/usr/lib/i386-linux-gnu/libGL.so
Which is in turn a link to
/usr/lib/i386-linux-gnu/mesa/libGL.so
Which is in turn a link to
/usr/lib/i386-linux-gnu/mesa/libGL.so.1.2
And LD_LIBRARY_PATH is set correctly. So, all good, right? Wrong. The makes still report "cannot find -lGL". So I fire off a terse note to the PyQt mailing list, hoping somebody will point out an obvious mistake, and call it a day.
Saturday morning I return to the Nuitka front, download the latest dev version with the results noted above. Then because there was no reply to my PyQt query this morning, I decided I would tackle that by making a copy of libGL.so into every place I could think of, starting with /usr/lib. So I sit down and do,
sudo cp /usr/lib/i386-linux-gnu/libGL.so /usr/lib
And guess what? cp "cannot stat" that file. WUT?!? Turns out, that link is dangling, there is no target file at the end of it. So also is the link /usr/lib/i386-linux-gnu/mesa/libGL.so. At the end of the chain there is no file libGL.so.1.2. Just dangling links all the way down.
There was in fact a mesa/libGL.so.10.1.2.28859, and when I copied that to /usr/lib, the PyQt5 configure and make proceeded normally. So somehow for reasons I cannot fathom, the installation of libgl-dev left broken links.
PyInstaller #1
So now I have a working PyQt5 on Ubuntu so I downloaded the Python3 branch of PyInstaller to Ubuntu and used it to bundle PPQT2. It seemed to go fine, but when I tried to execute the bundled app, it died in the PyInstaller boot-loader module looking for something called orig-prefix.txt. I looked to see if the MacOS version of PyInstaller had made anything like that, but no. So... send off an email to the PyInstaller list.
It's now nearly noon Saturday. I'm going for a pleasant walk with my wife, have a coffee. Maybe this afternoon, if I feel real energetic, I will return to the Nuitka #2 problem.
Ubuntu #2
OK so she wasn't ready for a walk and I returned to the keyboard. Thought I would at least try out PPQT2 from source in Ubuntu. Glad I did, gaaahhhh!
When I ran it, as soon as it opened the window, there was just all kinds of bad stuff happening on the screen. There was a huge title bar the full width of the screen. When I dragged the window around it left comet-trails of pixels. And the terminal window was full of looping messages about QPainter issues.
I killed it (which wasn't easy, the only way to kill it was to click the (x) in that full-width title bar) and pondered. Then I tried executing a tiny little test file from my trials folder. This creates a mainwindow with just three widgets, it's about 20 lines of code.
Same deal, constant messages from QPainter. But by killing it quickly before they could fill up the scroll-back area, I found out that on startup there were several messages of the form
(python:16446): Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion 'GTK_IS_WIDGET (widget)' failed
Googled that. Very common problem. Found people who had this and got around it by setting the QApplication style to something other than the default, thus avoiding use of GTK. I quickly modified my little test to do this, it took about 5 trials to work out the proper syntax for the argv strings, but when I added this code to the top of the test file,
args = []
if sys.platform == 'linux' :
args = ['','-style','Cleanlooks']
app = QApplication(args)
Then it came up nice and clean, no problems. Interesting, I also tried the 'Plastique' style which is supposed to be different, but it wasn't. In fact both looked exactly the same and exactly like the default Ubuntu look. But specifying any of them eliminated this horrible graphic loop catastrophe.
Ubuntu #3
So I put that code at the top of PPQT2.py and ran it, and now it won't start up because it is not initializing fonts. Some problem with QFont() arguments. It did not do this the first time it started up, which tells me the problem now must be because now it has a QSettings to read and what it is getting from there is not right.
I am now going for that walk & coffee and to hell with this.
No comments:
Post a Comment