On 2019/11/04 09:59, Edd Barrett wrote:
> On Sun, Nov 03, 2019 at 06:17:20PM -0800, Travis Cole wrote:
> > Debian has a package with 3 different luv.so files, one each for Lua 5.1, 
> > 5.2, 
> > and 5.3. Fedora has two packages, one for Lua 5.1 and one for Lua 5.3.
> > Debian and Fedora put them in lua/5.x, similar to your suggestion.
> 
> I was going to suggest something similar (e.g. luv-lua51.so), but let's
> look at your solution below as a first option.

If it turns out we need libluv for things other than neovim, then that's
probably the simplest way (different directories rather than filenames
usually make it easier to point other ports at the right one) - but
for now this feels like a sane approach.

> > -MAKE_FLAGS +=          USE_BUNDLED_DEPS=OFF
> > +MAKE_FLAGS +=          USE_BUNDLED=OFF
> >  CONFIGURE_ARGS +=      -DLUA_PRG=${MODLUA_BIN} \
> >                         -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR} \
> >                         -DLUA_LIBRARIES=${MODLUA_LIB} \
> > +                       -DUSE_BUNDLED_GPERF=Off \
> > +                       -DUSE_BUNDLED_UNIBILIUM=Off \
> > +                       -DUSE_BUNDLED_LIBTERMKEY=Off \
> > +                       -DUSE_BUNDLED_LIBVTERM=Off \
> > +                       -DUSE_BUNDLED_LIBUV=Off \
> > +                       -DUSE_BUNDLED_MSGPACK=Off \
> > +                       -DUSE_BUNDLED_LUAJIT=Off \
> > +                       -DUSE_BUNDLED_LUAROCKS=Off \
> > +                       -DUSE_BUNDLED_LUV=On \
> > +                       -DLIBLUV_INCLUDE_DIR=${WRKBUILD}/.deps/usr/include \
> > +                       -DLIBLUV_LIBRARY=${WRKBUILD}/.deps/usr/lib/libluv.a 
> > \
> >                         -DPREFER_LUA=ON # disables LuaJIT
> 
> It's kind of dd that USE_BUNDLED=OFF doesn't disable all of those other
> things that you explicitely turn off above, but if that's what's needed,
> then I guess we can live with it.

The joys of a build system which is a hybrid of cmake and Makefile!

> > It will also require the updated unibilium and libvterm that I'd
> > previously provided.
> 
> Right, so I will review these updates shortly. I wonder if the old
> neovim will work with the new versions...

I don't think it matters much either way, just commit the 3 together
if the new neovim is ok.

Reply via email to