cmake fails to find a usable lua

... even if packages for lua and all deps(mpack, bitop, lpeg) are installed. This seems to be a problem with the lua binary name in OpenBSD its called lua51, lua52, luajit51 - instead of the expected lua5.1 or just lua.

The workaround for this is to specify the binary


TLDR; it did not work, apparently the major blocker is libuv support

1. dependencies (i.e. nvim's third-party/)

Haiku already has some deps, lets use its packages. But for libvterm, etc we need to use third-party

mkdir .deps
cd .deps



In Windows we build using the toolchain provided by MSYS2 - the resulting binaries DO NOT link against the MSYS2 runtime.

Start by installing the necessary dependencies


CMake Generators

CMake has two generatores using Make for windows.

  • MinGW Makefiles expects to run from the cmd shell (uses mingw32-make)

Vim's system('string') interface is not always straightforward in Windows, its behaviour can be downright unexpected involves an intricate set of options. Its primary purpose its to execute a command in the shell (see &shell) in simple terms we can think that calling system('some command') is equivalent to spawning a process with the following arguments

[&shell, &shellcmdflag, 'some command']

and sometimes this might be true but it also might not. Consider the following examples (I'm running in gVim 7.4/Windows 8)


The problem

I thought this was fixed earlier, but the following fails to execute if shell=cmd.exe

:echo system('cd /d "c:\Windows"')

Take the following script



os_can_exe() used by executable() actually checks PATHEXT. Behaviour in Vim is:

executable('no_such_file') returns 0
executable('file') returns 1 if file.bat,file.exe,etc exist ($PATHEXT)
executable('file.bat')returns 1
executable('file.exe')returns 1

This could lead to the misconception that, for example, executable("file.bat") being 1 implies that system(["file.bat"]) is expected to succeed, which is not true. But this is an issue with system([]) in windows and not with executable(). The notion of executable in Windows is fundamentaly a shell concept, because unlike UNIX there no notion of shebang and permission bits, that allows execution of non binary files.

# Little script to check if Appveyor is stuck
# The return code is (2) if the build is considered stuck, (0) if not
# stuck, and (1) for other errors
import json
import sys
import requests

TLDR; no, libuv doesn't work in Cygwin just yet, see at the bottom.


I tested using the master branch (9d3449852bd35c9283948186d0259c1bf73b8579 or later)

I installed the following in the cygwin setup

  • gcc-c++ make cmake pkg-config libtool
View gist:4685f7aef022a36c26d5

Check the pull request for the changes and the main issue for discussion. If you run into trouble check the Known Errors section at the end, or drop me a comment.


  • MSVC 2015, cl should report > 19.*
  • Python 2 (required by libuv to get gyp) - python 3 will not work, see the issue
  • Git (required by libuv to get gyp)
  • libintl
  • You might need the Windows 10 SDK to be installed (unverified, please drop me a comment in #810, specially if you are in Windows8 or lower.)