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

2015-09-02 Thread Ray Donnelly 
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

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

2015-09-02 Thread Greg Jung 
>
> 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

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

2015-09-02 Thread Greg Jung 
>
> 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

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

2015-09-02 Thread Greg Jung 
>
> 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

2015-09-02 Thread Ray Donnelly 
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

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

2015-09-02 Thread Greg Jung 
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

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

2015-09-02 Thread Brad King 
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

2015-08-07 Thread 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.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:

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

2015-08-07 Thread Ray Donnelly 
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

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

2015-08-07 Thread Greg Jung 
Hi there,
  A patch for review:

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


0001-FindPythonLibs-avoids-registry-if-MINGWE-or-MSYS.patch
Description: Binary data
-- 

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