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.
Cheers,
RM
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
__________________________
> 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
__________________________
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
