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)).
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 <gvj...@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.andr...@gmail.com>
> wrote:
>
>> 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
