On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
I [...] spotted this bug report https://cmake.org/Bug/view.php?id=15831. I think the gist of it is that find_library will only search in Windows SDKs that are at least as old as the one used to build that version of Cmake. This seems a bit daft to me as it forces upgrade whenever a new SDK is released
Brad King refers in that discussion to the target version, but I am not sure exactly what he means by that. But what is clear from that discussion is Brad felt the early SDK policy for Windows 10 was wrong, and they instead adopted the same policy as is used for Mac OS X and their SDK's which I assume is a rational one without the need for forced CMake (or SDK) upgrades. The implementation of that fundamental change in policy was done by commit <https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a57caf7e> where the new policy is summarized as Select "a Windows 10 SDK if one exists. Use the SDK for the exact version if is available. Otherwise use the latest version of the SDK available because that will have at least the APIs expected for the target version." Does that policy (implemented in the run-up to CMake 3.4.0) appear like a rational one to you?
I know in the past Alan has mentioned the need to not upgrade due to a bug in a release.
I have said a lot of things in the past concerning CMake versions because early versions of CMake-3.x.y truly sucked. But my experience with CMake versions between 3.6.2 and 3.9.x is much better. My attitude now concerning CMake versions is summarized in "1.1 CMake version compatibility" which you can find for the recent 5.13.0 release in README.cumulated_release. In sum, due to our extensive comprehensive testing of various CMake versions, I feel most/all versions of CMake between 3.6.2 (our minimum allowed version) and CMake 3.9.x should be fine. Of course, the caveat to that summary is we have not comprehensively tested PLplot for Windows SDK's, and there is still a lot of on-going bug fixing for the various Windows SDK's by the CMake developers so I think, in general, you would be better off using 3.9.4 than your current 3.7.1. Anyhow, why not try 3.9.4 and see? If it does not satisfy your personal needs, then you can always move back to 3.7.1. But the bigger issue as PLplot developers is we need to know about any problems you might have with 3.9.4 and your particular Windows SDK so we can make the appropriate bug reports to CMake to get the issue fixed to protect _all_ our users in your situation. 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
