- Remove unused function argument from GetBinaryDeps
- Remove unused variable LUA_LOAD_PACKAGE_MODULE_SOURCE
- Add LUA_FS_MODULE_SOURCE as a dependency of VIM_MODULE_FILE
The wintools executables are stored in a zip file, making it
inconvenient to bump these during releases. Instead, unpack the
executables in the deps repository and download each executable
separately.
We provide options such as "DEPS_BIN_DIR" for the user to set, but only
sometimes use them. This makes binaries and other files to be spread out
if the user defines a custom DEPS_BIN_DIR location.
This will reduce required boilerplate, but more importantly it will
automatically unset variables ending on URL. This will help people
needing to avoid to unset the URL variable each time a new dependency is
added.
It is possible that this may remove a non-download variable ending on
"URL" in the future, however, the risk of this is likely much lower than
the risk of someone forgetting to unset the variable.
Previously, all targets were connected in one main target called
third-party in order to remove any potentially conflicting shared
library. We can make each dependency target independent of each other by
only removing shared libraries from luajit and msgpack in their own
targets, as only these has unwanted shared libraries.
59d5f692f removed cmake.deps/cmake/DownloadAndExtractFile.cmake and
support for USE_EXISTING_SRC_DIR. The Ubuntu nightly PPA still relies
on USE_EXISTING_SRC_DIR functionality since it can't access the network
during the build.
Supplying an empty value for ExternalProject_Add()'s URL value appears
to provide the needed mechanism to avoid re-downloading when the sources
are already present. This is undocumented behavior, though, so it may
break in the future.
Now, if USE_EXISTING_SRC_DIR is set, the ExternalProject's URL variable
is unset, preventing the download and erroring out if the source doesn't
actually exist.
DownloadAndExtractFile.cmake was initially introduced as a workaround to
avoid the massive amounts of logs generated by the download progress.
This is not a problem anymore as ExternalProject_Add has had the
DOWNLOAD_NO_PROGRESS option since cmake version 3.1.
Problem:
Dirs "config", "packaging", and "third-party" are all closely related
but this is not obvious from the layout. This adds friction for new
contributors.
Solution:
- rename config/ to cmake.config/
- rename test/config/ to test/cmakeconfig/ because it is used in Lua
tests: require('test.cmakeconfig.paths').
- rename packaging/ to cmake.packaging/
- rename third-party/ to cmake.deps/ (parallel with .deps/)
