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

[Ray Donnelly]

On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung <gvjung at 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