From: RM <rc...@ve...> - 2014-03-11 06:56:17
|
<div style="FONT-FAMILY: Arial; COLOR: rgb(0, 0, 0); FONT-SIZE: 12px"><div>Thanks Alan. </div><div><br /></div><div>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 file, if you have one.</div><div><br /></div><div>For my setup, I've compiled Qt5 myself and have placed it in /opt.</div><div><br /></div><div>How can I get PLplot to find this custom Qt installation? Is there an environment variable or cmake switch?</div><div> </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/10/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-10 16:38-0500 RM wrote:<br /><br />> Despite searching, I couldn't find any information on this so I'll ask here -- Will PLplot compile against Qt 5.x?<br />> <br />> ln running cmake on PLplot 5.10.0, I see a number of references to "Qt4".<br />> <br />> Can PLplot be made to work/compile with Qt5?<br /><br />Not sure.<br /><br />> If not, is that capability on the roadmap?<br /><br />We don't have an offical roadmap, but, yes, that is an obvious next<br />step for one of our best and most well-supported device drivers. Qt5<br />is not available for Debian stable (the platform I run), but it is<br />available for Debian testing (what will turn into the next Debian<br />stable release) and other cutting-edge Linux versons so I agree it<br />would be a good idea for us to get ready for it.<br /><br />Currently I have no idea whether the API changes between Qt4 and Qt5<br />affect us or not (see the first answer). According to<br /><<a class="parsedLink" href="http://qt-project.org/wiki/Transition_from_Qt_4.x_to_Qt5" target="_blank">http://qt-project.org/wiki/Transition_from_Qt_4.x_to_Qt5</a>> the<br />differences should not be huge. So by all means give Qt5 a<br />try (assuming you have access to it). If it works, fine. If not, we<br />would be most interested in any patch you implement to make PLplot<br />build and run without issues against Qt5.<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> |
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> |
From: RM <rc...@ve...> - 2014-03-12 19:29:15
|
<div style="FONT-FAMILY: Arial; COLOR: rgb(0, 0, 0); FONT-SIZE: 12px"><div>Hi Alan,</div><div><br /></div><div>Sure, I'd be glad to try it out.</div><div><br /></div><div>Also, if you don't want to wait on your end for the linux distros to pick up Qt5, you can download the source code here and compile it to any local directory:</div><div><br /></div><div>Qt page</div><div>http://qt-project.org/downloads</div><div><br /></div><div>Qt 5.2.1 source code</div><div>http://download.qt-project.org/official_releases/qt/5.2/5.2.1/single/qt-everywhere-opensource-src-5.2.1.tar.gz</div><div><br /></div><div>It uses the configure make system. So, you do something like this:</div><div><br /></div><div>./configure --prefix=/home/irwin/qt5.2.1 -opensource -confirm-license -platform linux-g++-64 -v</div><div>make -j9</div><div>make -j9 install </div><div> </div><div>On CentOS 6 I needed to also give configure the "-qt-xcb" switch and needed to either disable webkit, or install libicu and gperf for webkit to compile. On other distros, Qt5 may build straight away, as CentOS is more conservative than most.</div><div><br /></div><div>Cheers,</div><div>RM</div><div><br /></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-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 />So stay tuned.<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> |
From: Alan W. I. <ir...@be...> - 2014-03-12 21:37:24
|
On 2014-03-12 14:29-0500 RM wrote: > Hi Alan, > > Sure, I'd be glad to try it out. It should be ready to go. See the e-mail I just posted. > > Also, if you don't want to wait on your end for the linux distros to pick up Qt5, you can download the source code here and compile it > to any local directory: For the cmake/epa_build subproject of PLplot, I actually configure a working build of a "lite" version of Qt4 that in the interest of speed excludes a lot from the Qt4 build that PLplot does not need. So it should not be too much of a stretch to do the same thing for Qt5. But configuring a Qt build is always a bit tricky so that just adds one more possibility for stuff to go wrong. So I plan to wait until Andrew and you have PLplot success with well-debugged versions of the Qt5 build before I try using an epa_build of Qt5. 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 __________________________ |
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> |
From: Alan W. I. <ir...@be...> - 2014-03-13 19:32:51
|
On 2014-03-13 13:07-0500 RM wrote: > Hi Alan, > > I downloaded the latest PLplot code and ran cmake against it with the following command: > > cmake28 -DPLPLOT_USE_QT5=ON -DCMAKE_PREFIX_PATH=/opt/qt5.2.1_x64/ .. > > It runs through and dies with a QT SVG issue: > > ---------------------------------- > CMake Warning at /opt/qt5.2.1_x64/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:273 (find_package): > Could not find a package configuration file provided by "Qt5QtSvg" with any > of the following names: > > Qt5QtSvgConfig.cmake > qt5qtsvg-config.cmake > > Add the installation prefix of "Qt5QtSvg" to CMAKE_PREFIX_PATH or set > "Qt5QtSvg_DIR" to a directory containing one of the above files. If > "Qt5QtSvg" provides a separate development package or SDK, be sure it has > been installed. > Call Stack (most recent call first): > bindings/qt_gui/CMakeLists.txt:48 (qt5_use_modules) > > > CMake Error at /opt/qt5.2.1_x64/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:275 (message): > Can not use "QtSvg" module which has not yet been found. > Call Stack (most recent call first): > bindings/qt_gui/CMakeLists.txt:48 (qt5_use_modules) > > -- Configuring incomplete, errors occurred! > ---------------------------------- > > > The Qt SVG file it's looking for appears to be named incorrectly -- the file is in fact called "Qt5SvgConfig.cmake" not > "Qt5QtSvgConfig.cmake" > > Was this a typo in the script? I haven't dug into the error -- I figured you'd probably know straight away. This result is quite encouraging. CMake found the core part of Qt5 without issues, and this error is only for the subsequent attempt to find additional components. Furthermore, your analysis of this error was correct; I had misread the documentation and used a Qt prefix on the component names when I shouldn't have. Fixed in revision 13052. So thanks for your report, and please try again with that revision. 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 __________________________ |
From: RM <rc...@ve...> - 2014-03-13 21:12:04
|
<div style="FONT-FAMILY: Arial; COLOR: rgb(0, 0, 0); FONT-SIZE: 12px"><div>Hi Alan,</div><div><br /></div><div>Ok, got further! It made it through cmake, though I get a message about Pango missing, which doesn't make sense because I have Pango in the system...</div><div><br /></div><div>The make command bails on the QPrinter class now, and I think some re-writing will be necessary there.</div><div><br /></div><div><div>[ 26%] Building CXX object bindings/qt_gui/CMakeFiles/plplotqtd.dir/plqt.cpp.o</div><div>/u/rmancuso/Downloads/plplot-latest/plplot-code/bindings/qt_gui/plqt.cpp: In member function 'void QtEPSDevice::definePlotName(const char*, int)':</div><div>/u/rmancuso/Downloads/plplot-latest/plplot-code/bindings/qt_gui/plqt.cpp:617: error: 'PostScriptFormat' is not a member of 'QPrinter'</div><div>make[2]: *** [bindings/qt_gui/CMakeFiles/plplotqtd.dir/plqt.cpp.o] Error 1</div><div>make[1]: *** [bindings/qt_gui/CMakeFiles/plplotqtd.dir/all] Error 2</div><div>make: *** [all] Error 2</div></div><div><br /></div><div>First, according to the migration guide the location of QPrinter changed. You *may* need to modify line 48 of bindings/qt_gui/CMakeLists.txt to add printer support as follows:</div><div><div> qt5_use_modules(plplotqt${LIB_TAG} Svg Gui PrintSupport)</div></div><div><br /></div><div>But, secondly, the larger problem is that PostScript support has apparently been removed from Qt5. So, "QPrinter::PostScriptFormat" will not compile. See here: <a href="https://qt-project.org/forums/viewthread/24857">https://qt-project.org/forums/viewthread/24857</a></div><div><br /></div><div>So, unfortunately, I think you need to decide how to proceed/work around that issue code-wise.</div><div><br /></div><div>Cheers,</div><div>RM</div><div><br /></div><div style="border-top:1px solid #bcbcbc;margin:5px 0px;"></div><span style="font-size:12;font-family:arial;color:#000000;">On 03/13/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-13 13:07-0500 RM wrote:<br /><br />> Hi Alan,<br />> <br />> I downloaded the latest PLplot code and ran cmake against it with the following command:<br />> <br />> cmake28 -DPLPLOT_USE_QT5=ON -DCMAKE_PREFIX_PATH=/opt/qt5.2.1_x64/ ..<br />> <br />> It runs through and dies with a QT SVG issue:<br />> <br />> ----------------------------------<br />> CMake Warning at /opt/qt5.2.1_x64/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:273 (find_package):<br />> Could not find a package configuration file provided by "Qt5QtSvg" with any<br />> of the following names:<br />> <br />> Qt5QtSvgConfig.cmake<br />> qt5qtsvg-config.cmake<br />> <br />> Add the installation prefix of "Qt5QtSvg" to CMAKE_PREFIX_PATH or set<br />> "Qt5QtSvg_DIR" to a directory containing one of the above files. If<br />> "Qt5QtSvg" provides a separate development package or SDK, be sure it has<br />> been installed.<br />> Call Stack (most recent call first):<br />> bindings/qt_gui/CMakeLists.txt:48 (qt5_use_modules)<br />> <br />> <br />> CMake Error at /opt/qt5.2.1_x64/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:275 (message):<br />> Can not use "QtSvg" module which has not yet been found.<br />> Call Stack (most recent call first):<br />> bindings/qt_gui/CMakeLists.txt:48 (qt5_use_modules)<br />> <br />> -- Configuring incomplete, errors occurred!<br />> ----------------------------------<br />> <br />> <br />> The Qt SVG file it's looking for appears to be named incorrectly -- the file is in fact called "Qt5SvgConfig.cmake" not<br />> "Qt5QtSvgConfig.cmake"<br />> <br />> Was this a typo in the script? I haven't dug into the error -- I figured you'd probably know straight away.<br /><br />This result is quite encouraging. CMake found the core part of Qt5<br />without issues, and this error is only for the subsequent attempt to<br />find additional components. Furthermore, your analysis of this error<br />was correct; I had misread the documentation and used a Qt prefix on<br />the component names when I shouldn't have. Fixed in revision 13052.<br /><br />So thanks for your report, and please try again with that revision.<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> |
From: Alan W. I. <ir...@be...> - 2014-03-13 22:49:40
|
On 2014-03-13 16:11-0500 RM wrote: > Hi Alan, > > Ok, got further! It made it through cmake, though I get a message about Pango missing, which doesn't make sense because I have Pango in > the system... > > The make command bails on the QPrinter class now, and I think some re-writing will be necessary there. > > [ 26%] Building CXX object bindings/qt_gui/CMakeFiles/plplotqtd.dir/plqt.cpp.o > /u/rmancuso/Downloads/plplot-latest/plplot-code/bindings/qt_gui/plqt.cpp: In member function 'void QtEPSDevice::definePlotName(const > char*, int)': > /u/rmancuso/Downloads/plplot-latest/plplot-code/bindings/qt_gui/plqt.cpp:617: error: 'PostScriptFormat' is not a member of 'QPrinter' > make[2]: *** [bindings/qt_gui/CMakeFiles/plplotqtd.dir/plqt.cpp.o] Error 1 > make[1]: *** [bindings/qt_gui/CMakeFiles/plplotqtd.dir/all] Error 2 > make: *** [all] Error 2 > > First, according to the migration guide the location of QPrinter changed. You *may* need to modify line 48 of > bindings/qt_gui/CMakeLists.txt to add printer support as follows: > qt5_use_modules(plplotqt${LIB_TAG} Svg Gui PrintSupport) > > But, secondly, the larger problem is that PostScript support has apparently been removed from Qt5. So, "QPrinter::PostScriptFormat" > will not compile. See here: https://qt-project.org/forums/viewthread/24857 > > So, unfortunately, I think you need to decide how to proceed/work around that issue code-wise. Hi RM: Your report of no obvious cmake find issues (except for the unrelated Pango message) is quite encouraging for the Qt5 case. There does seem to be an overall computer industry trend to drop PostScript in favor of PDF. For example, we have just dropped the traditional PostScript form of our documentation (but kept the PDF, html, info, and man forms). So I am not surprised that Qt5 has dropped PostScript (as also confirmed by the thread at <http://qt-project.org/forums/viewthread/24857/> ). If you look at include/qt.h, drivers/qt.cpp, and bindings/qt_gui/plqt.cpp there is a lot of use of PLD_XXX macros to exclude code if one or more of the qt devices is disabled. Those macros are #defined if the corresponding CMake variable is true, and otherwise not (see include/plDevs.h.in). Therefore, if you specify -DPLD_epsqt=OFF on the cmake command line, then the corresponding C/C++ PLD_epsqt macro will not be #defined, and all the (encapsulated) PostScript code should be excluded so the above problem disappears. For example, if you trace through the code (which I encourage you to do), the specific error above was caused by the code starting at line 1221 of drivers/qt.cpp which is protected by #if defined ( PLD_epsqt ) Therefore, -DPLD_epsqt=OFF should get you by this problem and allow you to move on to the next problem. Furthermore, if that next problem shows that not all all PostScript-related code is excluded by -DPLD_epsqt=OFF, then I would be happy to accept a patch from you to add more uses of the PLD_epsqt macro in the above source code files to fix that issue. Later today I plan to set the CMake PLD_epsqt variable permanently to OFF in the build system for the PLPLOT_USE_QT5=ON case since Qt5 does not support PostScript. But that commit is going to be delayed by another CMake code cleanup issue so you should continue to specify -DPLD_epsqt=OFF for the time being to avoid the above issue. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2014-03-14 04:45:10
|
To Andrew and RM: On 2014-03-13 15:49-0700 Alan W. Irwin wrote: > Later today I plan to set the CMake PLD_epsqt variable permanently to > OFF in the build system for the PLPLOT_USE_QT5=ON case since Qt5 does > not support PostScript. DONE as of revision 13055. I am looking forward to seeing how the combined -DPLPLOT_USE_QT5=ON and (default) -DENABLE_DYNDRIVERS=ON case now works for both you guys on your entirely different platforms. 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 __________________________ |
From: RM <rc...@ve...> - 2014-03-14 18:45:33
|
<div style="FONT-FAMILY: Arial; COLOR: rgb(0, 0, 0); FONT-SIZE: 12px"><div>Hi Alan,</div><div><br /></div><div>I tried with your latest code. Some issues:</div><div><br /></div><div>I'm interpreting your last post as meaning all I need to do is use -DPLPLOT_USE_QT5=ON and the QPrinter problems should go away. Unfortunately this isn't the case yet. In qt.h, the #include <QPrinter> directive (line 62) needs to be protected by the macro, otherwise the compiler attempts to include it and can't find it with Qt5. So, as a quick hack, I moved it down to line 213, inside the #ifdef.</div><div><br /></div><div>This gets slightly further, but doesn't entirely work, perhaps because of the || clause in the #if statement. <br /></div><div><div>#if defined ( PLD_epsqt ) || defined ( PLD_pdfqt )</div></div><div><br /></div><div>I had to turn off both PS and PDF to make it past this issue:</div><div><br /></div><div><div>cmake28 -DPLPLOT_USE_QT5=ON -DCMAKE_PREFIX_PATH=/opt/qt5.2.1_x64/ -DPLD_epsqt=OFF -DPLD_pdfqt=OFF -DCMAKE_INSTALL_PREFIX=/opt/plplot5.10.0 ..</div></div><div><br /></div><div>Then, compile made it all the way down to here:</div><div><br /></div><div> [ 30%] Generating test_dyndrivers_dir/qt.driver_info</div><div>Could not open driver module /home/Downloads/plplot-latest/plplot-code/PLPLOT-BUILD/drivers/qt</div><div>libltdl error: file not found</div><div>make[2]: *** [drivers/test_dyndrivers_dir/qt.driver_info] Error 1</div><div>make[1]: *** [drivers/CMakeFiles/test_qt_dyndriver.dir/all] Error 2</div><div>make: *** [all] Error 2</div><div><br /></div><div>I don't understand this error -- but there's an issue of some sort. In any event, I ran make a second time, and it suddenly ran all the way to the end. make install worked as well.</div><div><br /></div><div>Off-hand, I don't have any code to test the qt library, and this is essentially my first time compiling plplot from scratch, so I'm unfamiliar with the build system. Is there a qt example I can run against it? I couldn't find where the examples built in the build directory.</div><div><br /></div><div>Cheers,</div><div>RM</div><div><br /></div><div style="border-top:1px solid #bcbcbc;margin:5px 0px;"></div><span style="font-size:12;font-family:arial;color:#000000;">On 03/14/14, <span>Alan W. Irwin<ir...@be...></span> wrote:</span><div> </div><div style="font-size:12;font-family:arial;color:#000000;">To Andrew and RM:<br /><br />On 2014-03-13 15:49-0700 Alan W. Irwin wrote:<br /><br />> Later today I plan to set the CMake PLD_epsqt variable permanently to<br />> OFF in the build system for the PLPLOT_USE_QT5=ON case since Qt5 does<br />> not support PostScript.<br /><br />DONE as of revision 13055. I am looking forward to seeing how the<br />combined -DPLPLOT_USE_QT5=ON and (default) -DENABLE_DYNDRIVERS=ON case<br />now works for both you guys on your entirely different platforms.<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> |
From: Alan W. I. <ir...@be...> - 2014-03-14 20:47:00
|
Hi RM: Congratulations on how far you have been able to get with Qt5 so far! I am most impressed. Following up should be straightforward. See comments in context below. On 2014-03-14 13:45-0500 RM wrote: > Hi Alan, > > I tried with your latest code. Some issues: > > I'm interpreting your last post as meaning all I need to do is use -DPLPLOT_USE_QT5=ON and the QPrinter problems should go away. > Unfortunately this isn't the case yet. In qt.h, the #include <QPrinter> directive (line 62) needs to be protected by the macro, > otherwise the compiler attempts to include it and can't find it with Qt5. So, as a quick hack, I moved it down to line 213, inside the > #ifdef. > > This gets slightly further, but doesn't entirely work, perhaps because of the || clause in the #if statement. > #if defined ( PLD_epsqt ) || defined ( PLD_pdfqt ) > > I had to turn off both PS and PDF to make it past this issue: I don't understand the qt.h code that well, but perhaps Andrew or Hazen can figure out the correct use of the PLD_epsqt (and PLD_pdfqt) macros to solve this issue so you don't have to disable the pdfqt device as well. > > cmake28 -DPLPLOT_USE_QT5=ON -DCMAKE_PREFIX_PATH=/opt/qt5.2.1_x64/ -DPLD_epsqt=OFF -DPLD_pdfqt=OFF > -DCMAKE_INSTALL_PREFIX=/opt/plplot5.10.0 .. Good choice to bypass the issue for now with -DPLD_pdfqt=OFF. -DPLD_epsqt=OFF should not be needed any more since that happens by default for -DPLPLOT_USE_QT5=ON. > > Then, compile made it all the way down to here: > > [ 30%] Generating test_dyndrivers_dir/qt.driver_info > Could not open driver module /home/Downloads/plplot-latest/plplot-code/PLPLOT-BUILD/drivers/qt > libltdl error: file not found > make[2]: *** [drivers/test_dyndrivers_dir/qt.driver_info] Error 1 > make[1]: *** [drivers/CMakeFiles/test_qt_dyndriver.dir/all] Error 2 > make: *** [all] Error 2 > > I don't understand this error -- but there's an issue of some sort. In any event, I ran make a second time, and it suddenly ran all the > way to the end. make install worked as well. This is a "head-scratcher" bug that appears on certain Windows platforms that we have never been able to figure out. The simple code that checks dynamic loading of the qt device driver sometimes fails on Windows, but that same dynamic loading succeeds for the equivalent PLplot library code! Go figure.... The workaround is to skip the simple check by adding the cmake option -DTEST_DYNDRIVERS=OFF. > Off-hand, I don't have any code to test the qt library, and this is essentially my first time compiling plplot from scratch, so I'm > unfamiliar with the build system. Is there a qt example I can run against it? I couldn't find where the examples built in the build > directory. Add the cmake option -DBUILD_TEST=ON. Then directly after you run cmake (no need to do "make" or "make all" first since all necessary dependencies are taken care of by the following commands), do this simple test. # Build the first C example: make x01c # Build the qt device driver make qt # ESSENTIAL for Windows: Put the dll subdirectory of the top-level directory of the # build tree (i.e., where all the dll's are located) on # your PATH. For bash.exe I would do that as follows: PATH=$(pwd)/dll:$PATH where $(pwd) contains the absolute PATH of the top-level directory of the build tree. # Run x01c with one of the qt devices. examples/c/x01c You should get a choice of a long list of qt-related devices. Pick one of them. If qtwidget is available use that. Otherwise use a file-related device, e.g., svgqt. For the file-related case you will also be prompted for the output filename. You can do all of this on the command line once you know what qt devices are available on your platform. For example, examples/c/x01c -dev qtwidget examples/c/x01c -dev svgqt -o test.svg For the svg case you will need to use some svg display software to see the test.svg results that are output by the above command. For example, the firefox browser should handle display of an svg file without issues. You will also require display software to check results for the other file-related qt devices. If you have the MSYS bash.exe application on your PATH, you can also do a much more comprehensive check of the qt devices as follows: make test_all_qt >& test_all_qt.out Subsequently, you should look in test_all_qt.out for any error messages from this comprehensive test. I hope the simple test of the qt device driver I demonstrated above as well as the comprehensive test of that device driver (if you have bash.exe from MSYS on your PATH) both give you excellent results with Qt5. 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 __________________________ |
From: RM <rc...@ve...> - 2014-03-17 17:15:27
|
<div style="FONT-FAMILY: Arial; COLOR: rgb(0, 0, 0); FONT-SIZE: 12px"><div>Hi all,</div><div><br /></div><div>I downloaded the latest SVN (r13080) and ran the following cmake command:</div><div><br /></div><div><div>cmake28 -DPLPLOT_USE_QT5=ON -DCMAKE_PREFIX_PATH=/opt/qt5.2.1_x64/ -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX=/opt/plplot5.10.0 ..</div></div><div><br /></div><div>So, I'm no longer specifically disabling PDF or PS support, per your recent commits.</div><div><br /></div><div>The whole thing built successfully, and installed. And, running the example with qtwidget works also! SUCCESS!</div><div> </div><div>BTW, I'm in linux also -- CentOS 6.2. So, it looks like it's working on CentOS 6, with a custom Qt5 install, that's living alongside a system Qt4 install.</div><div><br /></div><div>Thanks for all the support!</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/14/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-15 00:28-0000 Andrew Ross wrote:<br /><br />> OK. So the file not found error is a slight read herring. Following some<br />> googling I tried<br />><br />> LD_DEBUG=all test-drv-info qt<br />><br />> and came up with the following error<br />><br />> 31836: /home/andrew/software/plplot/build_qt5/bindings/qt_gui/libplplotqtd.so.1: error: symbol lookup error: undefined symbol: _ZTV11QtExtWidget (fatal)<br />><br />> so it is actually a problem with linking to libplplotqtd.<br /><br />I had never heard of LD_DEBUG before, but when I googled for it, it<br />does seem to be a powerful way to figure out linking issues on Linux. So thanks<br />for drawing that weapon in the arsenal to my attention.<br /><br />><br />> Looking further this turns out to be because moc is not being run on<br />> include/qt.h. There is a new automoc facility in CMake (which I assume<br />> is what Alan's comment in include/CMakeLists.txt was referring to as the<br />> "different method in Qt5". Our file usage doesn't appear to meet the<br />> conditions for this though, and also we weren't actually setting the<br />> automoc property! Anyway, you can still use the old method, but the cmake<br />> is now qt5_wrap_cpp. I've changed back to using this and all works fine.<br /><br />The impression I got from reading the (somewhat terse) information in<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> is<br />that for 2.8.9 (our minimum CMake version) or later versions of CMake,<br />that the qt5_use_modules macro is all that needs to be called. For<br />example, qt5_wrap_cpp is only mentioned for the case of CMake version<br />2.8.3 (or above). So the impression left is that it will work, as you<br />have found, but it is old-fashioned if you can guarantee your users<br />are using 2.8.9 or above (as in our case). However, the only other<br />mention of automoc in that document is for 2.8.11 (which we cannot<br />guarantee for our users) or above where automoc target properties and<br />the CMAKE_AUTOMOC variable which controls are apparently first<br />available for CMake in a way that supports Qt5. (The corresponding<br />cmake documentation for 2.8.9 does mention CMAKE_AUTOMOC, but goes out<br />of its way to mention only Qt4 for that case.) So I now suspect you<br />have found the only possibility that will work for all our users until<br />we bump our minimum CMake version from 2.8.9 to at least 2.8.11.<br /><br />In sum I suspect your changes were the only way to go for now. I also<br />(revision 13059) made an additional change for didactic reasons, but<br />this additional change should have no practical consequences.<br /><br />> With this final change I can now compile and run plplot and the examples<br />> with qt5.<br /><br />Were all your good test results for Qt-5.2.0? If so, please commit<br />the approprate change to cmake/modules/qt.cmake to lower the current minimum<br />version of Qt5 that we support from 5.2.1 to 5.2.0.<br /><br />> RM, how do you get on with these latest changes?<br /><br />RM, I am interested in your reply to that question as well. :-)<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> |
From: Alan W. I. <ir...@be...> - 2014-03-18 03:00:55
|
On 2014-03-17 12:15-0500 RM wrote: > Hi all, > > I downloaded the latest SVN (r13080) and ran the following cmake command: > > cmake28 -DPLPLOT_USE_QT5=ON -DCMAKE_PREFIX_PATH=/opt/qt5.2.1_x64/ -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX=/opt/plplot5.10.0 .. > > So, I'm no longer specifically disabling PDF or PS support, per your recent commits. > > The whole thing built successfully, and installed. And, running the example with qtwidget works also! SUCCESS! > > BTW, I'm in linux also -- CentOS 6.2. So, it looks like it's working on CentOS 6, with a custom Qt5 install, that's living alongside a > system Qt4 install. Excellent news, indeed. > Thanks for all the support! And thank you for drawing this Qt5 issue to our attention in the first place. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2014-03-11 18:22:16
|
On 2014-03-11 01:56-0500 RM wrote: > Thanks Alan. > > 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 > file, if you have one. > > For my setup, I've compiled Qt5 myself and have placed it in /opt. > > How can I get PLplot to find this custom Qt installation? Is there an environment variable or cmake switch? Good question! That stimulated me to look deeper, and it turns out that to even try Qt5 is a lot more difficult than I thought. The PLplot build system is, of course, CMake-based, and CMake provides an "all in one" find module for Qt4 (which we use). However, there were some fundamental issues with that approach such as Qt4 updates would not be supported by CMake until a new version of CMake was released. Therefore, the CMake and Qt5 developers have jointly decided to use a much different approach with Qt5, where the Qt5 project provides the CMake functions and data required to find components of Qt5. But that approach has required some fundamental infrastructure changes in CMake also. The result of these changes is that finding Qt5 components is a very different proposition than finding Qt4 components. Furthermore, if you look at http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html where the new methods the PLplot build system would have to use to find Qt5 components are documented, those methods appear not to be stabilized even yet. For example, the latest major change in the CMake infrastructure to support this new approach occurred relatively recently (for CMake-2.8.11). Therefore, my conclusion is we should wait for something like another year before we attempt to make PLplot work with Qt5. There are several benefits to such a substantial delay. (1) A delay will allow us to bump our minimum CMake version (currently 2.8.9) to 2.8.11 which is currently required to take advantage of the latest CMake infrastructure support for finding Qt5 components. Typically we wait to bump that minimum version until Debian stable includes that minimum version of CMake as a signal that most modern Linux distributions are likely to carry at least that minimum version of CMake. The release date of the next Debian stable version is still TBA, but it should roughly be a year or so from now if the Debian track record for the length of previous release cycles continues for this Debian release cycle. (2) Assuming CMake-2.8.11 constitutes the last big change in infrastructure support, a delay also allows the Qt5 part of the find methods to completely settle down to take advantage of that new infrastructure. (3) A delay allows the Qt5 software itself to settle down. PLplot triggered a number of bugs that existed for Qt4.x before Qt4.5 was released, and the same type of bug issues are likely to occur for early Qt5.x versions as well. (4) A delay gives me a chance to get access to a well-debugged version of Qt5.x myself. For example, I am likely to move to Debian testing (which allows Qt5 to be installed) within the next year or else that version will be released as the next Debian stable release. Such access will allow me to implement (as de facto chief maintainer for our build system) the build-system changes needed to allow users access to Qt5. RM, I am sure you are disappointed by the substantial delay I think we will need before we can support even finding Qt5 with our build system. But in fact it is still early days for Qt5.x so such delays should be expected. Meanwhile, I highly encourage you to try Qt4 for now. Thanks for your good question above! 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2014-03-12 18:10:18
|
On 2014-03-11 11:22-0700 Alan W. Irwin wrote: > Therefore, my conclusion is we should wait for something like another > year before we attempt to make PLplot work with Qt5. There > are several benefits to such a substantial delay. > > (1) A delay will allow us to bump our minimum CMake version (currently > 2.8.9) to 2.8.11 which is currently required to take advantage of the > latest CMake infrastructure support for finding Qt5 components. > Typically we wait to bump that minimum version until Debian stable > includes that minimum version of CMake as a signal that most modern > Linux distributions are likely to carry at least that minimum version > of CMake. The release date of the next Debian stable version is still > TBA, but it should roughly be a year or so from now if the Debian > track record for the length of previous release cycles continues for > this Debian release cycle. > > (2) Assuming CMake-2.8.11 constitutes the last big change in > infrastructure support, a delay also allows the Qt5 part of the find > methods to completely settle down to take advantage of that new > infrastructure. > > (3) A delay allows the Qt5 software itself to settle down. PLplot > triggered a number of bugs that existed for Qt4.x before Qt4.5 was > released, and the same type of bug issues are likely to occur for > early Qt5.x versions as well. > > (4) A delay gives me a chance to get access to a well-debugged version > of Qt5.x myself. For example, I am likely to move to Debian testing > (which allows Qt5 to be installed) within the next year or else that > version will be released as the next Debian stable release. Such > access will allow me to implement (as de facto chief maintainer for > our build system) the build-system changes needed to allow users > access to Qt5. > RM, despite all those caveats, I have changed my mind about delaying this since I have been recently most encouraged by the helpful comments on the CMake mailing list concerning finding Qt5. So later today I will try to implement an experimental option for the PLplot build system so that it will be able to find Qt5. Of course, it will all be blind development on my part since I don't currently have access to Qt5, but it turns out finding Qt5 is actually pretty simple so there is a reasonable chance this experimental option will work for you immediately or after one iteration when I deal with any build-system issues that you find with Qt5. Once that build-system option works for you, it should allow you to see whether there are any API changes between Qt4 and Qt5 that you have to be concerned with. So stay tuned. 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 __________________________ |
From: Andrew R. <and...@us...> - 2014-03-12 19:48:20
|
On Wed, Mar 12, 2014 at 11:10:07AM -0700, Alan Irwin wrote: > On 2014-03-11 11:22-0700 Alan W. Irwin wrote: > > > Therefore, my conclusion is we should wait for something like another > > year before we attempt to make PLplot work with Qt5. There > > are several benefits to such a substantial delay. > > > > (1) A delay will allow us to bump our minimum CMake version (currently > > 2.8.9) to 2.8.11 which is currently required to take advantage of the > > latest CMake infrastructure support for finding Qt5 components. > > Typically we wait to bump that minimum version until Debian stable > > includes that minimum version of CMake as a signal that most modern > > Linux distributions are likely to carry at least that minimum version > > of CMake. The release date of the next Debian stable version is still > > TBA, but it should roughly be a year or so from now if the Debian > > track record for the length of previous release cycles continues for > > this Debian release cycle. > > > > (2) Assuming CMake-2.8.11 constitutes the last big change in > > infrastructure support, a delay also allows the Qt5 part of the find > > methods to completely settle down to take advantage of that new > > infrastructure. > > > > (3) A delay allows the Qt5 software itself to settle down. PLplot > > triggered a number of bugs that existed for Qt4.x before Qt4.5 was > > released, and the same type of bug issues are likely to occur for > > early Qt5.x versions as well. > > > > (4) A delay gives me a chance to get access to a well-debugged version > > of Qt5.x myself. For example, I am likely to move to Debian testing > > (which allows Qt5 to be installed) within the next year or else that > > version will be released as the next Debian stable release. Such > > access will allow me to implement (as de facto chief maintainer for > > our build system) the build-system changes needed to allow users > > access to Qt5. > > > > RM, despite all those caveats, I have changed my mind about delaying > this since I have been recently most encouraged by the helpful > comments on the CMake mailing list concerning finding Qt5. So later > today I will try to implement an experimental option for the PLplot > build system so that it will be able to find Qt5. Of course, it will > all be blind development on my part since I don't currently have > access to Qt5, but it turns out finding Qt5 is actually pretty simple > so there is a reasonable chance this experimental option will work for you > immediately or after one iteration when I deal with any build-system > issues that you find with Qt5. > > Once that build-system option works for you, it should allow you to > see whether there are any API changes between Qt4 and Qt5 that you > have to be concerned with. Alan, If you are able to implement this I'll try using my Debian unstable pbuilder environment. Should give fairly easy access to Qt5. Andrew |
From: Alan W. I. <ir...@be...> - 2014-03-12 21:28:24
|
On 2014-03-12 19:48-0000 Andrew Ross wrote: > On Wed, Mar 12, 2014 at 11:10:07AM -0700, Alan Irwin wrote: >> On 2014-03-11 11:22-0700 Alan W. Irwin wrote: >> >>> Therefore, my conclusion is we should wait for something like another >>> year before we attempt to make PLplot work with Qt5. There >>> are several benefits to such a substantial delay. >>> >>> (1) A delay will allow us to bump our minimum CMake version (currently >>> 2.8.9) to 2.8.11 which is currently required to take advantage of the >>> latest CMake infrastructure support for finding Qt5 components. >>> Typically we wait to bump that minimum version until Debian stable >>> includes that minimum version of CMake as a signal that most modern >>> Linux distributions are likely to carry at least that minimum version >>> of CMake. The release date of the next Debian stable version is still >>> TBA, but it should roughly be a year or so from now if the Debian >>> track record for the length of previous release cycles continues for >>> this Debian release cycle. >>> >>> (2) Assuming CMake-2.8.11 constitutes the last big change in >>> infrastructure support, a delay also allows the Qt5 part of the find >>> methods to completely settle down to take advantage of that new >>> infrastructure. >>> >>> (3) A delay allows the Qt5 software itself to settle down. PLplot >>> triggered a number of bugs that existed for Qt4.x before Qt4.5 was >>> released, and the same type of bug issues are likely to occur for >>> early Qt5.x versions as well. >>> >>> (4) A delay gives me a chance to get access to a well-debugged version >>> of Qt5.x myself. For example, I am likely to move to Debian testing >>> (which allows Qt5 to be installed) within the next year or else that >>> version will be released as the next Debian stable release. Such >>> access will allow me to implement (as de facto chief maintainer for >>> our build system) the build-system changes needed to allow users >>> access to Qt5. >>> >> >> RM, despite all those caveats, I have changed my mind about delaying >> this since I have been recently most encouraged by the helpful >> comments on the CMake mailing list concerning finding Qt5. So later >> today I will try to implement an experimental option for the PLplot >> build system so that it will be able to find Qt5. Of course, it will >> all be blind development on my part since I don't currently have >> access to Qt5, but it turns out finding Qt5 is actually pretty simple >> so there is a reasonable chance this experimental option will work for you >> immediately or after one iteration when I deal with any build-system >> issues that you find with Qt5. >> >> Once that build-system option works for you, it should allow you to >> see whether there are any API changes between Qt4 and Qt5 that you >> have to be concerned with. > > Alan, > > If you are able to implement this I'll try using my Debian unstable > pbuilder environment. Should give fairly easy access to Qt5. To Andrew and RM: I have implemented an experimental version of Qt5 find support as of revision 13050 in our svn trunk version. This support defaults to OFF so to turn it ON you must specify the cmake command-line option -DPLPLOT_USE_QT5=ON. I have tested the -DPLPLOT_USE_QT5=ON case for my strictly Qt4 platform. As expected it warned me that it could not find Qt5 and then it fell back to looking for Qt4 (just as I designed it). I also tried the test_qt_all target which does what its name implies. All was well there indicating my fairly extensive Qt5-related build system changes hadn't screwed up anything with our current Qt4 support. Anyhow, for those here like you guys with access to Qt5, please give -DPLPLOT_USE_QT5=ON a try. Note this Qt5 support is only bare bones at this stage (certain things like pyqt and pkg-config Qt support are disabled for this case as denoted by a FIXME comment). But we can add all the bells and whistles later once the fundamental question (does the qt device driver build and run properly with Qt5) is answered. Note if your Qt5 installation is in a non-standard location, then http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html recommends specifying the CMAKE_PREFIX_PATH environment variable to help CMake locate Qt5. You will likely also have to use LD_LIBRARY_PATH for this case since RPATH support for a non-standard QT5 installation is not implemented in our build system yet. Also with regard to API changes, one guy on the CMake list gave me the link <https://github.com/Kitware/VTK/commit/384636ec9f4> showing what the VTK project did to adjust from Qt4 only to support for both Qt4 and Qt5. The code changes to adapt to the new Qt5 API do not look that bad. In our case, if something like that has to be done, please use the PLPLOT_USE_QT5 macro that is now #defined in plplot_config.h to distinguish between the Qt4 and Qt5 cases. @Andrew: It is great that you have access to Qt5. Also because of your high degree of expertise concerning our build system, I encourage you to just go ahead and make any further Qt5-related build-system changes that are required yourself rather than waiting for me to pass judgement on what you think is necessary. 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 __________________________ |
From: Andrew R. <and...@us...> - 2014-03-13 22:30:36
|
On Wed, Mar 12, 2014 at 02:28:16PM -0700, Alan Irwin wrote: > On 2014-03-12 19:48-0000 Andrew Ross wrote: > > > On Wed, Mar 12, 2014 at 11:10:07AM -0700, Alan Irwin wrote: > >> On 2014-03-11 11:22-0700 Alan W. Irwin wrote: > >> > >>> Therefore, my conclusion is we should wait for something like another > >>> year before we attempt to make PLplot work with Qt5. There > >>> are several benefits to such a substantial delay. > >>> > >>> (1) A delay will allow us to bump our minimum CMake version (currently > >>> 2.8.9) to 2.8.11 which is currently required to take advantage of the > >>> latest CMake infrastructure support for finding Qt5 components. > >>> Typically we wait to bump that minimum version until Debian stable > >>> includes that minimum version of CMake as a signal that most modern > >>> Linux distributions are likely to carry at least that minimum version > >>> of CMake. The release date of the next Debian stable version is still > >>> TBA, but it should roughly be a year or so from now if the Debian > >>> track record for the length of previous release cycles continues for > >>> this Debian release cycle. > >>> > >>> (2) Assuming CMake-2.8.11 constitutes the last big change in > >>> infrastructure support, a delay also allows the Qt5 part of the find > >>> methods to completely settle down to take advantage of that new > >>> infrastructure. > >>> > >>> (3) A delay allows the Qt5 software itself to settle down. PLplot > >>> triggered a number of bugs that existed for Qt4.x before Qt4.5 was > >>> released, and the same type of bug issues are likely to occur for > >>> early Qt5.x versions as well. > >>> > >>> (4) A delay gives me a chance to get access to a well-debugged version > >>> of Qt5.x myself. For example, I am likely to move to Debian testing > >>> (which allows Qt5 to be installed) within the next year or else that > >>> version will be released as the next Debian stable release. Such > >>> access will allow me to implement (as de facto chief maintainer for > >>> our build system) the build-system changes needed to allow users > >>> access to Qt5. > >>> > >> > >> RM, despite all those caveats, I have changed my mind about delaying > >> this since I have been recently most encouraged by the helpful > >> comments on the CMake mailing list concerning finding Qt5. So later > >> today I will try to implement an experimental option for the PLplot > >> build system so that it will be able to find Qt5. Of course, it will > >> all be blind development on my part since I don't currently have > >> access to Qt5, but it turns out finding Qt5 is actually pretty simple > >> so there is a reasonable chance this experimental option will work for you > >> immediately or after one iteration when I deal with any build-system > >> issues that you find with Qt5. > >> > >> Once that build-system option works for you, it should allow you to > >> see whether there are any API changes between Qt4 and Qt5 that you > >> have to be concerned with. > > > > Alan, > > > > If you are able to implement this I'll try using my Debian unstable > > pbuilder environment. Should give fairly easy access to Qt5. > > To Andrew and RM: > > I have implemented an experimental version of Qt5 find support as of > revision 13050 in our svn trunk version. This support defaults to OFF > so to turn it ON you must specify the cmake command-line option > -DPLPLOT_USE_QT5=ON. > > I have tested the -DPLPLOT_USE_QT5=ON case for my strictly Qt4 > platform. As expected it warned me that it could not find Qt5 and > then it fell back to looking for Qt4 (just as I designed it). I also > tried the test_qt_all target which does what its name implies. All was > well there indicating my fairly extensive Qt5-related build system > changes hadn't screwed up anything with our current Qt4 support. > > Anyhow, for those here like you guys with access to Qt5, please give > -DPLPLOT_USE_QT5=ON a try. Note this Qt5 support is only bare bones > at this stage (certain things like pyqt and pkg-config Qt support are > disabled for this case as denoted by a FIXME comment). But we can add > all the bells and whistles later once the fundamental question (does > the qt device driver build and run properly with Qt5) is answered. > > Note if your Qt5 installation is in a non-standard location, then > http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html > recommends specifying the CMAKE_PREFIX_PATH environment variable to > help CMake locate Qt5. You will likely also have to use > LD_LIBRARY_PATH for this case since RPATH support for a non-standard > QT5 installation is not implemented in our build system yet. > > Also with regard to API changes, one guy on the CMake list gave me > the link <https://github.com/Kitware/VTK/commit/384636ec9f4> showing > what the VTK project did to adjust from Qt4 only to support for > both Qt4 and Qt5. The code changes to adapt to the new Qt5 API do > not look that bad. In our case, if something like that has to > be done, please use the PLPLOT_USE_QT5 macro that is now #defined > in plplot_config.h to distinguish between the Qt4 and Qt5 cases. > > @Andrew: It is great that you have access to Qt5. Also because of > your high degree of expertise concerning our build system, I encourage > you to just go ahead and make any further Qt5-related build-system > changes that are required yourself rather than waiting for me to pass > judgement on what you think is necessary. Alan, I tried this evening. I ran into a couple of problems. Firstly Debian still has Qt 5.2.0. Simple to change the version searched for. This got me a bit further, but cmake then failed with CMake Error at src/CMakeLists.txt:218 (set_qt_target_properties): Unknown CMake command "set_qt_target_properties". Debian also still has cmake 2.8.12.1 if this is relevant. Looks like this function is only defined for Qt4, not Qt5 and there will be some work to do sorting out include directories and libraries. Commenting out the call to this function for QT5 leads to the build failing since it can't find the Qt5 header files. Handling include directories and libraries now appears to be per component in Qt5, rather than the old QT_INCLUDE_DIRECTORIES etc. Andrew |
From: Alan W. I. <ir...@be...> - 2014-03-13 23:24:21
|
On 2014-03-13 22:30-0000 Andrew Ross wrote: > On Wed, Mar 12, 2014 at 02:28:16PM -0700, Alan Irwin wrote: >> @Andrew: It is great that you have access to Qt5. Also because of >> your high degree of expertise concerning our build system, I encourage >> you to just go ahead and make any further Qt5-related build-system >> changes that are required yourself rather than waiting for me to pass >> judgement on what you think is necessary. > > Alan, > > I tried this evening. I ran into a couple of problems. Firstly Debian > still has Qt 5.2.0. Simple to change the version searched for. This got > me a bit further, but cmake then failed with > > CMake Error at src/CMakeLists.txt:218 (set_qt_target_properties): > Unknown CMake command "set_qt_target_properties". > > Debian also still has cmake 2.8.12.1 if this is relevant. > > Looks like this function is only defined for Qt4, not Qt5 [...] True. This Qt4-only function should never be called for the Qt5 case, and I have fixed that issue (good catch by the way) for revision 13053. > and there will > be some work to do sorting out include directories and libraries. That should all be taken care of (according to the Qt5 cmake manual <http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html> with the logic block above that starts if(NOT ENABLE_DYNDRIVERS AND ANY_QT_DEVICE AND PLPLOT_USE_QT5) I am using the CMake-2.8.9 part of that manual which basically says the qt5_use_modules command should take care of all these issues. But I may be misreading/misinterpreting that manual so would you take a look at that manual as well? > Commenting > out the call to this function for QT5 leads to the build failing since it > can't find the Qt5 header files. I don't understand that result (which for the Qt5 case is equivalent to my fix) since RM got a lot further, but he apparently used the default dynamic devices while you have specifically requested static devices for some reason with -DENABLE_DYNDRIVERS=OFF which triggered the bad call to set_qt_target_properties for the Qt5 case which has now been fixed. Since static devices are always a bit tricky, could you use the dynamic devices to start with at least? Of course, you should also follow my suggestion to RM that he set -DPLD_epsqt=OFF to exclude PostScript-relevant code that is not supported by Qt5. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2014-03-14 02:15:15
|
On 2014-03-13 16:24-0700 Alan W. Irwin wrote: > On 2014-03-13 22:30-0000 Andrew Ross wrote: >> [...]Commenting >> out the call to this function for QT5 leads to the build failing since it >> can't find the Qt5 header files. > > I don't understand that result (which for the Qt5 case is equivalent > to my fix) since RM got a lot further, but he apparently used the > default dynamic devices while you have specifically requested static > devices for some reason with -DENABLE_DYNDRIVERS=OFF which triggered > the bad call to set_qt_target_properties for the Qt5 case which has > now been fixed. Since static devices are always a bit tricky, could > you use the dynamic devices to start with at least? Of course, you > should also follow my suggestion to RM that he set -DPLD_epsqt=OFF to > exclude PostScript-relevant code that is not supported by Qt5. P.S. If you still cannot get as far as RM for the dynamic drivers case, then there are two other possibilities to watch out for that are not an issue for RM. (1) On Linux distributions, Qt5 has to find a way to coexist with the Qt4 installation within the same Unix file system hierarchy, and it is pretty clear from my reading that the Qt developers prefer two completely separate install prefixes for Qt4 and Qt5 instead. So you may have to take some extra measures (say by specifying CMAKE_INCLUDE_PATH or by using some of the methods recommended in <http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html> ) to be sure the Qt5 headers are found for whatever location Debian has decided to install those headers. (2) The Debian 5.2.0 version of Qt may have some bugs in the qt5_use_modules CMake function it provides. Since our Qt5 build-system logic relies on completely on that function, using Qt-5.2.1 (the version that was discussed on the CMake list in answer to my Qt5 questions there) might be essential. While waiting for Qt-5.2.1 to propagate to Linux distros, a possible fallback is to build it ourselves using epa_build. Therefore, I might try implementing that epa_build in the next few days to see how far I get. 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 __________________________ |
From: Andrew R. <and...@us...> - 2014-03-14 23:10:26
|
On Thu, Mar 13, 2014 at 07:15:07PM -0700, Alan Irwin wrote: > On 2014-03-13 16:24-0700 Alan W. Irwin wrote: > > > On 2014-03-13 22:30-0000 Andrew Ross wrote: > >> [...]Commenting > >> out the call to this function for QT5 leads to the build failing since it > >> can't find the Qt5 header files. > > > > I don't understand that result (which for the Qt5 case is equivalent > > to my fix) since RM got a lot further, but he apparently used the > > default dynamic devices while you have specifically requested static > > devices for some reason with -DENABLE_DYNDRIVERS=OFF which triggered > > the bad call to set_qt_target_properties for the Qt5 case which has > > now been fixed. Since static devices are always a bit tricky, could > > you use the dynamic devices to start with at least? Of course, you > > should also follow my suggestion to RM that he set -DPLD_epsqt=OFF to > > exclude PostScript-relevant code that is not supported by Qt5. > > P.S. > > If you still cannot get as far as RM for the dynamic drivers case, > then there are two other possibilities to watch out for that are not > an issue for RM. > > (1) On Linux distributions, Qt5 has to find a way to coexist with the > Qt4 installation within the same Unix file system hierarchy, and it is > pretty clear from my reading that the Qt developers prefer two > completely separate install prefixes for Qt4 and Qt5 instead. So you > may have to take some extra measures (say by specifying > CMAKE_INCLUDE_PATH or by using some of the methods recommended in > <http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html> ) to > be sure the Qt5 headers are found for whatever location Debian has > decided to install those headers. > > (2) The Debian 5.2.0 version of Qt may have some bugs in the > qt5_use_modules CMake function it provides. Since our Qt5 > build-system logic relies on completely on that function, using > Qt-5.2.1 (the version that was discussed on the CMake list in answer > to my Qt5 questions there) might be essential. While waiting for > Qt-5.2.1 to propagate to Linux distros, a possible fallback is to > build it ourselves using epa_build. Therefore, I might try > implementing that epa_build in the next few days to see how far I get. Alan, I'd not spotted the static drivers - this was an oversight on my part when installing packages on the pbuilder chroot. Turns out the problem wasn't related to that though. In Qt5 the QPrinter class is in the QtPrintSupport module, which was not being used. Adding this to the list of required modules fixed the include problems. I then encountered the problem with the shared code between eps and pdf drivers that RM encountered. Turns out the only problem is that there is a mention of QPrinter::PostScriptFormat which does not exist any more with Qt5. Wrapping this with #ifndef PLPLOT_USE_QT5 avoids the problem. I'll commit these two fixes. So I can now compile all the qt drivers statically, but test-drv-info fails with a file not found error, even though the qt.so driver is there and looks ok. Clearly there is something odd about this, so I will investigate further. So far this is promising though. Andrew |
From: Alan W. I. <ir...@be...> - 2014-03-15 00:25:16
|
On 2014-03-14 23:10-0000 Andrew Ross wrote: > Turns out the problem wasn't related to that though. In Qt5 the QPrinter > class is in the QtPrintSupport module, which was not being used. Adding > this to the list of required modules fixed the include problems. > > I then encountered the problem with the shared code between eps and pdf > drivers that RM encountered. Turns out the only problem is that there > is a mention of QPrinter::PostScriptFormat which does not exist any more > with Qt5. Wrapping this with #ifndef PLPLOT_USE_QT5 avoids the problem. > > I'll commit these two fixes. > > So I can now compile all the qt drivers statically, but test-drv-info fails > with a file not found error, even though the qt.so driver is there and looks > ok. Clearly there is something odd about this, so I will investigate further. > So far this is promising though. Thanks, Andrew, for that excellent Qt5 news. It appears to me you now get as far as RM (albeit with the better fixes which you are about to commit). Of course, I am concerned with that test-drv-info failure (which he also encountered). For his case, I assumed it was just the standard Windows bug with test-drv-info, but since you are seeing a test-drv-info problem on Linux as well, there might be some linking issue which you will need to diagnose with nm (or "objump --dynamic-syms" if the QT5 libraries have been stripped) and "ldd -r". It's possible, for example, that you need to add more than just the QtPrintSupport module to get the linking right. Of course, if use of -DTEST_DYNDRIVERS=OFF to work around the test-drv-info failure and a subsequent successful run of the test_all_qt target shows that dynamic loading of the qt device is actually working properly, then it is always possible you are the victim of a build-system race issue concerning test-drv-info. Thus, that possibility is worth looking at if the nm, objdump, and ldd results all look good. Anyhow, I am looking forward with great interest to see what you come up with for the solution of the test-drv-info failure that you are seeing, and I am very pleased at how far both you and RM have gotten with Qt5 so far. 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 __________________________ |
From: Andrew R. <and...@us...> - 2014-03-15 00:29:10
|
On Fri, Mar 14, 2014 at 11:10:10PM +0000, Andrew Ross wrote: > On Thu, Mar 13, 2014 at 07:15:07PM -0700, Alan Irwin wrote: > > On 2014-03-13 16:24-0700 Alan W. Irwin wrote: > > > > > On 2014-03-13 22:30-0000 Andrew Ross wrote: > > >> [...]Commenting > > >> out the call to this function for QT5 leads to the build failing since it > > >> can't find the Qt5 header files. > > > > > > I don't understand that result (which for the Qt5 case is equivalent > > > to my fix) since RM got a lot further, but he apparently used the > > > default dynamic devices while you have specifically requested static > > > devices for some reason with -DENABLE_DYNDRIVERS=OFF which triggered > > > the bad call to set_qt_target_properties for the Qt5 case which has > > > now been fixed. Since static devices are always a bit tricky, could > > > you use the dynamic devices to start with at least? Of course, you > > > should also follow my suggestion to RM that he set -DPLD_epsqt=OFF to > > > exclude PostScript-relevant code that is not supported by Qt5. > > > > P.S. > > > > If you still cannot get as far as RM for the dynamic drivers case, > > then there are two other possibilities to watch out for that are not > > an issue for RM. > > > > (1) On Linux distributions, Qt5 has to find a way to coexist with the > > Qt4 installation within the same Unix file system hierarchy, and it is > > pretty clear from my reading that the Qt developers prefer two > > completely separate install prefixes for Qt4 and Qt5 instead. So you > > may have to take some extra measures (say by specifying > > CMAKE_INCLUDE_PATH or by using some of the methods recommended in > > <http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html> ) to > > be sure the Qt5 headers are found for whatever location Debian has > > decided to install those headers. > > > > (2) The Debian 5.2.0 version of Qt may have some bugs in the > > qt5_use_modules CMake function it provides. Since our Qt5 > > build-system logic relies on completely on that function, using > > Qt-5.2.1 (the version that was discussed on the CMake list in answer > > to my Qt5 questions there) might be essential. While waiting for > > Qt-5.2.1 to propagate to Linux distros, a possible fallback is to > > build it ourselves using epa_build. Therefore, I might try > > implementing that epa_build in the next few days to see how far I get. > > Alan, > > I'd not spotted the static drivers - this was an oversight on my part > when installing packages on the pbuilder chroot. > > Turns out the problem wasn't related to that though. In Qt5 the QPrinter > class is in the QtPrintSupport module, which was not being used. Adding > this to the list of required modules fixed the include problems. > > I then encountered the problem with the shared code between eps and pdf > drivers that RM encountered. Turns out the only problem is that there > is a mention of QPrinter::PostScriptFormat which does not exist any more > with Qt5. Wrapping this with #ifndef PLPLOT_USE_QT5 avoids the problem. > > I'll commit these two fixes. > > So I can now compile all the qt drivers statically, but test-drv-info fails > with a file not found error, even though the qt.so driver is there and looks > ok. Clearly there is something odd about this, so I will investigate further. > So far this is promising though. OK. So the file not found error is a slight read herring. Following some googling I tried LD_DEBUG=all test-drv-info qt and came up with the following error 31836: /home/andrew/software/plplot/build_qt5/bindings/qt_gui/libplplotqtd.so.1: error: symbol lookup error: undefined symbol: _ZTV11QtExtWidget (fatal) so it is actually a problem with linking to libplplotqtd. Looking further this turns out to be because moc is not being run on include/qt.h. There is a new automoc facility in CMake (which I assume is what Alan's comment in include/CMakeLists.txt was referring to as the "different method in Qt5". Our file usage doesn't appear to meet the conditions for this though, and also we weren't actually setting the automoc property! Anyway, you can still use the old method, but the cmake is now qt5_wrap_cpp. I've changed back to using this and all works fine. With this final change I can now compile and run plplot and the examples with qt5. RM, how do you get on with these latest changes? Andrew |
From: Alan W. I. <ir...@be...> - 2014-03-15 02:12:38
|
On 2014-03-15 00:28-0000 Andrew Ross wrote: > OK. So the file not found error is a slight read herring. Following some > googling I tried > > LD_DEBUG=all test-drv-info qt > > and came up with the following error > > 31836: /home/andrew/software/plplot/build_qt5/bindings/qt_gui/libplplotqtd.so.1: error: symbol lookup error: undefined symbol: _ZTV11QtExtWidget (fatal) > > so it is actually a problem with linking to libplplotqtd. I had never heard of LD_DEBUG before, but when I googled for it, it does seem to be a powerful way to figure out linking issues on Linux. So thanks for drawing that weapon in the arsenal to my attention. > > Looking further this turns out to be because moc is not being run on > include/qt.h. There is a new automoc facility in CMake (which I assume > is what Alan's comment in include/CMakeLists.txt was referring to as the > "different method in Qt5". Our file usage doesn't appear to meet the > conditions for this though, and also we weren't actually setting the > automoc property! Anyway, you can still use the old method, but the cmake > is now qt5_wrap_cpp. I've changed back to using this and all works fine. The impression I got from reading the (somewhat terse) information in http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html is that for 2.8.9 (our minimum CMake version) or later versions of CMake, that the qt5_use_modules macro is all that needs to be called. For example, qt5_wrap_cpp is only mentioned for the case of CMake version 2.8.3 (or above). So the impression left is that it will work, as you have found, but it is old-fashioned if you can guarantee your users are using 2.8.9 or above (as in our case). However, the only other mention of automoc in that document is for 2.8.11 (which we cannot guarantee for our users) or above where automoc target properties and the CMAKE_AUTOMOC variable which controls are apparently first available for CMake in a way that supports Qt5. (The corresponding cmake documentation for 2.8.9 does mention CMAKE_AUTOMOC, but goes out of its way to mention only Qt4 for that case.) So I now suspect you have found the only possibility that will work for all our users until we bump our minimum CMake version from 2.8.9 to at least 2.8.11. In sum I suspect your changes were the only way to go for now. I also (revision 13059) made an additional change for didactic reasons, but this additional change should have no practical consequences. > With this final change I can now compile and run plplot and the examples > with qt5. Were all your good test results for Qt-5.2.0? If so, please commit the approprate change to cmake/modules/qt.cmake to lower the current minimum version of Qt5 that we support from 5.2.1 to 5.2.0. > RM, how do you get on with these latest changes? RM, I am interested in your reply to that question as well. :-) 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 __________________________ |
From: Andrew R. <and...@us...> - 2014-03-15 20:22:03
|
On Fri, Mar 14, 2014 at 07:12:30PM -0700, Alan Irwin wrote: > On 2014-03-15 00:28-0000 Andrew Ross wrote: > > > OK. So the file not found error is a slight read herring. Following some > > googling I tried > > > > LD_DEBUG=all test-drv-info qt > > > > and came up with the following error > > > > 31836: /home/andrew/software/plplot/build_qt5/bindings/qt_gui/libplplotqtd.so.1: error: symbol lookup error: undefined symbol: _ZTV11QtExtWidget (fatal) > > > > so it is actually a problem with linking to libplplotqtd. > > I had never heard of LD_DEBUG before, but when I googled for it, it > does seem to be a powerful way to figure out linking issues on Linux. So thanks > for drawing that weapon in the arsenal to my attention. Neither had I until I stumbled across it in another post about debugging issues with dynamic loading of libraries. Definitely a useful thing to remember. > > > > Looking further this turns out to be because moc is not being run on > > include/qt.h. There is a new automoc facility in CMake (which I assume > > is what Alan's comment in include/CMakeLists.txt was referring to as the > > "different method in Qt5". Our file usage doesn't appear to meet the > > conditions for this though, and also we weren't actually setting the > > automoc property! Anyway, you can still use the old method, but the cmake > > is now qt5_wrap_cpp. I've changed back to using this and all works fine. > > The impression I got from reading the (somewhat terse) information in > http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html is > that for 2.8.9 (our minimum CMake version) or later versions of CMake, > that the qt5_use_modules macro is all that needs to be called. For > example, qt5_wrap_cpp is only mentioned for the case of CMake version > 2.8.3 (or above). So the impression left is that it will work, as you > have found, but it is old-fashioned if you can guarantee your users > are using 2.8.9 or above (as in our case). However, the only other > mention of automoc in that document is for 2.8.11 (which we cannot > guarantee for our users) or above where automoc target properties and > the CMAKE_AUTOMOC variable which controls are apparently first > available for CMake in a way that supports Qt5. (The corresponding > cmake documentation for 2.8.9 does mention CMAKE_AUTOMOC, but goes out > of its way to mention only Qt4 for that case.) So I now suspect you > have found the only possibility that will work for all our users until > we bump our minimum CMake version from 2.8.9 to at least 2.8.11. > > In sum I suspect your changes were the only way to go for now. I also > (revision 13059) made an additional change for didactic reasons, but > this additional change should have no practical consequences. Sounds a good idea. It might be worth experimenting with the new support, but for now the approach works on both Qt4 and Qt5. > > With this final change I can now compile and run plplot and the examples > > with qt5. > > Were all your good test results for Qt-5.2.0? If so, please commit > the approprate change to cmake/modules/qt.cmake to lower the current minimum > version of Qt5 that we support from 5.2.1 to 5.2.0. Yes, that is all with 5.2.0. I've run make test_all_qt and all the targets work except test_qt_example. Note you need the QtImageFormats module for the tiff format. The other bitmap formats are available by default. If you don't install the module then plplot just generates empty files with no warning, as I discovered the hard way. I've lowered the minimum requirements to 5.2.0. Andrew |