[Plplot-devel] Finding the sip system directory and sip command flags for PyQt4 and PyQt5

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

Our build system's abilities to find the sip system directory and sip
command flags for PyQt4 and PyQt5 are not implemented very well. So
after the 5.13.0 release has been completed, I want to improve this
situation.

The current issues that will be part of the 5.13.0 release are as follows:

* The PyQt4 case

   In this case we currently depend on the pyqtconfig Python module to
   find the sip system directory and sip command flags, and although
   both the Debian and Cygwin packagers of PyQt4 provide this
   deprecated (by the PyQt4 developers) module, the MinGW-w64/MSYS2
   packager of PyQt4 does not.  For more details about this situation,
   see the recent discussion on the MSYS2 mailing list that Arjen
   started with the subject line "How to complete the installation of
   PyQt4?" Arjen is going to submit a MinGW-w64/MSYS2 bug report
   concerning this MinGW-w64/MSYS2 issue.  However, they may decide not to
   supply this deprecated module, and by definition of what deprecated
   means, it is virtually guaranteed that all software distributions
   will eventually stop providing pyqtconfig so we have to find
   an alternative to use for our build system.

   The PyQt4 developers have decided to deprecate this module because
   they claim all it is really good for is to determine the sip system
   directory and sip command flags where other alternatives exist to
   determine those. That turns out to be our exact use case (see
   cmake/modules/qt.cmake) so using those alternatives does appear to be
   a promising approach.  Indeed, from
   <http://pyqt.sourceforge.net/Docs/PyQt4/build_system.html>) it does
   appear that you can determine the sip flags without the pyqtconfig
   module using PyQt4.QtCore.PYQT_CONFIGURATION which is

   "a dict that describes how
   PyQt was configured. At the moment it contains a single value called
   sip_flags which is a string containing the appropriate -t and -x
   flags."

   So that alternative looks OK.

   At this stage it is not clear what is the alternative to using
   pyqtconfig to find the sip system directory, but I believe the
   "fool-proof" approach here is to determine a standard sip file that
   is guaranteed to always be installed in that directory, and use the
   CMake find_path command to find the directory that contains that
   file.

* The PyQt5 case

   The PyQT developers (consistent with their deprecation warning for the PyQt4 case)
   do not provide the pyqtconfig Python module at all for this case.

   So our current approach is to use the above PYQT_CONFIGURATION method for determinng
   sip flags, and it appears to work (at least on Linux but probably on
   all other systems as well).  But our current approach to determining
   the sip system directory is problematic.  For example, it has
   the comment

# FIXME: This is almost surely wrong

   for the WIN32 AND NOT CYGWIN part of the logic that would
   have been used if Arjen had tried out Qt5 (and PyQt5) on
   MinGW-w64/MSYS2.

   So I think the solution here is to try the idea I had above
   for determining the sip system directory, but we will need
   to experiment on all platforms to find out what is the best approach.

While writing the above summary, I *finally* remembered to search our
mailing list archive for previous mentions of pyqtconfig, and it turns
out that Greg Jung thoroughly discussed this issue two years ago!  In
fact, at that time Greg sent me in an off-list e-mail a patch to deal
with the "missing pyqtconfig issue" for pyqt4 that attempted to find
the sip system directory in what looks like a fairly problematic way
and the sip command flags using the above PYQT_CONFIGURATION way. I
didn't apply that patch at the time because of style issues in it, and
because of the problematic nature of how the sip system directory was
found.  Also, Greg said at the time that as a result of his patch our
build system configured the pyqt4 component build without any obvious
configure-time issues, but the actual build itself failed.

So it appears that after the release of 5.13.0, Arjen and I have a
relatively small amount of work to do to figure out the remaining
problematic configuration issues for determining the sip system
directory for pyqt4 and pyqt5 on Cygwin and MinGW-w64/MSYS2.  But then
after that is all solved it is possible (unless MinGW-w64/MSYS2 has
been improved in the last two years in this regard) that additional
work might be required to get both pyqt4 and pyqt5 built and running
properly on MinGW-w64/MSYS2.  And Arjen will likely want to make
similar tests of both pyqt4 and pyqt5 on Cygwin (since interactive
testing on Cygwin has not been done very often in the past and never
for Qt5), and he might turn up some configure, build or run time
issues that we have to address in that case as well.

In sum, the goal is to have a good run-time experience for our pyqt4
(if we are using Qt4) or our pyqt5 (if we are using Qt5) components on
both MinGW-w64/MSYS2 and Cygwin similar to what is now possible for
Linux.  To achieve that goal is obviously going to take quite a bit of
testing and development effort, but we do have a good start and at
least the remaining configuration issues when we move completely away
from the deprecated pyqtconfig Python module are now clear.  So I hope
we do reach this goal in the early stages of the release cycle just
after 5.13.0 is released, and to remind me of that possibility I have
summarized what needs to be done in my post-5.13.0 ToDo list.

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
__________________________