3 ms·
pacman -S mingw-w64-{x86_64,i686}-cmake There's you out of the box. You might have tried pacman -S cmake which will have gotten you the msys/cmake package whic
by RayDonnelly 11y ago
pacman -S mingw-w64-{x86_64,i686}-cmake
There's you out of the box. You might have tried pacman -S cmake which will have gotten you the msys/cmake package which is used for building the packages in the msys repo (i.e. those linked to msys-2.0.dll). Having to add the mingw-w64-.. prefix is kind of strange, but you get used to it.
- xaduha 11y agoNope, cmake that was working OOB was installed separately, from https://cmake.org/download https://cmake.org/download I'll try your suggestion and report back.
- RayDonnelly 11y agoWell, we package our own software so we can work around any quirks that our system introduces, but actually generic cmake should work fairly well out of the box. The difference will the down to path translation. We don't stick to the old MSYS rules precisely as that code was re-written for MSYS2. MSYS2_ARG_CONV_EXCL can be used to prevent specific translations from happening too. A bug report would be appreciated anyway.
- xaduha 11y agoSure, I'll make a bug report, should it go here? https://github.com/alexpux/mingw-packages https://github.com/alexpux/mingw-packages BTW thing that I was able to compile with old MSYS + cmake from cmake.org, but can't with MSYS2 and mingw-w64-i686-cmake is https://github.com/Absolight/pkcs11-proxy https://github.com/Absolight/pkcs11-proxy
- RayDonnelly 11y agoYeah, but you need to be clear that it wasn't our cmake build of course. Generally get used using, asking for and contributing to MSYS2 packages if you can. That way everyone benefits. It's not the norm on Windows, but it very much should be.