Menu
▾
▴
Re: [Plplot-devel] Is Qt5 supported?
|
From: RM <rc...@ve...> - 2014-03-11 18:50:04
|
<div style="FONT-FAMILY: Arial; COLOR: rgb(0, 0, 0); FONT-SIZE: 12px"><div>Hi Alan,</div><div><br /></div><div>I understand! Thank you for the detailed response.</div><div><br /></div><div>In case you're interested, a couple of references on how cmake & Qt5 support play together are MathGL (http://mathgl.sourceforge.net/doc_en/Main.html) and VTK (http://www.vtk.org/). And, yes, I believe they both require cmake 2.8.</div><div><br /></div><div>Ok, thanks again.</div><div><br /></div><div>Cheers,</div><div>RM</div><div> </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/11/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-11 01:56-0500 RM wrote:<br /><br />> Thanks Alan. <br />> <br />> I'm willing to give it a try.  I think the migration on the Qt-side shouldn't be much more than changing include names and the .PRO<br />> file, if you have one.<br />> <br />> For my setup, I've compiled Qt5 myself and have placed it in /opt.<br />> <br />> How can I get PLplot to find this custom Qt installation?  Is there an environment variable or cmake switch?<br /><br />Good question!<br /><br />That stimulated me to look deeper, and it turns out that to even try<br />Qt5 is a lot more difficult than I thought. The PLplot build system<br />is, of course, CMake-based, and CMake provides an "all in one" find<br />module for Qt4 (which we use). However, there were some fundamental<br />issues with that approach such as Qt4 updates would not be supported<br />by CMake until a new version of CMake was released. Therefore, the<br />CMake and Qt5 developers have jointly decided to use a much different<br />approach with Qt5, where the Qt5 project provides the CMake functions<br />and data required to find components of Qt5. But that approach has<br />required some fundamental infrastructure changes in CMake also. The<br />result of these changes is that finding Qt5 components is a very<br />different proposition than finding Qt4 components. Furthermore, if you<br />look at<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> where<br />the new methods the PLplot build system would have to use to find Qt5<br />components are documented, those methods appear not to be stabilized<br />even yet. For example, the latest major change in the CMake<br />infrastructure to support this new approach occurred relatively<br />recently (for CMake-2.8.11).<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 />RM, I am sure you are disappointed by the substantial delay I think we<br />will need before we can support even finding Qt5 with our build<br />system. But in fact it is still early days for Qt5.x so such delays<br />should be expected. Meanwhile, I highly encourage you to try Qt4 for<br />now.<br /><br />Thanks for your good question above!<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> |
