MSYS2 broken CMAKE_PREFIX_PATH

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

MSYS2 broken CMAKE_PREFIX_PATH

Mario Emmenlauer

I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
but just recently I started to have problems with CMAKE_PREFIX_PATH.
Its possible that the problems have been there forever, but I now just
found them due to a better use of CI systems.

The problem is that cmake is not finding package configuration files
correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
and XXXTargets.cmake (i.e. for Qt, VTK and others).

But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
in Unix path style. It does work when I specify the package configuration
directory in Windows style! This makes things quite confusing, because many
find_xxx() commands for headers and libraries work with Unix paths. So now
I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
add WINDESTDIR\lib\cmake for the package configuration files (*).

Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
can comment?

All the best,

    Mario Emmenlauer


(*) UNIXDESTDIR is a shorthand of a path in Unix style, like /d/soft/
    WINDESTDIR is a shorthand of a path in Windows style, like D:\soft\


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Alan W. Irwin
On 2018-02-11 15:13+0100 Mario Emmenlauer wrote:

>
> I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
> but just recently I started to have problems with CMAKE_PREFIX_PATH.
> Its possible that the problems have been there forever, but I now just
> found them due to a better use of CI systems.
>
> The problem is that cmake is not finding package configuration files
> correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
> XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
> and XXXTargets.cmake (i.e. for Qt, VTK and others).
>
> But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
> in Unix path style. It does work when I specify the package configuration
> directory in Windows style! This makes things quite confusing, because many
> find_xxx() commands for headers and libraries work with Unix paths. So now
> I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
> add WINDESTDIR\lib\cmake for the package configuration files (*).
>
> Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
> here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
> can comment?

Hi Mario:

From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
what you said above it appears you are using the "native Windows"
cmake version from the mingw64 repository rather than the POSIX-style
cmake package you can install from the msys2 repository.  I am pretty
sure the native version would not do well with non-native POSIX-style
paths so I am not surprised by your results.  Anyhow, I suggest you
experiment with native versus POSIX cmake packages in both CMD and
bash (from msys2) environments to establish what the different results
are in those four cases for native Windows and POSIX paths.

Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close
attention to this platform because it is the best Windows platform for
PLplot according to a fellow PLplot developer who does have a lot of
practical experience with this platform.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Mario Emmenlauer

Dear Alan,

thanks for your reply! Below more:

On 11.02.2018 23:11, Alan W. Irwin wrote:

> On 2018-02-11 15:13+0100 Mario Emmenlauer wrote:
>
>>
>> I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
>> but just recently I started to have problems with CMAKE_PREFIX_PATH.
>> Its possible that the problems have been there forever, but I now just
>> found them due to a better use of CI systems.
>>
>> The problem is that cmake is not finding package configuration files
>> correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
>> XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
>> and XXXTargets.cmake (i.e. for Qt, VTK and others).
>>
>> But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
>> in Unix path style. It does work when I specify the package configuration
>> directory in Windows style! This makes things quite confusing, because many
>> find_xxx() commands for headers and libraries work with Unix paths. So now
>> I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
>> add WINDESTDIR\lib\cmake for the package configuration files (*).
>>
>> Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
>> here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
>> can comment?
>
> Hi Mario:
>
> From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
> what you said above it appears you are using the "native Windows"
> cmake version from the mingw64 repository rather than the POSIX-style
> cmake package you can install from the msys2 repository.  I am pretty

Hmm, I don't think I have a native Windows cmake installed. I installed
mingw-w64-*-cmake from pacman, and I do not find any other cmake.exe in
PATH or on the hard disk. At least when I do:

#> find /c/ /d/ -name cmake.exe 2>/dev/zero
/d/msys2/bda/mingw32/bin/cmake.exe
/d/msys2/bda/mingw64/bin/cmake.exe

I find only the native MSYS2 mingw-w64-x86_64-cmake / mingw-w64-xi686-cmake.

