On Friday 03 January 2003 1:12 pm, [EMAIL PROTECTED] wrote: > > On Friday 03 January 2003 11:46 am, [EMAIL PROTECTED] 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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
