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.
Introduce ALLOW_EXISTING_SRC_DIR option, turned off by default.
The Homebrew formula, which downloads and extracts the third-party
dependency sources before starting the build, would turn this option
ON.
It turns out that `file(DOWNLOAD ...)` is not very user friendly with
it's error message, and only supports MD5 on v2.8.10 of CMake (the
default for Ubuntu 12.04). If CMake is built without SSL support,
users are left hanging with a message that the hashes don't match.
It turns out that `file(SHA1 ...)` exists in v2.8.10, and we
can use that to compute the hash ourselves. So this splits the hash
checking into a separate step, where we can provide some additional
advice if the SHA1 is the hash for an empty file. Additionally, it also
allows us to drop the MD5 hashes and maintain only SHA1 hashes for our
dependencies.
This is useful when trying to bisect an issue in a dependency, and we
want to pull from a specific commit but don't want to have to download
and determine the sha1sum and md5sum of the tarball.
When building under Homebrew, we want to let Homebrew manage
downloading and extracting the tarballs. See PR #1411.
Also make sure to skip only if directory is not empty. Fix#1433.
Underneath the hood, CMake uses libcurl and libcurl has had a number of
issues regarding progress feedback. In one sample run against Travis
CI, we ended up with nearly 3,000 lines of progress output for a single
download.
Unfortunately, CMake doesn't have the download and extract steps
separate, so we have some extra work that we have to do. Much of the
content was taken from the ExternalProject.cmake and it's template for
generating the content of the download and extract CMake files.
