equalsraf

#!/usr/bin/python3
#
# 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

equalsraf

executable()

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.

equalsraf

• 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)

equalsraf

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

equalsraf

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

equalsraf

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

equalsraf

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.

Requirements

• 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.)

equalsraf

So we still have some issues with the GUI clipboard.

My hypothesis is that because nvim is caching the has_clipboard static variable then the clipboard will always be considered as invalid and can NEVER be enabled.

Test setup

First I'm going to start nvim in a way that prevents any clipboard for working by changing the PATH.

equalsraf

Before you start you need a Mingw-w64 toolchain for Linux, try installing the mingw-w64 package (Ubuntu, Suse, Fedora?) or get it from the Mingw-w64 website.

Build dependencies

$ mkdir deps-mingw
$ cd deps-mingw
$ cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/mingw32-w64-cross-travis.toolchain.cmake ../third-party/
$ make
$ cd ..

equalsraf

It's been a while since I did this, so .... lets see what happens.

For starters we have this setup

• Windows 10 64 bit
• using VS code (with some cmake and C++/C extensions installed)
• installed cmake manually
• I'm doing this off two different computers, so these notes will not have output :S

Just to establish that we have everything we need to build neovim, I'm going to take the long route using cmake