On 2018-02-12 13:06+0100 Mario Emmenlauer wrote:


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

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

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


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: 

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 

Follow this link to subscribe/unsubscribe:

Reply via email to