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

Greg Jung gvjung at gmail.com
Wed Sep 2 15:27:17 EDT 2015 

>
> On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung <gvjung at gmail.com> wrote:
> >> Would:
> >> if (MSVC)
> >> .. not be a better discriminator here? There's probably some people
> >> who use MSYS2 in conjunction with MSVC compilers.
> >>
> > If they are doing that, won't they want the MSYS-installed version? If
> it's
> > not found then the library
> > reverts to the windows-registered version. It just gives the possible
> python
> > living under the designated path the first crack.
> >
>
> Not necessarily; I mean, if MSVC is set, then CMake is going to use
> MSVC and if it then finds our Python and links to it then you'll have
> two c-runtimes in play .. not good .. so my vote is for "if MSVC" or
> "if MINGW" with no reference to "MSYS" as that's just a general
> purpose build environment.


If MSVC is the only compiler that is capable of using the registered
python,
then  replacing if(WIN32 AND NOT (MINGW OR MSYS)) with if(MSVC)
and
if((NOT WIN32) OR (MINGW OR MSYS)) replaced by if(NOT MSVC)
would definitely be a better read.

On Wed, Sep 2, 2015 at 12:04 PM, Ray Donnelly <mingw.android at gmail.com>
wrote:

> On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung <gvjung at gmail.com> wrote:
> >> Would:
> >> if (MSVC)
> >> .. not be a better discriminator here? There's probably some people
> >> who use MSYS2 in conjunction with MSVC compilers.
> >>
> > If they are doing that, won't they want the MSYS-installed version? If
> it's
> > not found then the library
> > reverts to the windows-registered version. It just gives the possible
> python
> > living under the designated path the first crack.
> >
>
> Not necessarily; I mean, if MSVC is set, then CMake is going to use
> MSVC and if it then finds our Python and links to it then you'll have
> two c-runtimes in play .. not good .. so my vote is for "if MSVC" or
> "if MINGW" with no reference to "MSYS" as that's just a general
> purpose build environment.
>
> > On Wed, Sep 2, 2015 at 4:13 AM, Ray Donnelly <mingw.android at gmail.com>
> > wrote:
> >>
> >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung <gvjung at gmail.com> wrote:
> >> > To revive this issue, I show a comparison of the CMakeCache entries
> for
> >> > cmake run from the same configuration, 1) cmake 3.2.3 with "old"
> >> > PythonLibs
> >> > .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake.
> >> >
> >> > Cmake 1):
> >> >
> >> > # This is the CMakeCache file.
> >> > # For build in directory: d:/mingw/msys32/tmp/bld-32
> >> > # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe
> >> >  [...]
> >> > //Path to a program.
> >> > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe
> >> >
> >> > //Path to a file.
> >> > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7
> >> >
> >> > //Path to a library.
> >> > PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a
> >> >
> >> > //Dependencies for the target
> >> >
> >> >
> _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a;
> >> >
> >> > //Dependencies for the target
> >> >
> >> >
> plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a;
> >> > //Path to CMake executable.
> >> > CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe
> >> > //Details about finding PythonLibs
> >> >
> >> >
> FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()]
> >> >
> >> >
> >> > Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched
> >> > FindPythonLibs.cmake
> >> >
> >> > # This is the CMakeCache file.
> >> > # For build in directory: d:/mingw/msys32/tmp/bld-32
> >> > # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe
> >> > [...]
> >> > //Path to a program.
> >> > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe
> >> >
> >> > //Path to a file.
> >> > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7
> >> >
> >> > //Path to a library.
> >> > PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a
> >> >
> >> > //Dependencies for the target
> >> >
> >> >
> _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a;
> >> >
> >> > //Dependencies for the target
> >> >
> >> >
> plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a;
> >> > //Path to CMake executable.
> >> > CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe
> >> > //Details about finding PythonLibs
> >> >
> >> >
> FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()]
> >> >
> >> >
> >> > So, my windows-y python installation which is registered in the
> windows
> >> > registry, interferes with my use of
> >> > python until I replace the FindPythonLibs.cmake with the modified
> >> > version.
> >> > The new routine will find the registry  version in the same manner  if
> >> > (WIN32 AND NOT (MINGW OR MSYS)).
> >> >
> >>
> >>
> >> Would:
> >> if (MSVC)
> >> .. not be a better discriminator here? There's probably some people
> >> who use MSYS2 in conjunction with MSVC compilers.
> >>
> >> >   Someone using this routine from windows (MSVC) or from a non-win32
> >> > environment should have the same results as before.  If the MSYS user
> >> > only
> >> > has a separate windows-based registry-registered python
> >> > and there is nothing found in the unix-style searches, the previous
> >> > behavior
> >> > of providing answers from the registry-based installation kicks in.
> >> >
> >> > Regards, Greg
> >> >
> >> > On Fri, Aug 7, 2015 at 4:05 PM, Greg Jung <gvjung at gmail.com> wrote:
> >> >>>
> >> >>> >   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/20150902/d23c85e4/attachment-0001.html>

More information about the cmake-developers mailing list