Logging getting a working neovim

Building from source with cmake

I tried this because of dependency hell (?) with msys packages, getting perl provider finding executable only once for unknown reasons.

irc.libera.chat#neovim build log

drbean: The windows/msys build instructions are out-of-date at https://neovim.io/doc/build/, no?
drbean: It doesn’t mention msys environments https://www.msys2.org/docs/environments/ and it’s mixing ucrt64 and mingw64 ones.
drbean: Packages.
drbean: This is the first time I’ve seen cmake in action. Its TUI influences weechat’s fset and scripts buffer look and feel I believe, though I’m not using its ncurses GUI.
drbean: I’m standardizing this msys neovim build attempt with the MINGW64 environment, not mxing in UCRT64.
drbean: I intend to put my attempt here and archive it on my web page to help me remember what happened.
drbean: cmake -S cmake.deps -B .deps -G Ninja -D CMAKE_BUILD_TYPE=RelWithDebInfo went OK.
drbean: Previously luajit build didn’t go OK. This time did.
drbean: And cmake --build .deps completed, with 128 steps.
drbean: But cmake -B build -G Ninja -D CMAKE_BUILD_TYPE=RelWithDebInfo was not able (with Ninja?) to find many header files.
drbean: cmake --build build 670 steps! It’s a long time since I built a C app from source.
drbean: It failed at step 112. The error is ” error UCRT is the only supported C runtime on windows”!!
drbean: So the header files it was looking for were not msys’s but the windows C runtime!
drbean: Perhaps I can replace the MINGW64 gcc with the UCRT64 one in cmake -B build -G Ninja -D CMAKE_BUILD_TYPE=RelWithDebInfo to
drbean: I know I’ll just stroll over to the msys UCRT64 terminal where gcc is in /ucrt64/bin
drbean: No. I’ll have to back up further. Remembering the dependencies:
drbean: gcc: /mingw64/bin/gcc, ie MINGW64
drbean: cmake: same, ie MINGW64
drbean: make: /usr/sbin ie MSYS
drbean: ninja: MINGW64
drbean: diffutils: MINGW64
drbean: Don’t I have to SETX PATH, and logout to prefix it with /ucrt64, rather than just open a new shell?

Later,

drbean: You can edit CMakeCache.txt.
drbean: I change ninja path to something.
drbean: Fail with msys/{cmake,make,ninja??,diffutils}

Trying msys packages again

I have the perl, python providers finding executables, and the node.js provider finding node.js but checkhealth is unable to find the mingw-w64-ucrt-x86_64-nodejs-neovim-5.4.0-1 package.

I think this partial success is connected to msys only half translating windows paths and neovim here being a windows app.

My experience with Msys2 is different than with cygwin, which is able to sweep its dependence on the underlying Windows OS underneath the carpet.

Msys2 doesn’t do that, according to https://www.msys2.org/wiki/MSYS2-introduction/, says google, because it’s providing a unix-like environment, CLI and repos to install, use, build software on Windows.

Paths and software invoked are either cygwin or windows like.

Jumping thru Language Service Protocol hoops

neovim’s implementation is a work-in-progress, I think.

The second/main/only purpose of the nodejs neovim package is use by the python-language-server, apparently.

I was getting checkhealth errors in python for it which I solved somehow, but it is still showing error in the nodejs one, which could be due to the Windows/MSYS mismatch.
So with the node, perl, etc providers, the paths,
```
 let g:node_host_prog = 'c:/ghcup/msys64/ucrt64/bin/neovim-node-host'
 let g:perl_host_prog = 'c:/ghcup/msys64/ucrt64/bin/perl'
 let g:python3_host_prog = 'c:/ghcup/msys64/ucrt64/bin/python3'
```
work. The executable is neovim-node-host which I only found digging deeply into neovim’s documentation.

Following the neovim-lspconfig package, which I can’t get nvim to load, invocation of bash-language-server was failing because not on PATH. Invoking bash-language-server.cmd does not fail!
lua-language-server executable was in /ucrt64/bin and returned without error, but I needed to read the non-neovim download docu to see it had to be in a dir with files it needs. (And I also forgot PATH)

The vim.lsp error message that the executable was not executable was unhelpful.

Me at

Backto HomePage