bundle expected libuv via git subtree #99
Conversation
git-subtree-dir: third-party/libuv git-subtree-split: 3c4022464acd92607f21c6eef69330fb071d0400
Rename file to reflect new intent of script. Libuv is bundled into the third-party directory. Modify the script to compile but not fetch libuv.
get-libuv.sh was renamed to compile-libuv.sh
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.
|
I like the idea of packaging libuv with neovim. |
|
Agree with subtree solution. And in furthur future I wish it can be configure to use system libuv, this definitely makes distros maintainers happy. |
|
There's something to be said for all approaches here. Git subtree is definitely nice, I personally use a manual version by downloading new releases of dependencies and pasting them over the |
As it stands, a system supplied libuv will actually be used if CMake is used directly to compile neovim rather than using the That's a solution for a different day. |
|
Yes this is much better than downloading separately, thanks for this and sorry for taking so long to merge, I've been giving priority to code-related issues. |
As evidenced by #13 it is surprising to people that libuv is fetched at
make-time. This also necessitates an Internet connection and GitHub being up in order to compile neovim. Both of these requirements are similarly surprising to experienced developers.Since we mandate a particular version of libuv and are reticent to allow the use of system-supplied libraries, it makes sense to use
git subtreeto bundle that version directly into athird-partydirectory and modify the existingget-libuv.shscript to only compile that version. The use ofgit subtreealso has the advantage that a) the precise commit of libuv being used is recorded in the repository history and b) we can move to a later version of libuv directly by appropriategit subtreeincantation recorded in source history rather than fiddling withget-libuv.sh.Such an incantation might be:
$ git subtree merge --prefix=third-party/libuv --squash https://github.com/joyent/libuv $TAGwhere
$TAGis replaced by the tag name one wishes to merge.Use the
--squashparameter togit subtreeto avoid pulling in the entirety of libuv's history. This makes the difference in bandwidth required between bundling libuv and fetching a tarball directly negligible.The version of libuv which has been merged corresponds to the "v0.11.19" tag which at merge time pointed to joyent/libuv@336a182.
An alternative solution would be to separate compilation from dependency fetching. Perhaps moving the fetching to the
make cmakestage?This PR does not completely address #13 since, unless one notices the "build" instructions in the README, the usual
mkdir build && cd build && cmake .. && makerecipe for compilation will fail unexpectedly which is likely to lead to lots of #13 dupes being opened. Should this PR be merged, it may be prudent to modify the CMakeLists.txt file to compile the provided libuv either by "CMake-izing" libuv or callingcompile-libuv.shfrom CMake. This would allow compilation using the standard CMake build procedure. If nothing else, this would make packaging neovim a lot easier.