Re: [Plplot-devel] Is Qt5 supported?

[Andrew R. <and...@us...>]

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