All the best,

   Mario



> sure the native version would not do well with non-native POSIX-style
> paths so I am not surprised by your results.  Anyhow, I suggest you
> experiment with native versus POSIX cmake packages in both CMD and
> bash (from msys2) environments to establish what the different results
> are in those four cases for native Windows and POSIX paths.
>
> Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close
> attention to this platform because it is the best Windows platform for
> PLplot according to a fellow PLplot developer who does have a lot of
> practical experience with this platform.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

CHEVRIER, Marc
Be aware that MSYS2 environment is a "dual" environment:
* Unix like environment. Executables are in <MSYS2_ROOT>/usr/bin
* Windows like (i.e. understand windows paths but with slashes rather than back-slashes). Executables are in <MSYS2_ROOT>/ mingw(64|32)/bin.

So, if you want a pure unix like usage, you have to install package 'msys/cmake'.
If you use tool in mingw(32|64)/bin (package 'mingw32/mingw-w64-i686-cmake' or ' mingw64/mingw-w64-x86_64-cmake'), use windows paths (ex: C:/DESTDIR/lib/cmake).


On 12/02/2018 09:32, "CMake on behalf of Mario Emmenlauer" <[hidden email] on behalf of [hidden email]> wrote:

   
    Dear Alan,
   
    thanks for your reply! Below more:
   
    On 11.02.2018 23:11, Alan W. Irwin wrote:
    > On 2018-02-11 15:13+0100 Mario Emmenlauer wrote:
    >
    >>
    >> I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
    >> but just recently I started to have problems with CMAKE_PREFIX_PATH.
    >> Its possible that the problems have been there forever, but I now just
    >> found them due to a better use of CI systems.
    >>
    >> The problem is that cmake is not finding package configuration files
    >> correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
    >> XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
    >> and XXXTargets.cmake (i.e. for Qt, VTK and others).
    >>
    >> But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
    >> in Unix path style. It does work when I specify the package configuration
    >> directory in Windows style! This makes things quite confusing, because many
    >> find_xxx() commands for headers and libraries work with Unix paths. So now
    >> I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
    >> add WINDESTDIR\lib\cmake for the package configuration files (*).
    >>
    >> Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
    >> here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
    >> can comment?
    >
    > Hi Mario:
    >
    > From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
    > what you said above it appears you are using the "native Windows"
    > cmake version from the mingw64 repository rather than the POSIX-style
    > cmake package you can install from the msys2 repository.  I am pretty
   
    Hmm, I don't think I have a native Windows cmake installed. I installed
    mingw-w64-*-cmake from pacman, and I do not find any other cmake.exe in
    PATH or on the hard disk. At least when I do:
   
    #> find /c/ /d/ -name cmake.exe 2>/dev/zero
    /d/msys2/bda/mingw32/bin/cmake.exe
    /d/msys2/bda/mingw64/bin/cmake.exe
   
    I find only the native MSYS2 mingw-w64-x86_64-cmake / mingw-w64-xi686-cmake.
   
    All the best,
   
       Mario
   
   
   
    > sure the native version would not do well with non-native POSIX-style
    > paths so I am not surprised by your results.  Anyhow, I suggest you
    > experiment with native versus POSIX cmake packages in both CMD and
    > bash (from msys2) environments to establish what the different results
    > are in those four cases for native Windows and POSIX paths.
    >
    > Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close
    > attention to this platform because it is the best Windows platform for
    > PLplot according to a fellow PLplot developer who does have a lot of
    > practical experience with this platform.
    >
    > Alan
    > __________________________
    > Alan W. Irwin
    >
    > Astronomical research affiliation with Department of Physics and Astronomy,
    > University of Victoria (astrowww.phys.uvic.ca).
    >
    > Programming affiliations with the FreeEOS equation-of-state
    > implementation for stellar interiors (freeeos.sf.net); the Time
    > Ephemerides project (timeephem.sf.net); PLplot scientific plotting
    > software package (plplot.sf.net); the libLASi project
    > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
    > and the Linux Brochure Project (lbproject.sf.net).
    > __________________________
    >
    > Linux-powered Science
    > __________________________
    >
   
   
   
    Viele Gruesse,
   
        Mario Emmenlauer
   
   
    --
    BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
    Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
    D-81669 München                          http://www.biodataanalysis.de/
    --
   
    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:
    https://cmake.org/mailman/listinfo/cmake
   

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Mario Emmenlauer

