On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung <gvj...@gmail.com> wrote: > Hi there, > A patch for review: > > I have two changes in FindPythonLibs that should make for less failure in > the MINGW/MSYS camp.
I think you explicitly mean the MSYS2 camp here. We have our own Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a Linux-y layout. While I support this stuff, I think for it to not break other people (who use either mingw.org/MinGW-w64 compilers or the old MSYS with 'normal' Windows CPython), CMake needs to be able to identify MSYS2 distinctly from both MINGW and MSYS first. Would a patch making that distinction be acceptable to CMake? > 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 > > -- > > 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 -- 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