I found it often irritation to see the same comment about "DEPENDS"
there all the time. This uses the LuaRocks rock name as a comment
instead (which is hard to parse from the recipe), moves the note about
DEPENDS to the top (extended), and fixes/aligns some whitespace.
With LuaRocks 3 it will include the version, and this will make the
upgrade easier then.
It also makes sense to factor this out in general for clarity already.
Pulled out of https://github.com/neovim/neovim/pull/10292.
* build: update some test dependencies
* luacheck ignores
* BuildLua: add ${BUSTED} to depends for ${BUSTED_LUA}
This is required to rebuild it when busted gets updated.
This regressed in 204ec6337.
Currently it would detect/use lua5.3 from the system, but in general
luajit is / should be preferred.
Noticed this due to nvim-client failing to build with Lua 5.3
(https://github.com/neovim/lua-client/pull/43).
LuaRocks bundles an outdated wget.exe for downloading packages on Windows. It is too old to support GitHub's TLS, so this patch will replace it with curl.
Tracking master subjects us to breakages (as happened when
luacheck-scm-1.rockspec got renamed to luacheck-dev-1.rockspec) and
makes older releases unbuildable when that happens.
LuaRocks 2.3 and onwards changed the /P option to no longer include the
version number which made newer releases of LuaRocks fail when compiling
on Windows.
https://github.com/mpeterv/luacheck/pull/81#issuecomment-261099606
> If you really want to use bleeding-edge version you should get the
> rockspec from master branch, not a fixed commit ...
> The correct way to install from a specific commit is cloning that
> commit and running "luarocks make" from project directory. The reason
> is that running "install" or "build" on an scm rockspec fetches
> sources from master but uses build description from the rockspec
> itself, which may be outdated.
Using /MT was causing issues when building luarocks, revert it, use the
dynammic runtime and generate release DLLs for the dependencies.
Some refactoring was required because for linking cmake looks for the
import libraries (.lib) but on runtime executables we need the .dll files
to be in the same folder.
The DLLs are placed in the bin/ folder in order for nvim.exe to run
during the build and tests. The install target installs the DLLs with
the nvim binary - uses GetPrerequisites to find runtime DLLs.
Some minor issues that required adjustments:
- [MSVC] FindMsgpack.cmake now looks for msgpack_import.lib instead of
msgpack.lib
- The lua-client fails to find libuv.lib, instead it looks for uv.lib,
added second copy of the file to the install command.
- [MSVC] CMAKE_BUILD_TYPE affects the output paths, default to Release.
Part of these changes are credited to @jasonwilliams200OK who fixed the
third-party recipes to consistently use the same build type.
