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

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

  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

* The PyQt5 case

  The PyQT developers (consistent with their deprecation warning for the PyQt4 
  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 
  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

  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 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

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Plplot-devel mailing list

Reply via email to