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 interested. 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 __________________________ 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
