[PyQt] Consolidated module support: couple of bugs

[Phil Thompson]

On Friday 15 June 2007 4:54 pm, Giovanni Bajo wrote:
> Hi Phil,
>
> thanks for starting the consolidated module support in SIP!
>
> I have a couple of bugs to report:
>
> 1) In PyQt4's configure.py, around line 217, it creates the sip/Qt
> directory using os.mkdir. This fails if the directory already exists
> (eg: the second time you run configure.py). I fixed it by guarding the
> creation with os.path.exists.
>
> 2) In PyQt4, sip/QtCore/qobject.sip, around line 573, there's an
> explicit reference to the symbol "sipNm_QtCore_pyqtSignature" in
> hand-written code. That won't work with consolidated module: it needs to
> be "sipNm_Qt_pyqtSignature".
>
> 3) Under Windows, when you build Qt4 as static libraries (configure.exe
> -static), the libraries' filenames won't have the trailing "4". For
> instance, QtCore's library is called "QtCore.lib", not "QtCore4.lib".
> This needs to be fixed twice in sipconfig.py:
>
>    a) around line 416, win_shared is incorrectly detected as True. I
> couldn't follow how that self.config.qt_winconfig is generated by
> PyQt4's configure.py though, so I don't know why it thinks I have
> compiled Qt with shared libraries. [If win_shared is True, the QT_DLL
> symbol will be defined, which is wrong and will fail at link-time].
>
>    b) around line 803, there's the code that adds the trailing "4"
> character to library names. This code needs not to be executed if Qt is
> compiled as static libraries.
>
> 4) If Qt was compiled as static libraries, it doesn't make sense to run
> PyQt4's configure.py without either -k or -g. You might want to add a
> sanity check about this, since otherwise the whole PyQt4 compilation
> would theoretically succeed, but each PyQt module would contain a copy
> of Qt's code, probably causing hard crashes later at runtime.
>
> Anyway, even with the above fixes, I was unable to compile PyQt4 with
> consolidated module support. Next problem is something related to
> qpointerpath.h not being included when compiled init_QPointF (the
> "extender", whatever that means in SIP's terminology). I guess the
> support isn't fully ready yet...

It's nowhere near ready. The only thing I'm trying to make sure of is that a 
normal build continues to work. It will be another couple of weeks at the 
very least.

Phil