[PyQt] How to build pyqt sources to provide the same content than official wheel?
BPL
spscener84 at gmail.com
Sat Jul 20 17:38:11 BST 2019
Phil,
don't mind my previous mail, I think I've found the issue here... problem
some Pyqt5 pyd not loading is because they were missing
some external dlls such as libpng16.dll... right now I'm trying to figure
out why, maybe the way I've compiled qt:
configure.bat -prefix "d:/qt/5.13.0-394-g69ef6e8212" -opensource
-confirm-license -nomake examples -nomake tests -opengl dynamic -ssl -L
D:/software/vcpkg/installed/x86-windows/lib -I
D:/software/vcpkg/installed/x86-windows/include -v
wasn't a good idea afterall... I suspect by doing this I've been forced to
add d:/software/vcpkg/installed/x86-windows/bin to path when importing
PyQt as well so that libpng16.dll will be found... so probably the best way
to link openssl is by downloading & compiling openssl in isolation (ie:
https://www.openssl.org/source/)
and not relying in vcpkg at all :/
On Sat, Jul 20, 2019 at 5:54 PM BPL <spscener84 at gmail.com> wrote:
> Phil,
>
> Usually I don't have any of my available qt distributions in path, when
> you said
>
> You don't copy your Qt installation, PyQt (when build from sources) will
>> use it where it is.
>
>
> I guess you meant PyQt (when built from sources) will use the Qt
> installation from either path
> or from the Qt folder in the target dir where PyQt has been installed. I
> can see pyqt
> __init__.py looks like this:
>
> def find_qt():
> import os
>
> path = os.environ['PATH']
>
> dll_dir = os.path.dirname(__file__) + '\\Qt\\bin'
> if os.path.isfile(dll_dir + '\\Qt5Core.dll'):
> path = dll_dir + ';' + path
> os.environ['PATH'] = path
> else:
> for dll_dir in path.split(';'):
> if os.path.isfile(dll_dir + '\\Qt5Core.dll'):
> break
> else:
> raise ImportError("unable to find Qt5Core.dll on PATH")
>
> try:
> os.add_dll_directory(dll_dir)
> except AttributeError:
> pass
>
>
> find_qt()
> del find_qt
>
>
> As a workaround I've decided to create a junction pointing out
> to the Qt distribution used to build pyqt from sources, ie:
>
> (py364_32) d:\virtual_envs\py364_32\Lib\site-packages\PyQt5>mklink /j Qt
> d:\qt\5.13.0-394-g69ef6e8212
> Junction created for Qt <<===>> d:\qt\5.13.0-394-g69ef6e8212
>
>
> But for some reason when I do `from PyQt5.Qt import *` I'll just get this
> content
> <https://dl.dropboxusercontent.com/s/cj9rf8mbm023rwf/2019-07-20_17-49-10.txt> where
> you can see there isn't any available
> QApplication :(
>
> And when doing `from PyQt5.QtWidgets import *` I'll get:
>
> from PyQt5.QtWidgets import *
> ImportError: DLL load failed: The specified module could not be found.
>
> So I'm stuck at this point, could you advice?
>
> On Sat, Jul 20, 2019 at 4:34 PM BPL <spscener84 at gmail.com> wrote:
>
>> Florian,
>>
>> Thanks to provide those wiki docs as well as the qt releasing mailing
>> list, they're definitely
>> helpful indeed to make proper planning.
>>
>> If I look in retrospective is funny though, that QTBUG-74492 is the first
>> one I've ever been involved with,
>> this bug was opened in 21.03.2019 and after few months passed nobody was
>> working on it or they didn't
>> know what the problem was. I decided to spend some days bisecting the bug
>> and finding the root cause
>> of the problem, thanks to that the author who introduced the bug in the
>> first place could fix it properly in few days. In any case,
>> finding the issue was really tricky and the fix ended up to be quite
>> "trivial" one. The moral of the story here is,
>> for something as trivial as this one you'll need to wait quite a lot of
>> time to get
>> a proper release... and that's assuming you're interested enough to help
>> Qt team to narrow it down. The
>> workload of Qt devs isn't small neither... which indicates there is room
>> to optimize development in that company.
>>
>> Bug opened in 21.03.2019 and official release with the fix delivered in
>> 15.08.2019... That's quite a lot
>> of time to wait for...
>>
>> Anyway, at this point a global view of how things work in both Qt & pyqt
>> has become +/- clear, which is great so you
>> know what you can or can't expect.
>>
>> On Sat, Jul 20, 2019 at 3:10 PM Florian Bruhin <me at the-compiler.org>
>> wrote:
>>
>>> On Sat, Jul 20, 2019 at 02:53:29PM +0200, BPL wrote:
>>> > Anyway... I'll try again to see if I can make it work but hopefully a
>>> new
>>> > pyqt wheel with this annoying bug fix
>>> > https://bugreports.qt.io/browse/QTBUG-74492
>>> > will land soon at pypi, I've got some opengl tools in place where this
>>> > glitch makes really annoying work with them, it's a really disturbing
>>> bug :/
>>>
>>> As you can see in the bug report, the fix lands in Qt 5.12.5, 5.13.1 and
>>> 5.14.0.
>>> Via the Qt wiki, you can see when those are planned to be released:
>>>
>>> https://wiki.qt.io/Qt_5.12_Release (5.12.5: 27.08.2019)
>>> https://wiki.qt.io/Qt_5.13_Release (5.13.1: 15.08.2019)
>>> https://wiki.qt.io/Qt_5.14_Release (5.14.0: 26.11.2019)
>>>
>>> After a new Qt is released, usually a couple of days afterwards, PyQt
>>> gets
>>> updated (might be a bit longer for new feature releases like 5.14 will
>>> be).
>>> So if you're okay with upgrading to Qt 5.13, you'll hopefully see an
>>> updated
>>> PyQt in a month or so.
>>>
>>> I'd also recommend subscribing to the Qt Releasing mailinglist - it's
>>> quite
>>> low-traffic, and you get announcement mails when Qt updates are
>>> released, or
>>> when there was a release team meeting (with the meeting minutes):
>>>
>>> https://lists.qt-project.org/listinfo/releasing
>>>
>>> Florian
>>>
>>> --
>>> https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP)
>>> GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
>>> I love long mails! | https://email.is-not-s.ms/
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20190720/9bb037f9/attachment-0001.html>
More information about the PyQt
mailing list