On 2019-01-31 17:37-0000 Phil Rosenberg wrote:

Hi Alan
I half thought that we had scrapped our findwxWidgets.cmake module,
but I just found that this isn't actually the case.

I've just disabled our version by renaming it, and I've found that the
CMake version does appear to work on Windows. This is using cmake
3.13.3 (the latest release as of writing this email).

I seem to remember that it was for windows builds that we were
maintaining our own version. Perhaps this can now be removed?

Hi Phil:

I am moving this development discussion to the plplot-devel list since that is 
what
that list is for, and plplot-general is normally just used for user support.

I followed up on your question by using

git log cmake/modules/FindwxWidgets.cmake

to check the history of this file.  As of commit 59344dc51a25
it was updated to the official upstream version for
CMake-3.9.0-rc3, and since there has been 3 commits, but
one of them cancelled another one so the net effect of our changes
since commit 59344dc51a25 is as
follows:

software@merlin> git diff 59344dc51a25 HEAD cmake/modules/FindwxWidgets.cmake diff --git a/cmake/modules/FindwxWidgets.cmake b/cmake/modules/FindwxWidgets.cmake
index 82f34ec32..4d3a2d115 100644
--- a/cmake/modules/FindwxWidgets.cmake
+++ b/cmake/modules/FindwxWidgets.cmake
@@ -915,8 +915,17 @@ if (_wx_lib_missing)
 endif()
 unset(_wx_lib_missing)

-# Check if a specfic version was requested by find_package().
+# Check if a specific version was requested by find_package().
 if(wxWidgets_FOUND)
+  # On at least one Windows platform (MinGW/MSYS) find_file fails
+  # unless convert from /<drive_letter>/ form to <drive_letter>:/
+  # form.  So use both forms to be sure on that platform without
+  # disrupting other platforms.
+  string(REGEX REPLACE ";/([a-zA-z])/" ";\\1:/" wxWidgets_search_path 
";${wxWidgets_INCLUDE_DIRS}")
+  list(REMOVE_AT wxWidgets_search_path 0)
+  if(NOT "${wxWidgets_search_path}" STREQUAL "${wxWidgets_INCLUDE_DIRS}")
+    list(APPEND wxWidgets_INCLUDE_DIRS ${wxWidgets_search_path})
+  endif(NOT "${wxWidgets_search_path}" STREQUAL "${wxWidgets_INCLUDE_DIRS}")
   find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} 
NO_DEFAULT_PATH)
   dbg_msg("_filename:  ${_filename}")

That change was to help support the legacy MinGW/MSYS system which is now likely
of zero interest to us (since its successor MinGW-w64/MSYS2 is so much better).
And this change may not be necessary on any other platform.

Meanwhile, since CMake-3.9.0-rc3 the CMake developers have been
actively maintaining the upstream version of FindwxWidgets.cmake to
the point that from your experience it is a big improvement on our
version.

So yes, I agree that it is time for us to drop our own version, and if
we find the above patch is necessary on any Windows platform of
interest to us we can always submit that change for inclusion into the
upstream version.

Meanwhile, the upstream version of this find module would likely fail
for our users that are using cmake versions less than 3.9.0.  But that
is not going to be an issue since I plan in any case today to bump the
minimum version of cmake that PLplot accepts to a version of CMake
that all modern Linux, Mac, and Windows free software distributions
support.  That new minimum version will be 3.13.2 for Linux, but I
still have to look at the Mac OS X distributions Fink, MacPorts, and
HomeBrew, and the Windows distributions Cygwin, and MinGW-w64/MSYS2 to
see if that or a higher version of CMake is available for all of
those.

Just to remind developers here that are not aware of this, the
motivation for such bumps in the minimum version of CMake we accept
for PLplot configuration is all the bug fixing and improved find
capability (e.g., for the wxwidgets find module) that has gone on, and
the improved CMake policy that has been established for modern CMake
versions.  So in general every such bump makes our build system more
robust and easier to maintain (e.g., it allows us to drop our own
version of the wxwidgets find module).

Alan
__________________________
Alan W. Irwin

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
__________________________


_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to