On 2016-10-15 21:07-0400 Pedro Vicente wrote:
> Hi Alan
> Thank you for your effort in debuging this.
> I send some results here attached , and I'll keep trying other options later.
> by the way, wxWidgets is also not detected.
> I wonder, could this be a Windows only issue? Because you are trying on
> Linux, correct?
Yes, all my tests are on Linux. Our goal is to tune our CMake-based
build system so the Windows PLplot experience as just as smooth as on
Linux, but we are not there yet, and your help in reporting any issues
you find is important for helping us to reach that goal. It turns out
in this case, that the find Qt5 part of the issue is working smoothly
on Windows. That is, both your QTDIR and alternative
CMAKE_PREFIX_PATH ways of setting up cmake appear to be giving you
good Qt5_library_fullpath_list, etc., results.
> also here
> they specificaly say to *not* use the form
> but that is a resource from 2012, not sure if that is valid
That resource is no longer valid. Methods of finding Qt5 have been in a big
state of flux
since those dark ages.
> first, the Qt location is detected
> -- Qt5_library_fullpath_list =
> -- Qt5_library_LINK_FLAGS = I:/qt-win32-msvc2015/lib/Qt5Cored.lib
> I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
Those good results imply you are finding Qt5 successfully on your
system (and see my comments above about that). The remaining issues
you have discovered are general Qt5 issues rather than Windows only.
> but then the errors are
> CMake Error at src/CMakeLists.txt:322 (target_link_libraries):
> The plain signature for target_link_libraries has already been used with
> the target "plplot". All uses of target_link_libraries with a target must
> be either all-keyword or all-plain.
So after that Qt5 find succeeded, you ran into the same mixed
plain/keyword target_link_libraries message you got before, and you
have to locally fix that issue just like you did before by dropping
the PUBLIC keyword from the target_link_libraries command indicated
above. The reason you are running into this is you are choosing to
use static libraries, and if I did the same thing on Linux, I would
also have to use that local workaround. Once I get our build system
changed so that it uses the modern Qt5 setup method, then I plan to
comprehensively test both the shared (with and without dynamic
devices) and static cases to confirm plain/keyword local workarounds
are no longer necessary for any of the principal PLplot build
Once you try the above local workaround, the important question is
whether you still have the version inconsistency trouble that occurred
for you before or whether the minimum version bump in the commit I did
yesterday fixes that issue. (And if it doesn't fix it, please bump
the minimum version "5.3.1" that appears on line 80 of
cmake/modules/qt.cmake to a minimum version that is consistent with
your Qt5 version to see if that locally fixes the issue.)
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).
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