Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung 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
> /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
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
>
> > 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 ": MSYS dll found on
${MSYS_USR_PATH}")
endif()
unset(_BIN)
On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly
wrote:
> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung 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
> > /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/o
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
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 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 ": MSYS dll found on
> ${MSYS_USR_PATH}")
> endif()
> unset(_BIN)
>
>
>
>
> On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly
> wrote:
>
>> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung 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
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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 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 ": MSYS dll found on
>> ${MSYS_USR_PATH}")
>> endif()
>> unset(_BIN)
>>
>>
>>
>>
>> On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly
>> wrote:
>>>
>>> On Fri, Aug
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On 09/02/2015 07:13 AM, Ray Donnelly wrote: > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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. As a reminder, another branch of this discussion is pending over here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 -Brad -- 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
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung 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 > wrote: >> >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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 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. >> >> >>
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
> > 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. On Wed, Sep 2, 2015 at 4:13 AM, Ray Donnelly wrote: > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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 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 CMakeFindMSYS
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
> > As a reminder, another branch of this discussion is pending over here: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 That devolved into another issue. This also applies to msys-1 with a targetted python installation. I don't think there are any "structural" issues in running the mingw-w64/msys2 system using "MSYS Makefiles". The cmake adapted to running posix-mode msys2 is another matter. On Wed, Sep 2, 2015 at 6:02 AM, Brad King wrote: > On 09/02/2015 07:13 AM, Ray Donnelly wrote: > > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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. > > As a reminder, another branch of this discussion is pending over here: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 > > -Brad > > -- 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
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
> > On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung 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 wrote: > On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung 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 > > wrote: > >> > >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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) > >> .
