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