Hi Marc,

On 12.02.2018 09:40, CHEVRIER, Marc wrote:
> Be aware that MSYS2 environment is a "dual" environment:
> * Unix like environment. Executables are in <MSYS2_ROOT>/usr/bin
> * Windows like (i.e. understand windows paths but with slashes rather than back-slashes). Executables are in <MSYS2_ROOT>/ mingw(64|32)/bin.
>
> So, if you want a pure unix like usage, you have to install package 'msys/cmake'.
> If you use tool in mingw(32|64)/bin (package 'mingw32/mingw-w64-i686-cmake' or ' mingw64/mingw-w64-x86_64-cmake'), use windows paths (ex: C:/DESTDIR/lib/cmake).

This is an interesting thought! I see that many tools from mingw(32|64)/bin
accept both path styles, and about 90% of my build system uses pure Unix
style. This is the first time I encounter a problem. Its at least interesting
that cmake seems slightly inconsistent here: it accepts Unix style for
CMAKE_PREFIX_PATH when using find_xxx(), but no Unix style for detecting
package configuration files.

I see now that the problem is more likely on my side. But on the other hand,
it would be cool if cmake could consistently accept Unix style on MSYS2/MinGW
platforms. Would it be worthwhile to make this a cmake issue?

All the best,

   Mario



>
> On 12/02/2018 09:32, "CMake on behalf of Mario Emmenlauer" <[hidden email] on behalf of [hidden email]> wrote:
>
>    
>     Dear Alan,
>    
>     thanks for your reply! Below more:
>    
>     On 11.02.2018 23:11, Alan W. Irwin wrote:
>     > On 2018-02-11 15:13+0100 Mario Emmenlauer wrote:
>     >
>     >>
>     >> I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
>     >> but just recently I started to have problems with CMAKE_PREFIX_PATH.
>     >> Its possible that the problems have been there forever, but I now just
>     >> found them due to a better use of CI systems.
>     >>
>     >> The problem is that cmake is not finding package configuration files
>     >> correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
>     >> XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
>     >> and XXXTargets.cmake (i.e. for Qt, VTK and others).
>     >>
>     >> But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
>     >> in Unix path style. It does work when I specify the package configuration
>     >> directory in Windows style! This makes things quite confusing, because many
>     >> find_xxx() commands for headers and libraries work with Unix paths. So now
>     >> I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
>     >> add WINDESTDIR\lib\cmake for the package configuration files (*).
>     >>
>     >> Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
>     >> here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
>     >> can comment?
>     >
>     > Hi Mario:
>     >
>     > From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
>     > what you said above it appears you are using the "native Windows"
>     > cmake version from the mingw64 repository rather than the POSIX-style
>     > cmake package you can install from the msys2 repository.  I am pretty
>    
>     Hmm, I don't think I have a native Windows cmake installed. I installed
>     mingw-w64-*-cmake from pacman, and I do not find any other cmake.exe in
>     PATH or on the hard disk. At least when I do:
>    
>     #> find /c/ /d/ -name cmake.exe 2>/dev/zero
>     /d/msys2/bda/mingw32/bin/cmake.exe
>     /d/msys2/bda/mingw64/bin/cmake.exe
>    
>     I find only the native MSYS2 mingw-w64-x86_64-cmake / mingw-w64-xi686-cmake.
>    
>     All the best,
>    
>        Mario
>    
>    
>    
>     > sure the native version would not do well with non-native POSIX-style
>     > paths so I am not surprised by your results.  Anyhow, I suggest you
>     > experiment with native versus POSIX cmake packages in both CMD and
>     > bash (from msys2) environments to establish what the different results
>     > are in those four cases for native Windows and POSIX paths.
>     >
>     > Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close
>     > attention to this platform because it is the best Windows platform for
>     > PLplot according to a fellow PLplot developer who does have a lot of
>     > practical experience with this platform.
>     >
>     > Alan
>     > __________________________
>     > Alan W. Irwin
>     >
>     > Astronomical research affiliation with Department of Physics and Astronomy,
>     > University of Victoria (astrowww.phys.uvic.ca).
>     >
>     > Programming affiliations with the FreeEOS equation-of-state
>     > implementation for stellar interiors (freeeos.sf.net); the Time
>     > Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>     > software package (plplot.sf.net); the libLASi project
>     > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>     > and the Linux Brochure Project (lbproject.sf.net).
>     > __________________________
>     >
>     > Linux-powered Science
>     > __________________________
>     >
>    
>    
>    
>     Viele Gruesse,
>    
>         Mario Emmenlauer
>    
>    
>     --
>     BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
>     Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
>     D-81669 München                          http://www.biodataanalysis.de/
>     --
>    
>     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:
>     https://cmake.org/mailman/listinfo/cmake
>    
>



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Alan W. Irwin
In reply to this post by Mario Emmenlauer
On 2018-02-12 09:32+0100 Mario Emmenlauer wrote:

