Re: [Plplot-devel] Is Qt5 supported?

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

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