On 2019/11/02 14:31, Travis Cole wrote: > Why not use the libluv port with Stuart's improvements?
>From my earlier mail, On 2019/10/21 13:12, Stuart Henderson wrote: > Reviewing libluv/luv again as asked by Edd, I got rather confused that > it installed libluv.so.0.0 in /usr/local/lib which isn't usable from Lua > (which would expect luv.so in /usr/local/lib/lua/5.x aka MODLUA_LIBDIR). > Of course running one of the test programs shown in upstream's docs fails > because Lua can't find it. > > After a while I figured out that this is the "Build as shared library" > option from https://github.com/luvit/luv/ and isn't usable from Lua > so I think at least the DESCR and COMMENT are misleading, and the > package name is a bit confusing too, "libluv" would be better. > It's also a bit fiddly because the lib uses functions from the Lua > shared library, so depends on a particular Lua version, but this isn't > recorded in libluv.so NEEDED section. ^^^ this is the main reason why I didn't like the libluv port. How would you propose to handle it if some other ports uses libluv but needs a different Lua version? > > Then I looked again at Neovim's "following head" page. "Nvim core > requires libluv. This may require building with -DUSE_BUNDLED_LUV=ON if > you were previously using -DUSE_BUNDLED_LUV=OFF". Since libluv is a bit > of an awkward port in several ways, would it be a better idea to just > use the bundled libluv instead? >