[...]
>> Hi Mario:
>>
>> From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
>> what you said above it appears you are using the "native Windows"
>> cmake version from the mingw64 repository rather than the POSIX-style
>> cmake package you can install from the msys2 repository.  I am pretty
>
> Hmm, I don't think I have a native Windows cmake installed.

As Marc said in his post, be aware of the dual nature of this
platform. One side (the mingw64 repository) supplies native Windows
packages while the other (the msys2 repository) supplies a much
smaller number of Unix-like packages.  CMake packages happen to be in
both repositories!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Mario Emmenlauer

Hi,

ok I agree it might be cleaner to use Windows-style paths for all
cmake parameters on MSYS2. I changed my CI and everything works! :-)

But just as a side comment: It would be super cool if cmake would
support both styles for all parameters. The typical use on MSYS2 for
many commands is with Unix paths, and its great that cmake already
supports this so nicely. It really made things easier for me!

If its not a huge effort it would be great to have the same behaviour
also for the package configs.

Cheers and thanks,

   Mario




On 12.02.2018 10:23, Alan W. Irwin wrote:

> On 2018-02-12 09:32+0100 Mario Emmenlauer wrote:
>
> [...]
>>> Hi Mario:
>>>
>>> From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
>>> what you said above it appears you are using the "native Windows"
>>> cmake version from the mingw64 repository rather than the POSIX-style
>>> cmake package you can install from the msys2 repository.  I am pretty
>>
>> Hmm, I don't think I have a native Windows cmake installed.
>
> As Marc said in his post, be aware of the dual nature of this
> platform. One side (the mingw64 repository) supplies native Windows
> packages while the other (the msys2 repository) supplies a much
> smaller number of Unix-like packages.  CMake packages happen to be in
> both repositories!
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Alan W. Irwin
On 2018-02-12 13:06+0100 Mario Emmenlauer wrote:

>
> Hi,
>
> ok I agree it might be cleaner to use Windows-style paths for all
> cmake parameters on MSYS2. I changed my CI and everything works! :-)
>
> But just as a side comment: It would be super cool if cmake would
> support both styles for all parameters. The typical use on MSYS2 for
> many commands is with Unix paths, and its great that cmake already
> supports this so nicely. It really made things easier for me!
>
> If its not a huge effort it would be great to have the same behaviour
> also for the package configs.

