On 2015-09-04 09:26-0400 Hazen Babcock wrote: > >> Im working on MSYS2 which brings in all of the latest-and-greatest, >> ground-breaking compatibility-crushing versions, of which python is of >> course the worst offender. >> >> I'm trying to get the PyQT4 binding to work in MSYS2. All of the >> prerequisites >> are ready and I've patched the plplot/cmake scripting to accept the PYQT >> generated via configure-ng.py (as distinct from configure.py) >> http://pyqt.sourceforge.net/Docs/PyQt4/build_system.html#module-PyQt4.pyqtconfig >> The cygwin64 distribution has the up-to-date sip modules, but built with >> configure.py; >> it flies through the pyqt4 bindings without error. >> >> The problem I'm getting is that the generated .cpp files do not compile >> just to demonstrate, the first error: >> >>> ./sipplplot_pyqt4QtExtWidget.cpp: In member function 'void >>> sipQtExtWidget::disconnectNotify(const QMetaMethod&)': >>> ./sipplplot_pyqt4QtExtWidget.cpp:370:41: error: no matching function for >>> call to 'sipQtExtWidget::disconnectNotify(const QMetaMethod&)' >>> QtExtWidget::disconnectNotify(a0); >>> ^ >>> In file included from >>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qiodevice.h:46:0, >>> from >>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qdatastream.h:46, >>> from >>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qmetatype.h:49, >>> from >>> D:/mingw/msys32/mingw32/include/qt4/QtCore/QMetaType:1, >>> from >>> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipAPIplplot_pyqt4.h:13, >>> from >>> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipplplot_pyqt4QtExtWidget.cpp:7: >>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note: >>> candidate: virtual void QObject::disconnectNotify(const char*) >>> virtual void disconnectNotify(const char *signal); >>> ^ >>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note: no >>> known conversion for argument 1 from 'const QMetaMethod' to 'const char*' >> >> =============== >> Note: On cygwin the generated code (sipplot_pyqt4QtExtWidget.cpp) is >> different: >> >> void sipQtExtWidget::disconnectNotify(const char*a0) >> { >> sip_gilstate_t sipGILState; >> PyObject *sipMeth; >> >> sipMeth = >> sipIsPyMethod(&sipGILState,&sipPyMethods[0],sipPySelf,NULL,sipName_disconnectNotify); >> >> if (!sipMeth) >> { >> QtExtWidget::disconnectNotify(a0); >> return; >> } >> And it compiles without error. >> =============== >> >> So who's fault is it? is there a switch to be thrown in the qt >> configuration so that the headers are compatible with the >> different code generation? > > This looks a lot like this issue in a different project: > https://github.com/Homebrew/homebrew/issues/41464 > > Which seems to be that sip generates for qt5 but the build uses qt4. > Unfortunately I have not seen a solution and I also can't find anything > on the PyQt list about this problem. > > Perhaps it is possible to tell sip which version of qt to use? > > Does MSYS2 come with both Qt4 and Qt5? Maybe if you hide qt5 sip will do > the right thing?
To Hazen, Arjen, and Greg: To answer Hazen's question, from <http://sourceforge.net/p/msys2/wiki/Packages/> there are both pyqt4-related and pyqt5-related packages available for MinGW-w64/MSYS2. And similarly for qt4 and qt5. Furthermore, in the past Greg has told me that the qt4-related packages conflict with the qt5-related packages so you have to choose one or the other but not both. Indeed, the cmake package depends on qt5 so Greg built his own version of CMake that did not have that dependency so he could consistently use qt4-related MinGW-w64/MSYS2 packages for his recent successful comprehensive test on that platform (with pyqt4 necessarily disabled due to issues like above). I also notice there is just one sip package on this platform. My guess is that Hazen nailed it, and that package probably only generates qt5-compatible code. So if Greg continues with qt4-only approach, he may just have to always disable pyqt4 or else build his own MinGW-w64/MSYS2 sip package that is configured to generate QT4 code rather than Qt5 code. @Greg: another alternative to the above pure qt4 approach is to try a pure qt5 approach, i.e., uninstall all qt4-related (and pyqt4-related) packages and install the qt5-related packages instead. An immediate side benefit for you _and the rest of our MSYS2 users_ is this approach makes it possible to use the MinGW-w64/MSYS2 packaged version of CMake rather than having to build CMake. If you decide to explore this possibility, it will be necessary for you to use the -DPLPLOT_USE_QT5=ON cmake option for the PLplot build system. When I try that approach on Linux with epa_built Qt5, I get good results so there is a good chance you will not have any issues with that approach on MinGW-w64/MSYS2. The big caveat for -DPLPLOT_USE_QT5=ON is it automatically disables pyqt4 for obvious reasons which is why the above is just a first step toward supporting a pyqt5 binding for PLplot. Creating that binding is obviously cutting-edge stuff, and will likely require a lot of work to get right. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
