Should fix the following travis error:
/usr/bin/ld: /opt/neovim-deps/lib/libluajit-5.1.a(lj_err.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/opt/neovim-deps/lib/libluajit-5.1.a: could not read symbols: Bad value
Apparently busted 1.11.0 is broken(https://github.com/Olivine-Labs/busted/issues/236)
in a way that is causing the unit tests to fail. This pins the version to 1.10.0
and also fixes a wrong variable set when msgpack was added as a dependency
As of v0.11.23 libuv's uv_timer_cb, uv_async_cb, uv_prepare_cb, uv_check_cb and
uv_idle_cb no longer require a status parameter (this went unused in the first
place).
Bump third-party dependency `libuv` up to 0.11.23 and remove the extra
parameters from the callbacks.
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.
This achieves several goals:
* Less reliance on scripts so we have better portability to Windows
(though we still have a ways to go for proper Windows support).
Luajit, luarocks, moonscript, and busted are all installed via CMake
now.
* Trying to make use of pkg-config to get the correct libraries. The
latest libuv is still broken in this regard, but we'll at least be in
a position to use it.
* Allow the use of Ninja or make. The former runs faster in many
environments, and automatically makes use of parallel builds.
This also allows for system installed dependencies--though not through
the Makefile just yet--and adds support for FreeBSD.
This also make us build libuv and luajit as static libraries only, since
we're only concerned about having static libraries for our bundled
dependencies.
Add a brief README on the purpose of the third-party directory and some
suggestions for how to manage it. The neovim bigwigs may want to
re-draft the README.
Florian Walch