[PyKDE] SIP Roadmap

[Phil Thompson]

On Friday 03 January 2003 1:12 pm, gvermeul at grenoble.cnrs.fr wrote:
> > On Friday 03 January 2003 11:46 am, gvermeul at grenoble.cnrs.fr wrote:
> > > > For those interested I've added a SIP Roadmap to the website at
> > > > http://www.riverbankcomputing.co.uk/sip/roadmap.php which describes
> > > > the main objectives and features for SIP v4.
> > > >
> > > > Comments welcome.
> > >
> > > As author of PyQwt, an extension package that I support also on
> > > Qt-230-NC, I have the following comments:
> > >
> > > (1) wrt the obeying to the Python API export rules. This also
> > > facilitates the link step on other platforms than MacOS/X: under
> > > current scheme this is a minor problem on Posix systems, but on
> > > Windows, it means rebuilding PyQt-NC and sip-NC to rebuild the
> > > necessary *.exp and *.lib. Great!
> >
> > I hadn't appreciated that. I'll try and remember to include a
> > sub-package, excluded from the "Typical" installation, that includes the
> > .exp and .lib files. Remind me when I forget.
> >
> > > (2) wrt to the limitation to Qt >= 3.0.0. This will make it more
> > > difficult for me to keep PyQwt compatible with Windows (I have no
> > > commercial version for Qt, neither for PyQt). Let me point out that I
> > > know of at least 2 companies with a commercial license for PyQt that
> > > are also using PyQwt.
> >
> > Actually the real problem is that (1) requires qmake rather than tmake. I
> > don't think there will be an issue with Qt itself.
>
> I think that you are wrong, here. See below.
>
> > > From a more general point of view:
> > >
> > > (3) Using the new-style Python-2.2 classes allows to map a C++
> > > inheritance tree to Python (I have played with this, writing a wrapper
> > > for Fltk by hand).
> > > This is a great step forward for sip, also as a wrapper tool for other
> > > libraries than Qt. In this respect, it would be nice if there is
> > > support for two Python sip extensions modules, "sipQt" and "sip", with
> > > and without Qt support.
> >
> > How would that help? If you use a non-Qt wrapper with a Qt-sip module, it
> > will work fine. If you try a Qt wrapper with a non-Qt-sip module you will
> > get an exception.
>
> I suppose you are right. I just had the idea that it would be more clear
> if you use sip to wrap classes for systems without Qt.
>
> > > In summary, sounds great, but I'd like to keep support for Qt >= 2.3.0.
> >
> > As I said, it comes down to tmake/qmake. tmake doesn't support plugins
> > which is what a pure Python module is - but maybe that won't be an issue
> > for Windows and UNIX. It will be worth playing with once snapshots of SIP
> > v4 appear.
>
> IMHO, the point that you are missing is that Qt style plugins and Python
> extension module plugins are two different type of plugins. If you are
> using the Python import API, the extension module is a shared library
> from the point of view of Qt (or the linker). The import_QtOtherExtension()
> statement in the initQtExtension() function takes care of dynamic loading.

The point is that on some platforms plugins are different from shared 
libraries - MacOS/X being the most relevant example. tmake doesn't know about 
those differences (ie. the different flags that need to be passed to the 
link/loader) - qmake does.

> Python does not care about Qt style type of plugins.
>
> So, I am pretty confident that you can keep support for Qt < 3.0.0.

If it turns out that the only platform with this issue is MacOS/X (but I would 
also have concerns about AIX) then the problem goes away because it needs Qt3 
anyway.

What I might do is allow tmake to be used with SIP v4, but say it is 
unsupported until it is proved to be Ok.

Phil