Re: [Plplot-devel] Python, anyone?

[Alan W. I. <ir...@be...>]

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
__________________________