I am glad you have found a satisfactory solution for your needs, but I
would like to respond to your further side comment about the broader
picture.

I am virtually positive from reading
<https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
PATHs is done by the MSYS2 dll.  Also, MinGW-w64/MSYS2 applications
from the msys2 repository are linked against that dll while the
applications from the mingw64 repository are pure native, i.e., not
linked against that dll.  Thus, if that mental model is correct, here
are some predictions that flow from it.

* The cmake version from the msys2 repository will understand cache
variables expressed as POSIX PATHs, but the cmake version from the
mingw64 repository wont have that capability.

* bash.exe (only available on MinGW-w64/MSYS2 from the msys2
repository for obvious reasons) will understand the POSIX version of
environment variables that represent PATHs.

* The combination of mingw64 cmake and bash will work for your
POSIX PATH needs if you are careful to use the bash environment variable
form of CMAKE_PREFIX_PATH rather than the cache variable
form of CMAKE_PREFIX_PATH.

I invite you to read the MinGW-w64/MSYS2 documentation to satisfy
yourself concerning that mental model.  And I also hope you do some
experiments to see whether the above predictions are correct.

By the way, I don't have access to Microsoft Windows myself but since
the MinGW-w64/MSYS2 platform is so important for PLplot I have tried
to get access to it via Wine-staging version of Windows just to help
my fellow PLplot developers with testing of MinGW-w64/MSYS2.
Unfortunately, the combination of MinGW-w64/MSYS2 and Wine-staging
that apparently worked a while ago no longer works at all, see
<https://github.com/TeaCI/tea-ci/wiki/Msys2-on-Wine>.  If you follow
the link there, apparently there is a lot of continuing interest in
getting this wine-staging bug fixed.  But while waiting for that, I am
in the frustrating position of only being able to make theoretical
predictions based on mental models as above rather than trying
MinGW-w64/MSYS2 for myself! Anyhow, if you get a chance to test out
some of the above predictions, I would be most interested in your
results.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Mario Emmenlauer

Dear Alan,

On 12.02.2018 22:09, Alan W. Irwin wrote:

> On 2018-02-12 13:06+0100 Mario Emmenlauer wrote:
>
>>
>> Hi,
>>
>> ok I agree it might be cleaner to use Windows-style paths for all
>> cmake parameters on MSYS2. I changed my CI and everything works! :-)
>>
>> But just as a side comment: It would be super cool if cmake would
>> support both styles for all parameters. The typical use on MSYS2 for
>> many commands is with Unix paths, and its great that cmake already
>> supports this so nicely. It really made things easier for me!
>>
>> If its not a huge effort it would be great to have the same behaviour
>> also for the package configs.
>
> I am glad you have found a satisfactory solution for your needs, but I
> would like to respond to your further side comment about the broader
> picture.
>
> I am virtually positive from reading
> <https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
> MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
> PATHs is done by the MSYS2 dll.  Also, MinGW-w64/MSYS2 applications
> from the msys2 repository are linked against that dll while the
> applications from the mingw64 repository are pure native, i.e., not
> linked against that dll.  Thus, if that mental model is correct, here
> are some predictions that flow from it.
>
> * The cmake version from the msys2 repository will understand cache
> variables expressed as POSIX PATHs, but the cmake version from the
> mingw64 repository wont have that capability.

I am not sure if I follow until here, but very likely I just misunderstand
what you are saying. Please help shed some light! In my observation, I
have cmake installed from mingw64 repository, and I can successfully use
this cmake with a CMAKE_PREFIX_PATH in POSIX PATH notation, as long as I
find all my dependencies with find_xxx() commands (i.e. find_library() or
find_file() or the like). I also use this same cmake with a path to the
source directory specified as POSIX PATH.

So to be 150% sure we mean the same, the following works for me, where
/d/ corresponds to the D: drive of Windows:
    /mingw64/bin/cmake /d/tmp/sources \
        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
    make && make install

