[cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion

Greg Jung gvjung at gmail.com
Fri Aug 7 02:58:33 EDT 2015


Hi there,
  A patch for review:

  I have two changes in FindPythonLibs that should make for less failure in
the MINGW/MSYS camp.
1. Distinguish mingw and win32.  Avoid the registry lookup.
if(WIN32) => if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library search,
a full unix-style find_library call without reference to possible registry
entries.

+    NAMES
+    python${_CURRENT_VERSION_NO_DOTS}
+    python${_CURRENT_VERSION}mu
+    python${_CURRENT_VERSION}m
+    python${_CURRENT_VERSION}u
+    python${_CURRENT_VERSION}
+#
+    NAMES_PER_DIR
+    # Avoid finding the .dll in the PATH.  We want the .lib.
+# The NAMES_PER_DIR above should allow the library to be found where it
was desired
+# in the prioritized location of PATH - cmake V3.3 behavior;
+#    NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 improvement
where CMake will look into path.
+#
+  )
+endif()

2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the search
such that windows/system32/python27.dll
(for instance) is not picked up before finding the proper library under
<path component>/lib


  Instead of throwing all of the possible locations into a single
find_library(), for WIN32+MINGW builds this may latch into a windows'
python.
This is not an issue when CMake is run from /MINGW.
CMake-3.3.0 (and above) can use PATH to discover targets of find_library,
allowing
a user with several MINGW installations to use a single cmake (and
cmake-gui) instead of
installing several copies for each mingw to be built with.  Unless the
find_path or
find_library uses "NO_SYSTEM_ENVIRONMENT_PATH" which kills the new feature.
  Even though /mingw32/bin is frontmost in the path,
windows/system32/python27.dll
was latched onto because the name matches earlier in the NAMES list than
python2.7.
to avoid this all of the names are tested as the direcftories are
presented, this via the
NAMES_PER_DIR qualifier.

   This makes is possible for me to run builds using Cmake-gui without
installing cmake-gui
in /mingw32/bin (and qt5 along with it!).

Regards,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150806/03271fe6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FindPythonLibs-avoids-registry-if-MINGWE-or-MSYS.patch
Type: application/octet-stream
Size: 4474 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150806/03271fe6/attachment.obj>


More information about the cmake-developers mailing list