Pyqtdeploy plan for the end of qmake?

[Patrick Stinson]

I am combining replies to both forks of this thread. I think it is interesting and important enough to reply even this late.

See below.


> On Jul 8, 2020, at 12:47 AM, Phil Thompson <phil at riverbankcomputing.com> wrote:
> 
> On 07/07/2020 23:09, Patrick Stinson wrote:
>> I have an app which has both python code and a sip-based Python
>> extension to allow to app’s python code to access C apis. The sip
>> extension contains classes that extend Qt classes via the .sip files
>> provided by PyQt.
>> At current anyone who is developing such a sip extension has to build
>> the entire Qt/Python/sip/PyQt stack from source. This has always been
>> and still is horribly cumbersome when developing on more than one
>> platform. For all the time I put into this project, I spend most of my
>> time trying to keep my development environment alive across platforms
>> because of the fragility of configuring and building the stack. It is
>> such a pain that I will venture to predict that almost no one is doing
>> this seriously on both macOS and windows, if on windows at all. If I
>> am right, then that is a shame.
>> Broadly speaking, I believe this problem is important enough to point
>> it out. I Am hijacking this email thread on the future of qt and
>> dropping qmake in favor of cmake to point out this problem and ask for
>> your thoughts.
> 
> pyqtdeploy was developed for two reasons...
> 
> - to produce applications implemented as a single executable (required by some platforms)
> - to be able to produce those applications using cross-compilation
> 
> To achieve the above you have to build PyQt from source. If your target is a desktop platform then you will also need to build Qt from source. However if you don't want to achieve the above, ie. you are happy to build your application linked against Qt shared libraries and produce a package containing your application and those shared libraries in a form that is easily distributed. But if that's the case, why choose to use pyqtdeploy rather than one of the other tools available?
> 
> In other words, in normal circumstances, you choose to use pyqtdeploy because you *need* to build PyQt etc from source. If you don't *need* to, use something else.
> 
> Building from source, particularly Qt, is difficult. I certainly wouldn't update my sysroot every time I rebuilt my application. As a rule of thumb I would re-build my sysroot (with appropriate versions at the time) once a year. Assuming a typical agile timetable I would rebuild my application every couple of weeks. Even if you have to update your sysroot more often (because of a changing dependency) then stick with the same version of Qt etc.
> 
> Regarding cmake replacing qmake, I don't see that it makes things better or worse - just different. The change is primarily a cost saving exercise.
> 
> Phil


This clarification of principles is quite helpful since I have never discussed such principles with anyone.

My takeaway: Yes, it’s just hard to build everything from source and I should do this less often.

Qt releases are buggy enough (TableView is ridden with basic problems) that it is often advantageous to rebuild a sysroot when new versions come out. This could be mitigated to some degree by sticking with more mature Qt tech.

A third reason to use pyqt is that it is the only tool that actually works - at least in my experience. That is a more significant reason than the other two, in my opinion. It also provides a single deployment pathway for windows, macOS, and iOS, the latter of which is a pain to deploy pyqt to. To me, a single executable is certainly valuable to both obscure proprietary code and simplify distribution across platforms.

> 
> 
>  if on windows at all. If I am right, then that is a shame.
> 
> 
> Are you only referring to the case where pyqtdeploy is involved? 
> 
> I don't use pyqtdeploy, but I build a SIP extension on windows (which wraps a Qt based c++ library) and I don't build Qt or PyQt from source. Now that I've moved to sip5 I don't have to build sip either. I install pyqt5 and sip5 from pypi and then install the libs/binaries for the Qt version used to build pyqt from the qt website.
> 
> If you only meant in relation to pyqtdeploy then, fair enough... 
> 
> - mh


I hijacked & conflated topics in this thread. My apologies.

One topic was to point out how difficult it is to develop sip extensions on windows, let alone on both Mac and windows. I can’t see how you were able to build a sip extension without sip.h or the PyQt .sip files, which are not included in the pip extensions. Maybe you could explain how you do this?

Another topic has to do with pyqtdeploy generating qmake files instead of cmake files, and whether this would solve the problem of having to build from source to get the sip.h, dll stubs, and PyQt5 .sip files, not to mention qmake. I should not have conflated this topic with the question of making it easier to get a “dev” PyQt5 stack capable of building an pyqt app that contains a PyQt5 extension.

Maybe some innovation will come along where it will be easy to build a dev sysroot for the pyqtstack on macOS and windows. For example, I still can’t even get my app to build and run on windows, let alone debug the C++ code.

-Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20200827/ac111daa/attachment.htm>