Is that contradictory to your point above?

Cheers,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Alan W. Irwin
On 2018-02-12 23:06+0100 Mario Emmenlauer wrote:

> On 12.02.2018 22:09, Alan W. Irwin wrote:
[...]

>> I am virtually positive from reading
>> <https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
>> MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
>> PATHs is done by the MSYS2 dll.  Also, MinGW-w64/MSYS2 applications
>> from the msys2 repository are linked against that dll while the
>> applications from the mingw64 repository are pure native, i.e., not
>> linked against that dll.  Thus, if that mental model is correct, here
>> are some predictions that flow from it.
>>
>> * The cmake version from the msys2 repository will understand cache
>> variables expressed as POSIX PATHs, but the cmake version from the
>> mingw64 repository wont have that capability.
>
> I am not sure if I follow until here, but very likely I just misunderstand
> what you are saying. Please help shed some light!

I will try.  :-)

> In my observation, I
> have cmake installed from mingw64 repository, and I can successfully use
> this cmake with a CMAKE_PREFIX_PATH in POSIX PATH notation
> find all my dependencies with find_xxx() commands (i.e. find_library() or
> find_file() or the like). I also use this same cmake with a path to the
> source directory specified as POSIX PATH.
>
> So to be 150% sure we mean the same, the following works for me, where
> /d/ corresponds to the D: drive of Windows:
>    /mingw64/bin/cmake /d/tmp/sources \
>        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
>    make && make install
>
> Is that contradictory to your point above?

It certainly contradicts one of my predictions.

Just to clarify, the environment variable form of the above command
would have been (assuming your command-line environment is bash.exe
from the msys2 repository of MinGW-w64/MSYS2)

export CMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
/mingw64/bin/cmake /d/tmp/sources && make && make install

But instead, of using that environment variable form of the
command you used the
-DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
cmake option which sets CMAKE_PREFIX_PATH as a cache variable.

And for that cache variable approach, my prediction was the mingw64
version of cmake would not work with the above POSIX form of
CMAKE_PREFIX_PATH, but your experience is it does work!  So that
contradiction to the prediction is indeed an interesting result.

Just to cover off one possibility, could you try the bash printenv
command to print out all your bash environment variables to make sure
you have not inadvertently set the environment variable form of
CMAKE_PREFIX_PATH?  Of course, if you confirm this way that
CMAKE_PREFIX_PATH is not set as an environment variable, then it is
pretty clear something is incorrect/incomplete about the above mental
model.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Mario Emmenlauer
On 13.02.2018 01:08, Alan W. Irwin wrote:

