On Friday 03 March 2006 9:39 am, Gerard Vermeulen wrote: > On Fri, 3 Mar 2006 08:57:50 +0000 > > Phil Thompson <[EMAIL PROTECTED]> wrote: > > On Thursday 02 March 2006 11:31 am, Giovanni Bajo wrote: > > > Hello, > > > > > > For the past few months, I have been using a statically-compiled > > > version of PyQt. "Statically" here means that it's still an external > > > module (.pyd) but it does not depend on the external C++ Qt DLL: the > > > module is totally self-contained. This bring several advantages: > > > > > > - Size. A static version of PyQt (snapshots of December) with Qt 3.3.5, > > > and modules Core + OpenGL, is 1.1 Mb (compressed with UPX). When using > > > Core + OpenGL + Canvas + Table, size is 1.3 Mb. The size win is given > > > by the saving of almost 1,5 Mb of import and export sections > > > (respectively in qt.pyd and qt-mt335.dll), which are not necessary > > > anymore. The sections are *very* large because C++ name mangling is > > > bloated as we all know. > > > > > > - Ease of mainteance. A single file is easier to update, copy around, > > > and whatnot. I have several versions of PyQt and Qt in my computer and > > > I don't have to wonder anymore which version of PyQt goes with which Qt > > > DLL. > > > > > > - Minor startup speed benefit. A *cold* import of PyQt on my computer > > > is now roughly twice as faster than before (0.4 seconds instead of 0.9 > > > seconds). "Cold" import means after flushing all disk caches. Notice > > > that this is the time which matters most for users as they tipically > > > don't execute GUI applications many times in a row and thus they do not > > > benefit from OS caching. > > > > > > > > > It also brings a couple of disadvantages: > > > > > > - Change of API. Since you need to have a single file qt.pyd with all > > > the modules in it, there are name changes in the application. For > > > instance QTable is imported from "qt" and not "qttable". This doesn't > > > matter much if you use the "from qt import *" syntax, but it still > > > poses a compatibility problem (existing code using "from qttable import > > > *" won't work). > > > > > > > > > I would like to stress that the size improvement is a very good sell > > > point for PyQt4/Win. Currently, users shipping Python GUI applications > > > under Windows (with tools like PyInstaller and py2exe) always complain > > > of the fact that the final size of the application is too large > > > (especially compared with the small Python source code that produces > > > it). wxWidgets is a huge bloat of some 10Mb, for instance, but given > > > that Qt3 wasn't free for Windows there weren't many options for free > > > development. With the advent of Qt4 and PyQt4, I'm sure many will > > > evaluate PyQt4, and will surely look at the distribution size. > > > > > > Alas, I haven't looked into PyQt4 yet (and still won't for some > > > months), so I can't really contribute a patch for there. But I do have > > > a script to compile PyQt3 statically which I'm willing to contribute. I > > > would like this to become part of the official build system for PyQt. > > > Notice that currently compiling PyQt with a statically-compiled Qt > > > leads to a crash if you use more modules (as each pyd, eg. qttable.pyd, > > > will contain a full copy of the Qt C++ code). So this might simply be > > > the default way of building PyQt when a statically-compiled Qt is > > > detected. > > > > > > BTW, for PyQt3, the steps are really easy: > > > > > > 1) Compile Qt statically (produce qt-mt.lib) > > > 2) Merge all the modules of PyQt you're interested in into qtmod.sip > > > (you *must* build only qt.pyd). > > > 3) Build qt.pyd only. > > > > > > I have a Python script which does the module merging. > > > > I think this is a good idea, but... > > > > 1. Changing the API isn't acceptable, "import qttable" must continue to > > work. > > > > 2. I don't want to do this for PyQt3 - unless doing it for PyQt4 makes it > > trivial to do for PyQt3. The primary beneficiary will be Windows GPL > > users. > > > > You can solve 1. by flipping Gerard's idea around for Qt.py and > > generating a qttable.py that contained... > > > > from qt import QTable, QTableItem, ... > > > > The problem with this is that this is probably better handled by SIP > > rather than the build system. A SIP implementation would also go a long > > way to solving 2. It would probably also generate a C module rather than > > a Python one. > > > > SIP could be changed to support something like... > > > > %ConsolidatedModule qt > > %Include qtmod.sip > > %Include qttable.sip > > > > ...and PyQt's configure.py would have an extra flag to specify that the > > consolidated version should be built. It's up to you whether the Qt you > > are linking against is static or dynamic. > > Support for static linking is a great idea, but I am a little bit worried > that it won't be possible to use PyQt addon packages (PyQwt for instance) > with a statically linked PyQt.
I think you would be able to use it, just that there would be some bloat as you lost the benefits of sharing the Qt DLLs. I'm thinking of this as a packaging convenience for the majority of users for which standard Qt is all they need. It's a compromise between convenience and flexibility - there is nothing stopping somebody building things to meet their own specific requirements. There are similar issues in deciding, for example, which SQL drivers you include. Phil _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
