On 2017-04-22 21:46-0700 Alan W. Irwin wrote:
So my next steps are gross simplification (to prove this
cross-contamination of build rules for UseSWIG-generated modules in
the same CMakeLists.txt file really is due to a regression in CMake
somewhere between CMake-3.0.2 and 3.7.2. Note that both CMake-3.7.2
and CMake-3.8.0-rc4 show the warning problem.)
Well, the short story is there was no such regression. Note the
"--SOLVED" in the revised subject line. Also, sorry for the noise!
The somewhat longer story is just at the start (fortunately for me) of
that simplification process, I double checked the source of both
FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned
out to be special cutting-edge versions recommended by one user of the
cmake bug tracking system from a decade (!) ago. Oops! Those
versions did continue to work for a very long time for our simple swig
needs, but those are obviously well past their "best buy" date, and
complete removal of those "special" versions from PLplot (so PLplot is
now using the official version of those modules that is distributed by
whatever CMake version a user chooses) works without the warning
messages for both CMake-3.0.2 AND CMake-3.8.0-rc4. In fact (as I
expected since I am an optimist) but unlike the extremely peculiar
result I had before, inspection of
bindings/python/CMakeFiles/_Pltk_init.dir/build.make showed no
contamination from plplotc rules at all.
So problem solved completely! Thus, thanks to swig, and official
versions of FindSWIG.cmake and UseSWIG.cmake that vary with CMake
version but which are good enough for our needs despite that
variation, I now have my test of our Tcl/Tk "plframe" plotting GUI
working well for both Python 2 and Python 3 for a very large range of
CMake versions.
I hasten to add we will not support that large a range of CMake
versions too much longer although that supported range actually helped
to figure out the current problem. Indeed, I soon plan to bump our
minimum CMake version from 3.0.2 to 3.6.2 which will allow me to
greatly simplify our build system by stripping out a whole lot of
cruft that was necessary to work around issues that existed for quite
a few versions after CMake-3.0.2 was released.
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
__
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
