On 2016-10-12 09:03-0400 Pedro Vicente wrote:

> Hi Alan
> yes, that was what I did,  a clone of the git master from
> https://sourceforge.net/p/plplot/plplot/ci/master/tree/
> I'll try again later today

Hi Pedro:

I have put this discussion back on the plplot-devel list since I
assume the Qt5 users like Hazen that are lurking there will be

I now realize that a similar issue has come up before (look for the
subject line of "Qt5 / cmake error" in January this year in the
plplot-devel archive).  Hazen's workaround was to drop the offending
PRIVATE keyword from the target_link_libraries command in his commit
5d27ac4. What is new in your case is you are using static libraries so
it is a different target_link_libraries command where the issue
occurs.  So I suggest you try a similar workaround (remove either the
PRIVATE or PUBLIC keyword from the command) for the offending PLplot
target_link_libraries command reported in your error message.

Note a more fundamental fix for this issue of mixing of plain and
keyword signatures for the target_link_libraries commands is to
complete reimplement how we support Qt5 in our build system.  The
issue is Qt5 supports ~5 different ways of building Qt5-using
libraries, and we currently use one of the oldest of those methods
(suitable for CMake-2) which uses the plain target_link_libraries
signature and which therefore does not work with our keyworded version
of the same command. But our minimum CMake version is now in the
CMake-3 range which allows us to move to the most modern method
supported by Qt5.  So once I do that, I think this mixed plain and
keyword issue will simply disappear, and I will be able to reverse
Hazen's workaround.  But I am not sure I can deal
with this before the release of PLplot-5.12.0 so for now you have to
use workarounds for Qt5 (which is still only experimentally supported
by PLplot, after all, with Qt4 being the tried and true library that
we still recommend to our users).

@Hazen and other Qt5 users here.  Once I move to the latest Qt5 cmake
support methods, we will be on much less shaky ground with Qt5, but I
will still consider our Qt5 support to be experimental because there
are still text alignment issues which I have worked around with a
semiempirical displacement of text compared to the Qt4 case.  See
discussion in commentary of bindings/qt_gui/plqt.cpp concerning
"Empirical Y offset".

It's possible the issue is the default text alignment we are using for
Qt5 is not correct, and we have to do some specific library startup
for the Qt5 case to make its text alignment consistent with the Qt4
text alignment.

@Hazen: Would you be willing to look at this possibility?

Of course, we could also just be up against a Qt5 text alignment bug
which means if/when Qt5 fixed that hypothesized bug, our semiempirical
text displacement would have to be adjusted to zero to compensate. So
this is a strong possibility to look at if Qt5 users find that text
alignment is suddenly poor when they upgrade their Qt5 version.

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

Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Plplot-devel mailing list

Reply via email to