Menu
▾
▴
Re: [Plplot-devel] Is Qt5 supported?
|
From: RM <rc...@ve...> - 2014-03-13 18:07:54
|
<div style="FONT-FAMILY: Arial; COLOR: rgb(0, 0, 0); FONT-SIZE: 12px"><div> Hi Alan,</div><div><br /></div><div>I downloaded the latest PLplot code and ran cmake against it with the following command:</div><div><br /></div><div><div>cmake28 -DPLPLOT_USE_QT5=ON -DCMAKE_PREFIX_PATH=/opt/qt5.2.1_x64/ ..</div></div><div><br /></div><div>It runs through and dies with a QT SVG issue:</div><div><br /></div><div>----------------------------------</div><div>CMake Warning at /opt/qt5.2.1_x64/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:273 (find_package):</div><div> Could not find a package configuration file provided by "Qt5QtSvg" with any</div><div> of the following names:</div><div><br /></div><div> Qt5QtSvgConfig.cmake</div><div> qt5qtsvg-config.cmake</div><div><br /></div><div> Add the installation prefix of "Qt5QtSvg" to CMAKE_PREFIX_PATH or set</div><div> "Qt5QtSvg_DIR" to a directory containing one of the above files. If</div><div> "Qt5QtSvg" provides a separate development package or SDK, be sure it has</div><div> been installed.</div><div>Call Stack (most recent call first):</div><div> bindings/qt_gui/CMakeLists.txt:48 (qt5_use_modules)</div><div><br /></div><div><br /></div><div>CMake Error at /opt/qt5.2.1_x64/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:275 (message):</div><div> Can not use "QtSvg" module which has not yet been found.</div><div>Call Stack (most recent call first):</div><div> bindings/qt_gui/CMakeLists.txt:48 (qt5_use_modules)</div><div><br /></div><div>-- Configuring incomplete, errors occurred!</div><div>----------------------------------</div><div><br /></div><div><br /></div><div>The Qt SVG file it's looking for appears to be named incorrectly -- the file is in fact called "Qt5SvgConfig.cmake" not "Qt5QtSvgConfig.cmake"</div><div><br /></div><div>Was this a typo in the script? I haven't dug into the error -- I figured you'd probably know straight away.</div><div><br /></div><div>Cheers,</div><div>RM</div><div> </div><div style="border-top:1px solid #bcbcbc;margin:5px 0px;"></div><span style="font-size:12;font-family:arial;color:#000000;">On 03/12/14, <span>Alan W. Irwin<ir...@be...></span> wrote:</span><div> </div><div style="font-size:12;font-family:arial;color:#000000;">On 2014-03-12 19:48-0000 Andrew Ross wrote:<br /><br />> On Wed, Mar 12, 2014 at 11:10:07AM -0700, Alan Irwin wrote:<br />>> On 2014-03-11 11:22-0700 Alan W. Irwin wrote:<br />>><br />>>> Therefore, my conclusion is we should wait for something like another<br />>>> year before we attempt to make PLplot work with Qt5. There<br />>>> are several benefits to such a substantial delay.<br />>>><br />>>> (1) A delay will allow us to bump our minimum CMake version (currently<br />>>> 2.8.9) to 2.8.11 which is currently required to take advantage of the<br />>>> latest CMake infrastructure support for finding Qt5 components.<br />>>> Typically we wait to bump that minimum version until Debian stable<br />>>> includes that minimum version of CMake as a signal that most modern<br />>>> Linux distributions are likely to carry at least that minimum version<br />>>> of CMake. The release date of the next Debian stable version is still<br />>>> TBA, but it should roughly be a year or so from now if the Debian<br />>>> track record for the length of previous release cycles continues for<br />>>> this Debian release cycle.<br />>>><br />>>> (2) Assuming CMake-2.8.11 constitutes the last big change in<br />>>> infrastructure support, a delay also allows the Qt5 part of the find<br />>>> methods to completely settle down to take advantage of that new<br />>>> infrastructure.<br />>>><br />>>> (3) A delay allows the Qt5 software itself to settle down. PLplot<br />>>> triggered a number of bugs that existed for Qt4.x before Qt4.5 was<br />>>> released, and the same type of bug issues are likely to occur for<br />>>> early Qt5.x versions as well.<br />>>><br />>>> (4) A delay gives me a chance to get access to a well-debugged version<br />>>> of Qt5.x myself. For example, I am likely to move to Debian testing<br />>>> (which allows Qt5 to be installed) within the next year or else that<br />>>> version will be released as the next Debian stable release. Such<br />>>> access will allow me to implement (as de facto chief maintainer for<br />>>> our build system) the build-system changes needed to allow users<br />>>> access to Qt5.<br />>>><br />>><br />>> RM, despite all those caveats, I have changed my mind about delaying<br />>> this since I have been recently most encouraged by the helpful<br />>> comments on the CMake mailing list concerning finding Qt5. So later<br />>> today I will try to implement an experimental option for the PLplot<br />>> build system so that it will be able to find Qt5. Of course, it will<br />>> all be blind development on my part since I don't currently have<br />>> access to Qt5, but it turns out finding Qt5 is actually pretty simple<br />>> so there is a reasonable chance this experimental option will work for you<br />>> immediately or after one iteration when I deal with any build-system<br />>> issues that you find with Qt5.<br />>><br />>> Once that build-system option works for you, it should allow you to<br />>> see whether there are any API changes between Qt4 and Qt5 that you<br />>> have to be concerned with.<br />><br />> Alan,<br />><br />> If you are able to implement this I'll try using my Debian unstable<br />> pbuilder environment. Should give fairly easy access to Qt5.<br /><br />To Andrew and RM:<br /><br />I have implemented an experimental version of Qt5 find support as of<br />revision 13050 in our svn trunk version. This support defaults to OFF<br />so to turn it ON you must specify the cmake command-line option<br />-DPLPLOT_USE_QT5=ON.<br /><br />I have tested the -DPLPLOT_USE_QT5=ON case for my strictly Qt4<br />platform. As expected it warned me that it could not find Qt5 and<br />then it fell back to looking for Qt4 (just as I designed it). I also<br />tried the test_qt_all target which does what its name implies. All was<br />well there indicating my fairly extensive Qt5-related build system<br />changes hadn't screwed up anything with our current Qt4 support.<br /><br />Anyhow, for those here like you guys with access to Qt5, please give<br />-DPLPLOT_USE_QT5=ON a try. Note this Qt5 support is only bare bones<br />at this stage (certain things like pyqt and pkg-config Qt support are<br />disabled for this case as denoted by a FIXME comment). But we can add<br />all the bells and whistles later once the fundamental question (does<br />the qt device driver build and run properly with Qt5) is answered.<br /><br />Note if your Qt5 installation is in a non-standard location, then<br /><a class="parsedLink" href="http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html" target="_blank">http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html</a><br />recommends specifying the CMAKE_PREFIX_PATH environment variable to<br />help CMake locate Qt5. You will likely also have to use<br />LD_LIBRARY_PATH for this case since RPATH support for a non-standard<br />QT5 installation is not implemented in our build system yet.<br /><br />Also with regard to API changes, one guy on the CMake list gave me<br />the link <<a class="parsedLink" href="https://github.com/Kitware/VTK/commit/384636ec9f4" target="_blank">https://github.com/Kitware/VTK/commit/384636ec9f4</a>> showing<br />what the VTK project did to adjust from Qt4 only to support for<br />both Qt4 and Qt5. The code changes to adapt to the new Qt5 API do<br />not look that bad. In our case, if something like that has to<br />be done, please use the PLPLOT_USE_QT5 macro that is now #defined<br />in plplot_config.h to distinguish between the Qt4 and Qt5 cases.<br /><br />@Andrew: It is great that you have access to Qt5. Also because of<br />your high degree of expertise concerning our build system, I encourage<br />you to just go ahead and make any further Qt5-related build-system<br />changes that are required yourself rather than waiting for me to pass<br />judgement on what you think is necessary.<br /><br />Alan<br />__________________________<br />Alan W. Irwin<br /><br />Astronomical research affiliation with Department of Physics and Astronomy,<br />University of Victoria (astro<a class="parsedLink" href="http://www.phys.uvic.ca" target="_blank">www.phys.uvic.ca</a>).<br /><br />Programming affiliations with the FreeEOS equation-of-state<br />implementation for stellar interiors (freeeos.sf.net); the Time<br />Ephemerides project (timeephem.sf.net); PLplot scientific plotting<br />software package (plplot.sf.net); the libLASi project<br />(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);<br />and the Linux Brochure Project (lbproject.sf.net).<br />__________________________<br /><br />Linux-powered Science<br />__________________________<br /></div></div> |
