Hi Alan,
I understand! Thank you for the detailed response.
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.
Ok, thanks again.
Cheers,
RM
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
__________________________
> 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
__________________________
------------------------------------------------------------------------------ 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
