This is required to (re)build e.g. libluv when the version changes
(which triggers a new download).
With `make deps`, changing the `LUV_URL`/`LUV_SHA256`, and `make deps` again:
Before:
> Up-to-date: /home/daniel/Vcs/neovim/.deps/usr/lib/libluv.a
After:
> Installing: /home/daniel/Vcs/neovim/.deps/usr/lib/libluv.a
See with https://github.com/neovim/neovim/pull/10358 - where .deps
contained libluv 1.29, the merge updates it to 1.30, but then it failed
to link because `libluv.a` is considered to be up-to-date (after
downloading the new version).
Note that header files get installed, since they have the original time
stamp, but `libluv.a` is being generated (does not use the timestamp
from the archive here, but needs to get rebuild).
It could be argued that the build system of the included project should
catch/handle this, but it seems to be good practice to clean the binary
/ build dir with a new download to start from scratch.
Ref: https://gitlab.kitware.com/cmake/cmake/issues/19452
Also fixes cmake/BuildLuv / luv-static: use name with -DTARGET for
download command, and pass (shared) `SRC_DIR` explicitly instead.
It's only appropriate to set CMAKE_MAKE_PROGRAM to gmake when we're
using the "Unix Makefiles" generator. On QB, the nodes have Ninja
available and will use it, which means CMAKE_GENERATOR is set to
"Ninja". Setting CMAKE_MAKE_PROGRAM was forcing the build to use gmake
instead of ninja, which was causing the build failure.
Luv is a simple lua binding to libuv, which is now used by neovim lua client.
The bundled luv installation a bit different from other dependencies in that it
is installed two times:
- The "BuildLuv.cmake" script downloads and installs a static version of luv
using its normal cmake build script. This static version will be used later.
- Luv default rockspec is replaced with the alternate under the "rockspecs"
directory(the alternate rockspec plays nicer with neovim build system)
- The alternate rockspec is used to build/install the lua module and make it
available to lua scripts.
