cmd.exe vs msys2 shell

7059.md

• Aug 13 2017 lua-mpack is now available in mingw-packages.
• issue#7059

CMake Generators

CMake has two generatores using Make for windows.

• MinGW Makefiles expects to run from the cmd shell (uses mingw32-make)
• MSYS Makefiles expects to run from a MSYS shell i.e. sh/bash/etc

Why do we build from cmd.exe (-G "MinGW Makefiles")

The main reason why we build in cmd.exe is because of third-party. The luarocks recipe expects to run .bat files, and these cannot be executed from inside the msys2 shell. You can invoke a .bat from the shell using cmd.exe, but this requires escaping the commands properly, which is non trivial for arbitrary commands.

This extends to other build commands like the lua dependencies built through luarocks, and to the invocation of busted for tests. In a nutshell a lot of stuff in windows are actually .bat files.

Building with MinGW Makefiles (in cmd.exe)

The instructions in the wiki use this method. But this require some extra setup involving your PATH

1. to include the MSYS mingw64 path
2. to avoid a cmake error

This is the error you get(2.), cmake refuses to proceed if sh.exe is in PATH when using "MinGW Makefiles"

CMake Error at C:/msys64/mingw64/share/cmake-3.7/Modules/CMakeMinGWFindMake.cmake:12 (message):
  sh.exe was found in your PATH, here:
  C:/projects/neovim/.deps/build/src/libtermkey-build/"CMAKE_SH-NOTFOUND"
  For MinGW make to work correctly sh.exe must NOT be in your path.
  Run cmake from a shell that does not have sh.exe in your PATH.
  If you want to use a UNIX shell, then use MSYS Makefiles.
Call Stack (most recent call first):

If you retry it enough times it will actually work. But some of the third-party recipes have nested calls to cmake that lack the previous work around. You may be able to work around this using -DCMAKE_SH="CMAKE_SH-NOTFOUND" but this needs further study.

We work around this issue in appveyor builds by removing all path entries that have sh.exe (git, and msys2/usr/bin) while specifying some binary paths manually.

Finding a work around for this and patching third-party would probably simplify the appveyor PATH weirdness a good bit. But I keep getting contradictory results on this.

Building with MSYS Makefiles (in the MSYS MINGW64 shell)

Try to build with this recipe (-DUSE_BUNDLED_LUAROCKS=NO will disable the tests and development dependencies)

mkdir .deps
cd .deps
cmake -G "MSYS Makefiles" -DUSE_BUNDLED_LUAROCKS=NO ../third-party
make
cd ..
mkdir build
cd build
cmake -G "MSYS Makefiles" ..
make

Here is a branch with an partial appveyor recipe using the msys mingw64 shell.

Appveyor specifics

Even if we could do a full build from within the msys2 mingw shell, there are some Appveyor issues to handle:

• when calling the mingw environment shell bash -l Windows environment variables are discarded. Some of those are needed for build parameters. This could be solved by generating a script with these variables from appveyor.yml, and source it in a bash build script.
• override the path to avoid conflicts with other installed tools (we already do this anyway)
• manually calling a msys shell is done with the MSYSTEM=MINGW64 environment var and then running msys2/usr/bin/bash -l
• it is unclear to me if we can use python2/3 installed via the msys pacman. The binaries work but I had some issues with pip and the neovim module.