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. -- Giovanni Bajo _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde