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 __________________________ ------------------------------------------------------------------------------ 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
