[CMake] CMake support for MYS2

[Mojca Miklavec]

On 10 January 2018 at 11:56, Konstantin Tokarev <annulen at yandex.ru> wrote:
> 10.01.2018, 11:40, "Mojca Miklavec" <mojca.miklavec.lists at gmail.com>:
>> On 8 January 2018 at 17:38, Konstantin Tokarev wrote:
>>>  08.01.2018, 14:35, "Mojca Miklavec":
>>>>  Dear CMake developers,
>>>>
>>>>  I installed msys2 from http://www.msys2.org/ and (after updating etc)
>>>>  installed cmake via
>>>>      pacman -S cmake
>>>
>>>  You should install mingw-w64-x86_64-cmake (or i686).
>>
>> Thank you very much. That package is missing ccmake though
>
> Please report it as a bug. cmake package should provide ccmake, or
> there should be a separate package if ncurses dependency is undesirable
> in the main package.

I can create a bug report, but I would like to clarify with CMake
developers first before I know what exactly to report in the first
place.

I'm pretty sure that this is a side-effect of CMake's own build
figuring out that it's being built on and for Windows, so it probably
skips building ccmake and builds cmake-gui.exe instead.

This all makes perfect sense for distributing the standalone
executable on Windows, but it's less suitable in the context of MSYS2.

>>, so I can
>> only run cmake directly and even then it strangely(?) defaults to
>> Visual Studio when I would expect it to go for Unix Makefiles.
>
> This is behavior of vanilla cmake, so it's reasonable that it is not altered.

I assume it belongs "to the same category" as the lack of ccmake.

I can imagine that it would make sense to offer to ways of building
cmake on Windows: the "standalone" mode without ccmake, with cmake-gui
and defaulting to Visual Studio. And the "command-line" mode with
ccmake and defaulting to "Unix Makefiles". Of course one could build
both ccmake and cmake-gui at the same time if desired.

We often have this problem with a Mac package manager. Many software
builds do "if this is mac, then standard unix tools don't exist, so do
something completely different" and they would create the app bundle,
but skip the rest of command-line friendliness and completely ignore
the fact that those unix tools may exist after all.

> You can use msys2 like a generic Windows software repository, not only
> for MinGW- or MSYS-based development.

I admit that I don't totally understand how exactly it's supposed to
work, but further discussion would be too off-topic for this list, I
assume.

>> (The "ccmake" from /usr/bin/ccmake is not helping in any way either, I
>> was hoping it would perhaps use mingw-w64-x86_64-cmake.)
>>
>> I later noticed that there is /mingw64/bin/cmake-gui.exe, but that one
>> doesn't really work either:
>>
>> $ cmake-gui
>> C:/msys/msys64/mingw64/bin/cmake-gui.exe: error while loading shared
>> libraries: librhash.dll: cannot open shared object file: No such file
>> or directory
>>
>>>  You've installed
>>>  package that targets MSYS environment, not native Windows.
>>
>> I still assume that others might run into exactly the same isuse in
>> the future. Since it's explicitly suggesting to write to the mailing
>> list, the reports might repeat.
>
> This is a packaging problem, so it should be reported to msys2
> maintainers first.

OK.

> in the meanwhile, you can edit CMakeCache.txt file directly, gui tools
> don't really add much :)

Well, I can always use
    cmake -G "..." -Dwhatever ../source
but ccmake is useful to show what configuration options the program is
offering. Editing CMakeCache is a feasible workaround, but I would
like to have a proper fix at the end.

Thanks a lot for all the useful insights.

Mojca