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

[Greg Jung]

>
> >   I have two changes in FindPythonLibs that should make for less failure
> in
> > the MINGW/MSYS camp.
>
> 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),


If there is not a python installation to be found in the mingw path, the
patched routine will drop into the registry search. which will look exactly
like previous.

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.


  I've been running with msys2, and lately I've done a lot of test-running
of plplot using plain vanilla
CMake without the patches I used to think were needed.   I found that from
the CMake point of view,
msys1 or msys2 is a distinction without a difference.


> 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?

I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable
designating
what /usr translates to:
#
# the variable MSYS_USR_PATH is here  created for use
# where the /usr provided by an MSYS app needs to be translated for Windows.
#
unset(_BIN)
find_path( _BIN   msys-1.0.dll   NAMES msys-2.0.dll         HINTS ENV PATH
   NO_DEFAULT_PATH)
if(_BIN)
  set(MSYS 1)
find_path( MSYS_USR_PATH bin   PATHS ${_BIN}/../    NO_DEFAULT_PATH)

   mark_as_advanced(MSYS_USR_PATH)
   message(STATUS "<CMakeUnixFindMake>: MSYS dll found on
${MSYS_USR_PATH}")
endif()
unset(_BIN)




On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly <mingw.android at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150807/b7b09de8/attachment.html>