> On 2018-02-12 23:06+0100 Mario Emmenlauer wrote:
>
>> On 12.02.2018 22:09, Alan W. Irwin wrote:
> [...]
>>> I am virtually positive from reading
>>> <https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
>>> MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
>>> PATHs is done by the MSYS2 dll.  Also, MinGW-w64/MSYS2 applications
>>> from the msys2 repository are linked against that dll while the
>>> applications from the mingw64 repository are pure native, i.e., not
>>> linked against that dll.  Thus, if that mental model is correct, here
>>> are some predictions that flow from it.
>>>
>>> * The cmake version from the msys2 repository will understand cache
>>> variables expressed as POSIX PATHs, but the cmake version from the
>>> mingw64 repository wont have that capability.
>>
>> I am not sure if I follow until here, but very likely I just misunderstand
>> what you are saying. Please help shed some light!
>
> I will try.  :-)
>
>> In my observation, I
>> have cmake installed from mingw64 repository, and I can successfully use
>> this cmake with a CMAKE_PREFIX_PATH in POSIX PATH notation
>> find all my dependencies with find_xxx() commands (i.e. find_library() or
>> find_file() or the like). I also use this same cmake with a path to the
>> source directory specified as POSIX PATH.
>>
>> So to be 150% sure we mean the same, the following works for me, where
>> /d/ corresponds to the D: drive of Windows:
>>    /mingw64/bin/cmake /d/tmp/sources \
>>        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
>>    make && make install
>>
>> Is that contradictory to your point above?
>
> It certainly contradicts one of my predictions.
>
> Just to clarify, the environment variable form of the above command
> would have been (assuming your command-line environment is bash.exe
> from the msys2 repository of MinGW-w64/MSYS2)
>
> export CMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
> /mingw64/bin/cmake /d/tmp/sources && make && make install
>
> But instead, of using that environment variable form of the
> command you used the
> -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
> cmake option which sets CMAKE_PREFIX_PATH as a cache variable.
>
> And for that cache variable approach, my prediction was the mingw64
> version of cmake would not work with the above POSIX form of
> CMAKE_PREFIX_PATH, but your experience is it does work!  So that
> contradiction to the prediction is indeed an interesting result.
>
> Just to cover off one possibility, could you try the bash printenv
> command to print out all your bash environment variables to make sure
> you have not inadvertently set the environment variable form of
> CMAKE_PREFIX_PATH?  Of course, if you confirm this way that
> CMAKE_PREFIX_PATH is not set as an environment variable, then it is
> pretty clear something is incorrect/incomplete about the above mental
> model.
I'm 99% certain that this variable is not defined, because I build
from a standard Cygwin shell started from a gitlab runner. But there
might be another piece of evidence that can help us further. When I
build as outlined above (here for reference):

    /mingw64/bin/cmake /d/tmp/sources \
        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
    make && make install

then the find_xxx() commands will work, but the cmake package
configurations fail. To get them also to work, I can switch to
Windows path styles:

    /mingw64/bin/cmake /d/tmp/sources \
        -DCMAKE_PREFIX_PATH="D:\\dest\\thirdparty;D:\\dest\\binaries" && \
    make && make install

then *everything* will work. So this should clarify that my POSIX path
was not automatically translated before, otherwise both invocations
would be identical, and the cmake package configurations should still
fail.

PS: Note that the source directory is *still* in POSIX path notation :-)

So its my understanding that cmake does have quite ok support for
POSIX paths on Windows, except for the cmake package configurations.

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: MSYS2 broken CMAKE_PREFIX_PATH

Alan W. Irwin
On 2018-02-13 15:22+0100 Mario Emmenlauer wrote:

> I'm 99% certain that this variable [the CMAKE_PREFIX_PATH
environment variable] is not defined, because I build

> from a standard Cygwin shell started from a gitlab runner. But there
> might be another piece of evidence that can help us further. When I
> build as outlined above (here for reference):
>
>    /mingw64/bin/cmake /d/tmp/sources \
>        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
>    make && make install
>
> then the find_xxx() commands will work, but the cmake package
> configurations fail. To get them also to work, I can switch to
> Windows path styles:
>
>    /mingw64/bin/cmake /d/tmp/sources \
>        -DCMAKE_PREFIX_PATH="D:\\dest\\thirdparty;D:\\dest\\binaries" && \
>    make && make install
>
> then *everything* will work. So this should clarify that my POSIX path
> was not automatically translated before, otherwise both invocations
> would be identical, and the cmake package configurations should still
> fail.
>
> PS: Note that the source directory is *still* in POSIX path notation :-)

Hi Mario:

My understanding is that POSIX-style CMAKE PATH variables must be
colon-delimited.  So what does your CMakeCache.txt file say about
CMAKE_PREFIX_PATH with the semicolon delimiter you used above in your
first (POSIX) variant, and just as an experiment what happens with
that cache file and also your results with that first version if you
change the semicolon to a colon, i.e.,

     /mingw64/bin/cmake /d/tmp/sources \
         -DCMAKE_PREFIX_PATH="/d/dest/thirdparty:/d/dest/binaries" && \
     make && make install

?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

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:
https://cmake.org/mailman/listinfo/cmake