Pyqtdeploy plan for the end of qmake?

[Patrick Stinson]

I don’t know how the headers, dll stubs, sip files and such would be handled in that case, but developing sip extensions on windows is such an unholy practice and experience (mostly due to a poorly-defined python build system) that it warrants consideration. I have never really gotten the dev env built in a predictable way.

-Patrick


> On Jul 7, 2020, at 11:12 AM, Patrick Stinson <patrickkidd at gmail.com> wrote:
> 
> I am not familiar with cmake yet, but do you think that ditching qmake will make it possible to compile and link sip extensions against the pip-installed pyqt5 on various platforms? I have an app that has a custom sip extension.
> 
> I would say that I spend the more time hacking though configuring+compiling the various pyqt5 stacks (release | debug <==> macOS | iOS | linux | windows) just so I can get qmake to compile my app’s simple sip-based Qt-based extension. A ground-up makefile approach didn’t save any time on qmake considering the lack of portability with windows.
> 
> Cheers,
> -Patrick
> 
>> On Apr 28, 2020, at 4:34 AM, Patrick Stinson <patrickkidd at gmail.com> wrote:
>> 
>> Yep, cmake.
>> 
>>> On Apr 28, 2020, at 12:47 AM, Phil Thompson <phil at riverbankcomputing.com> wrote:
>>> 
>>> On 28/04/2020 06:44, Patrick Stinson wrote:
>>>> Phil,
>>>> What is the plan for pyqtdeploy on Qt 6 when qmake is retired?
>>>> Planning to just port to qmake?
>>> 
>>> You mean cmake?
>>> 
>>>> It doesn’t seem like there is a ton of code for the .pro output...
>>> 
>>> PyQt6 will require SIP v6 which will include a cmake builder (to replace the qmake builder in PyQt-builder).
>>> 
>>> Before that time pyqtdeploy will support SIP v5 (currently planned for v3.1) and subsequent support for SIP v6 should be trivial.
>>> 
>>> Phil
>