[PyKDE] Static compilation of PyQt

[Phil Thompson]

On Friday 03 March 2006 11:15 am, Giovanni Bajo wrote:
> Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
> > 1. Changing the API isn't acceptable, "import qttable" must continue
> > to work.
>
> I tried adding qttable.py which simply contained "from qt import *". I
> found out that the main breakage still happens because, since qt contains
> all the symbols, people just import qt and forget about importing the other
> modules. This is something which can't be "manually" cured. Surely SIP
> could create a "qt.py" wrapper around qt.pyd which imports only the symbols
> originally contained in qtmod, but you can see that I couldn't do this
> manually :)

The way to do it for PyQt3 would be...

%ConsolidatedModule _qt
%Include qtmod.sip
%Include qttablemod.sip

Every "public" module would have the same module objects as they would with a 
non-consolidated build. Only the "private" _qt.pyd module would have 
everything.

> > 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.
>
> Agreed. It's fine by me. I believe that existing PyQt3 Windows commercial
> customers might find this interesting too, but it's fine to have this in
> PyQt4 as a start.
>
> > 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.
>
> I was proposing to use Qt's linking status as a flag to switch compilation
> type in PyQt too for a simple reason: if Qt is linked statically, you
> cannot build PyQt without the consolidated module. You would end up with
> very big qt.pyd, qttable.pyd, qtgl.pyd, all of them including different
> copies of code from qt-mt.lib, and thus being incompatible. So my idea is
> that, if Qt is built statically (and -k is not specified for configure.py),
> PyQt could be built as a consolidated module. In a way, you're just
> "fixing" the fact that PyQt couldn't be usable with a static Qt, were it
> built without the consolidated module.
>
> ... but if you prefer a configuration option is fine by me.
>
> I'm not familiar enough with SIP to do anything though. So if we're going
> this way (using SIP), I guess I can't really help you more than testing the
> results
>
> :)

I'm keen to do this because I (eventually) want to produce a smallish Windows 
installer that includes a complete (other than Python) PyQt development 
environment. But I'm not going to hold things up to do it (ie. it will be SIP 
v4.5), and Detlev is getting impatient for QScintilla v2. ;)

Phil