Re: Neovim update and new libluv port
On Mon, Nov 18, 2019, at 19:51, Travis Cole wrote:
> On Mon, Nov 18, 2019 at 09:10:12PM +, Stuart Henderson wrote:
> > On 2019/11/18 17:16, Edd Barrett wrote:
> > > Hi everyone,
> > >
> > > On Sat, Nov 16, 2019 at 11:23:37AM -0800, Travis Cole wrote:
> > > > I have an updated diff.
> > >
> > > I believe the neovim update to be ready.
> > >
> > > I'm looking for OKs for the attached diffs. Any takers?
> >
> > Basically OK, a few comments in-line:
>
> Hey Stuart,
>
> I've attached two updated diffs that I hope address all of your
> comments.
>
> Let me know if you'd like to see any more tweaks.
Here is an updated unibillium diff after running:
make clean; make patch; make update-patches.
(Sorry for responding to the previous email, I had some email availability
issues last night
and missed a response)diff --git a/Makefile b/Makefile
index ddf0f18..1ea5cc4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,20 +1,22 @@
# $OpenBSD: Makefile,v 1.2 2019/07/12 20:46:03 sthen Exp $
COMMENT = very basic terminfo library
-VERSION = 1.2.0
+VERSION = 2.0.0
DISTNAME = unibilium-${VERSION}
-GH_ACCOUNT = mauke
+GH_ACCOUNT = neovim
GH_PROJECT = unibilium
GH_TAGNAME = v${VERSION}
-SHARED_LIBS += unibilium 0.0 # 3.0
+SHARED_LIBS += unibilium 1.0 # 4.0
CATEGORIES = devel
# LGPLv3+
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
MAKE_FLAGS = PREFIX=${PREFIX} \
MANDIR=${PREFIX}/man
diff --git a/distinfo b/distinfo
index 61047b4..b531af4 100644
--- a/distinfo
+++ b/distinfo
@@ -1,2 +1,2 @@
-SHA256 (unibilium-1.2.0.tar.gz) = YjrxCZUV5nOr/TyuXy+oCKCcpV3aHGWntclCTrME6tg=
-SIZE (unibilium-1.2.0.tar.gz) = 88488
+SHA256 (unibilium-2.0.0.tar.gz) = eJl9ONTIF3xg09DBqoxT/QgG6yGCW3szWxdo1xFrwcE=
+SIZE (unibilium-2.0.0.tar.gz) = 112570
diff --git a/patches/patch-Makefile b/patches/patch-Makefile
index 366b113..bb4e7bd 100644
--- a/patches/patch-Makefile
+++ b/patches/patch-Makefile
@@ -2,9 +2,10 @@ $OpenBSD: patch-Makefile,v 1.1.1.1 2017/01/19 19:44:47 edd Exp $
No compressed manuals please.
Makefile.orig Tue Jan 17 22:55:47 2017
-+++ Makefile Tue Jan 17 22:57:02 2017
-@@ -47,7 +47,7 @@ OBJECTS=unibilium.lo uninames.lo uniutil.lo
+Index: Makefile
+--- Makefile.orig
Makefile
+@@ -56,7 +56,7 @@ OBJECTS=unibilium.lo uninames.lo uniutil.lo
LIBRARY=libunibilium.la
PODS=$(wildcard doc/*.pod)
@@ -13,7 +14,7 @@ No compressed manuals please.
TOOLS=$(wildcard tools/*.c)
-@@ -111,5 +111,5 @@ install-man: build-man
+@@ -121,8 +121,8 @@ install-man: build-man
.PHONY: build-man
build-man: $(MANPAGES)
@@ -21,3 +22,6 @@ No compressed manuals please.
- $(POD2MAN) $(POD2MAN_OPTS) $< | gzip > $@
+man/%.3: doc/%.pod
+ $(POD2MAN) $(POD2MAN_OPTS) $< > $@
+
+
+ .PHONY: regenerate-tests
diff --git a/pkg/PLIST b/pkg/PLIST
index 683d93b..2012515 100644
--- a/pkg/PLIST
+++ b/pkg/PLIST
@@ -1,6 +1,6 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2017/01/19 19:44:47 edd Exp $
include/unibilium.h
-lib/libunibilium.a
+@static-lib lib/libunibilium.a
lib/libunibilium.la
@lib lib/libunibilium.so.${LIBunibilium_VERSION}
lib/pkgconfig/unibilium.pc
Re: Neovim update and new libluv port
On 2019/11/18 19:51, Travis Cole wrote:
> On Mon, Nov 18, 2019 at 09:10:12PM +, Stuart Henderson wrote:
> > On 2019/11/18 17:16, Edd Barrett wrote:
> > > Hi everyone,
> > >
> > > On Sat, Nov 16, 2019 at 11:23:37AM -0800, Travis Cole wrote:
> > > > I have an updated diff.
> > >
> > > I believe the neovim update to be ready.
> > >
> > > I'm looking for OKs for the attached diffs. Any takers?
> >
> > Basically OK, a few comments in-line:
>
> Hey Stuart,
>
> I've attached two updated diffs that I hope address all of your
> comments.
>
> Let me know if you'd like to see any more tweaks.
OK sthen@ as-is for libvterm.
unibilium needs "make clean; make patch; make update-patches" to regen
patches compared to the last version I found (in a mail from edd@) then
that is OK sthen@.
neovim is missing some MAKE_ENV setting (noticed because build fails
with USE_CCACHE=Yes). Updated diff for that attached (I also split the
separate commands in pre-configure onto their own lines to make it
easier to read) is OK sthen@.
Index: Makefile
===
RCS file: /cvs/ports/editors/neovim/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile9 Jul 2019 09:46:16 - 1.18
+++ Makefile19 Nov 2019 13:26:11 -
@@ -4,15 +4,24 @@ COMMENT = continuation and extension of
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.3
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
MAINTAINER = Edd Barrett
+# Neovim must be statically linked with libluv, which isn't yet ported.
+LUV_VER = 1.30.1-1
+LUV = luv-${LUV_VER}
+MASTER_SITES0 =
https://github.com/luvit/luv/releases/download/${LUV_VER}/
+DISTFILES =${DISTNAME}${EXTRACT_SUFX} \
+ ${LUV}${EXTRACT_SUFX}:0
+
# Apache 2.0 + Vim License
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
WANTLIB += unibilium util uv vterm
@@ -38,10 +47,12 @@ RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-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} \
+ -DLIBLUV_INCLUDE_DIR=${WRKBUILD}/deps/include \
+ -DLIBLUV_LIBRARY=${WRKBUILD}/deps/lib/libluv.a \
-DPREFER_LUA=ON # disables LuaJIT
# Tests need gmake
@@ -51,13 +62,46 @@ TEST_DEPENDS = shells/bash \
editors/py-neovim \
editors/py-neovim,python3
+# Build libluv first as a static library. We opted not to create a libluv
+# port because it must be built for a specific Lua version and we don't know
+# what version future ports might need. Currently no other port requires
+# libluv, so it's simpler to build a static library here.
+#
+# Most of this target is lifted from ${MODCMAKE_configure} in cmake.port.mk.
+# Unfortunately we can't use it directly, as some of the arguments make
+# assumptions that can't work for us here.
+pre-configure:
+ mkdir -p ${WRKBUILD}/build
+ cd ${WRKBUILD}/build && \
+ ${SETENV} CC="${CC}" \
+ CXX="${CXX}" \
+ CFLAGS="${CFLAGS}" \
+ CXXFLAGS="${CXXFLAGS}" \
+ ${CONFIGURE_ENV} \
+ ${LOCALBASE}/bin/cmake \
+ -DBUILD_MODULE=OFF \
+ -DCMAKE_COLOR_MAKEFILE=OFF \
+ -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
+ -DCMAKE_INSTALL_PREFIX=${WRKBUILD}/deps \
+ -DLUA_BUILD_TYPE=System \
+ -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR} \
+ -DLUA_LIBRARIES=${MODLUA_LIB} \
+ -DWITH_LUA_ENGINE=Lua \
+ ${WRKDIR}/${LUV}
+ cd ${WRKBUILD}/build && \
+ ${SETENV} ${MAKE_ENV} VERBOSE=1 \
+ ${MAKE_PROGRAM}
+ cd ${WRKBUILD}/build && \
+ ${SETENV} ${MAKE_ENV} VERBOSE=1 \
+ ${MAKE_PROGRAM} install
+
# These are the "old tests". There is also a new suite, but we would need the
# "busted" test suite for Lua, which is not yet ported.
#
# There is currently one (minor) test failure:
# https://github.com/neovim/neovim/issues/10420
do-test:
- cd ${WRKSRC}/src/nvim/testdir && env LC_CTYPE=en_US.UTF-8 \
+ cd ${WRKSRC}/src/nvim/testdir && ${SETENV} LC_CTYPE=en_US.UTF-8 \
${MAKE_PROGRAM} NVIM_PRG=${WRKBUILD}/bin/nvim ${MAKE_FLAGS}
.include
Index: distinfo
===
RCS file: /cvs/ports/editors/neovim/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo9 Jul 2019 09:46:16
Re: Neovim update and new libluv port
On Mon, Nov 18, 2019 at 09:10:12PM +, Stuart Henderson wrote:
> On 2019/11/18 17:16, Edd Barrett wrote:
> > Hi everyone,
> >
> > On Sat, Nov 16, 2019 at 11:23:37AM -0800, Travis Cole wrote:
> > > I have an updated diff.
> >
> > I believe the neovim update to be ready.
> >
> > I'm looking for OKs for the attached diffs. Any takers?
>
> Basically OK, a few comments in-line:
Hey Stuart,
I've attached two updated diffs that I hope address all of your
comments.
Let me know if you'd like to see any more tweaks.
--
-tcole
diff --git Makefile Makefile
index 0063676..c8bf3a7 100644
--- Makefile
+++ Makefile
@@ -1,22 +1,27 @@
-# $OpenBSD:
+# $OpenBSD$
COMMENT = VT220/xterm/ECMA-48 terminal emulator library
# No releases, so use date and a git hash.
# Note that the github repo is a mirror of a bzr repo.
-VERSION = 20170211
+VERSION = 20191009
DISTNAME = libvterm-${VERSION}
GH_ACCOUNT = neovim
GH_PROJECT = libvterm
-GH_COMMIT =224b8dcde1c9640c29a34aa60c0f0d56ad298449
+# Note this git sha is from the nvim branch because
+# Neovim requires patches from this branch to build.
+# see https://github.com/neovim/neovim/wiki/Deps
+GH_COMMIT =7c72294d84ce20da4c27362dbd7fa4b08cfc91da
-SHARED_LIBS += vterm 0.0 # 0.0
+SHARED_LIBS += vterm 1.0 # 0.0
CATEGORIES = devel
# MIT
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
WANTLIB += c
USE_GMAKE =Yes
diff --git distinfo distinfo
index 63c4d8e..4c90892 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libvterm-20170211-224b8dcd.tar.gz) =
W8Dol01zXaTVrjOGrEEiylL+gPHFMveyO3nGPsXYzs0=
-SIZE (libvterm-20170211-224b8dcd.tar.gz) = 67291
+SHA256 (libvterm-20191009-7c72294d.tar.gz) =
8wxNQ+DG2z4JEtr3GI2Y+/buiPl1idcvbzBOXbSIJqg=
+SIZE (libvterm-20191009-7c72294d.tar.gz) = 73002
diff --git patches/patch-bin_vterm-ctrl_c patches/patch-bin_vterm-ctrl_c
index 529b571..a3f5e1a 100644
--- patches/patch-bin_vterm-ctrl_c
+++ patches/patch-bin_vterm-ctrl_c
@@ -1,16 +1,42 @@
-$OpenBSD: patch-bin_vterm-ctrl_c,v 1.1.1.1 2017/02/28 22:40:11 edd Exp $
+$OpenBSD$
Fix signed versus unsigned comparison.
https://bugs.launchpad.net/libvterm/+bug/1668780
bin/vterm-ctrl.c.orig Sun Dec 18 21:03:40 2016
-+++ bin/vterm-ctrl.c Sat Feb 25 16:29:14 2017
-@@ -81,7 +81,7 @@ static char *read_csi()
+Patch updated to apply on:
+https://github.com/neovim/libvterm/tree/nvim
+
+diff --git bin/vterm-ctrl.c bin/vterm-ctrl.c
+index ba0d61e..92a365f 100644
+--- bin/vterm-ctrl.c
bin/vterm-ctrl.c
+@@ -79,9 +79,9 @@ static bool seticanon(bool icanon, bool echo)
+ return ret;
+ }
+
+-static void await_c1(unsigned char c1)
++static void await_c1(int c1)
{
- /* TODO: This really should be a more robust CSI parser
-*/
-- char c;
+- unsigned char c;
+ int c;
/* await CSI - 8bit or 2byte 7bit form */
bool in_esc = false;
+@@ -106,7 +106,7 @@ static char *read_csi()
+ char csi[32];
+ int i = 0;
+ for(; i < sizeof(csi)-1; i++) {
+-char c = csi[i] = getchar();
++int c = csi[i] = getchar();
+ if(c >= 0x40 && c <= 0x7e)
+ break;
+ }
+@@ -125,7 +125,7 @@ static char *read_dcs()
+ bool in_esc = false;
+ int i = 0;
+ for(; i < sizeof(dcs)-1; ) {
+-char c = getchar();
++int c = getchar();
+ if(c == 0x9c) // ST
+ break;
+ if(in_esc && c == 0x5c)
diff --git pkg/PLIST pkg/PLIST
index 58b664f..a4cc9ea 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -4,7 +4,7 @@
@bin bin/vterm-dump
include/vterm.h
include/vterm_keycodes.h
-lib/libvterm.a
+@static-lib lib/libvterm.a
lib/libvterm.la
@lib lib/libvterm.so.${LIBvterm_VERSION}
lib/pkgconfig/vterm.pc
diff --git Makefile Makefile
index e9b174a..a53c40c 100644
--- Makefile
+++ Makefile
@@ -4,15 +4,24 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.3
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
MAINTAINER = Edd Barrett
+# Neovim must be statically linked with libluv, which isn't yet ported.
+LUV_VER = 1.30.1-1
+LUV = luv-${LUV_VER}
+MASTER_SITES0 =
https://github.com/luvit/luv/releases/download/${LUV_VER}/
+DISTFILES =${DISTNAME}${EXTRACT_SUFX} \
+ ${LUV}${EXTRACT_SUFX}:0
+
# Apache 2.0 + Vim License
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
WANTLIB += unibilium util uv vterm
@@ -38,10 +47,12 @@ RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-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} \
+
Re: Neovim update and new libluv port
On 2019/11/18 17:16, Edd Barrett wrote:
> Hi everyone,
>
> On Sat, Nov 16, 2019 at 11:23:37AM -0800, Travis Cole wrote:
> > I have an updated diff.
>
> I believe the neovim update to be ready.
>
> I'm looking for OKs for the attached diffs. Any takers?
Basically OK, a few comments in-line:
> diff --git Makefile Makefile
> index 0063676..793389b 100644
> --- Makefile
> +++ Makefile
> @@ -1,22 +1,29 @@
> -# $OpenBSD:
> +# $OpenBSD$
>
> COMMENT =VT220/xterm/ECMA-48 terminal emulator library
> # No releases, so use date and a git hash.
> # Note that the github repo is a mirror of a bzr repo.
> -VERSION =20170211
> +VERSION =20191009
> DISTNAME = libvterm-${VERSION}
>
> GH_ACCOUNT = neovim
> GH_PROJECT = libvterm
> -GH_COMMIT = 224b8dcde1c9640c29a34aa60c0f0d56ad298449
> +# Note this git sha is from the nvim branch because
> +# Neovim requires patches from this branch to build.
> +# see https://github.com/neovim/neovim/wiki/Deps
> +GH_COMMIT = 7c72294d84ce20da4c27362dbd7fa4b08cfc91da
>
> -SHARED_LIBS += vterm 0.0 # 0.0
> +# Note upstream doesn't bump the library version properly.
> +# Diff the headers and check for bump-worthy changes.
Please drop this comment, the same thing applies to nearly every
port with shared libraries
> +SHARED_LIBS += vterm 1.0 # 0.0
>
> CATEGORIES = devel
>
> # MIT
> PERMIT_PACKAGE = Yes
>
> +DEBUG_PACKAGES = ${BUILD_PACKAGES}
> +
> WANTLIB += c
>
> USE_GMAKE = Yes
> diff --git distinfo distinfo
> index 63c4d8e..4c90892 100644
> --- distinfo
> +++ distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (libvterm-20170211-224b8dcd.tar.gz) =
> W8Dol01zXaTVrjOGrEEiylL+gPHFMveyO3nGPsXYzs0=
> -SIZE (libvterm-20170211-224b8dcd.tar.gz) = 67291
> +SHA256 (libvterm-20191009-7c72294d.tar.gz) =
> 8wxNQ+DG2z4JEtr3GI2Y+/buiPl1idcvbzBOXbSIJqg=
> +SIZE (libvterm-20191009-7c72294d.tar.gz) = 73002
> diff --git patches/patch-bin_vterm-ctrl_c patches/patch-bin_vterm-ctrl_c
> index 529b571..a3f5e1a 100644
> --- patches/patch-bin_vterm-ctrl_c
> +++ patches/patch-bin_vterm-ctrl_c
> @@ -1,16 +1,42 @@
> -$OpenBSD: patch-bin_vterm-ctrl_c,v 1.1.1.1 2017/02/28 22:40:11 edd Exp $
> +$OpenBSD$
>
> Fix signed versus unsigned comparison.
> https://bugs.launchpad.net/libvterm/+bug/1668780
>
> bin/vterm-ctrl.c.origSun Dec 18 21:03:40 2016
> -+++ bin/vterm-ctrl.c Sat Feb 25 16:29:14 2017
> -@@ -81,7 +81,7 @@ static char *read_csi()
> +Patch updated to apply on:
> +https://github.com/neovim/libvterm/tree/nvim
> +
> +diff --git bin/vterm-ctrl.c bin/vterm-ctrl.c
> +index ba0d61e..92a365f 100644
> +--- bin/vterm-ctrl.c
> bin/vterm-ctrl.c
> +@@ -79,9 +79,9 @@ static bool seticanon(bool icanon, bool echo)
> + return ret;
> + }
> +
> +-static void await_c1(unsigned char c1)
> ++static void await_c1(int c1)
> {
> - /* TODO: This really should be a more robust CSI parser
> -*/
> -- char c;
> +- unsigned char c;
> + int c;
>
> /* await CSI - 8bit or 2byte 7bit form */
> bool in_esc = false;
> +@@ -106,7 +106,7 @@ static char *read_csi()
> + char csi[32];
> + int i = 0;
> + for(; i < sizeof(csi)-1; i++) {
> +-char c = csi[i] = getchar();
> ++int c = csi[i] = getchar();
> + if(c >= 0x40 && c <= 0x7e)
> + break;
> + }
> +@@ -125,7 +125,7 @@ static char *read_dcs()
> + bool in_esc = false;
> + int i = 0;
> + for(; i < sizeof(dcs)-1; ) {
> +-char c = getchar();
> ++int c = getchar();
> + if(c == 0x9c) // ST
> + break;
> + if(in_esc && c == 0x5c)
> diff --git pkg/PLIST pkg/PLIST
> index 58b664f..a4cc9ea 100644
> --- pkg/PLIST
> +++ pkg/PLIST
> @@ -4,7 +4,7 @@
> @bin bin/vterm-dump
> include/vterm.h
> include/vterm_keycodes.h
> -lib/libvterm.a
> +@static-lib lib/libvterm.a
> lib/libvterm.la
> @lib lib/libvterm.so.${LIBvterm_VERSION}
> lib/pkgconfig/vterm.pc
> diff --git Makefile Makefile
> index ddf0f18..1ea5cc4 100644
> --- Makefile
> +++ Makefile
> @@ -1,20 +1,22 @@
> # $OpenBSD: Makefile,v 1.2 2019/07/12 20:46:03 sthen Exp $
>
> COMMENT =very basic terminfo library
> -VERSION =1.2.0
> +VERSION =2.0.0
> DISTNAME = unibilium-${VERSION}
>
> -GH_ACCOUNT = mauke
> +GH_ACCOUNT = neovim
> GH_PROJECT = unibilium
> GH_TAGNAME = v${VERSION}
>
> -SHARED_LIBS += unibilium 0.0 # 3.0
> +SHARED_LIBS += unibilium 1.0 # 4.0
>
> CATEGORIES = devel
>
> # LGPLv3+
> PERMIT_PACKAGE = Yes
>
> +DEBUG_PACKAGES = ${BUILD_PACKAGES}
> +
> MAKE_FLAGS = PREFIX=${PREFIX} \
> MANDIR=${PREFIX}/man
>
> diff --git distinfo distinfo
> index 61047b4..b531af4 100644
> --- distinfo
> +++ distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (unibilium-1.2.0.tar.gz) =
> YjrxCZUV5nOr/TyuXy+oCKCcpV3aHGWntclCTrME6tg=
> -SIZE (unibilium-1.2.0.tar.gz) = 88488
> +SHA256 (unibilium-2.0.0.tar.gz) =
> eJl9ONTIF3xg09DBqoxT/QgG6yGCW3szWxdo1xFrwcE=
> +SIZE (unibilium-2.0.0.tar.gz) = 112570
> diff --git pkg/PLIST pkg/PLIST
Re: Neovim update and new libluv port
Hi everyone,
On Sat, Nov 16, 2019 at 11:23:37AM -0800, Travis Cole wrote:
> I have an updated diff.
I believe the neovim update to be ready.
I'm looking for OKs for the attached diffs. Any takers?
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
diff --git Makefile Makefile
index 0063676..793389b 100644
--- Makefile
+++ Makefile
@@ -1,22 +1,29 @@
-# $OpenBSD:
+# $OpenBSD$
COMMENT = VT220/xterm/ECMA-48 terminal emulator library
# No releases, so use date and a git hash.
# Note that the github repo is a mirror of a bzr repo.
-VERSION = 20170211
+VERSION = 20191009
DISTNAME = libvterm-${VERSION}
GH_ACCOUNT = neovim
GH_PROJECT = libvterm
-GH_COMMIT =224b8dcde1c9640c29a34aa60c0f0d56ad298449
+# Note this git sha is from the nvim branch because
+# Neovim requires patches from this branch to build.
+# see https://github.com/neovim/neovim/wiki/Deps
+GH_COMMIT =7c72294d84ce20da4c27362dbd7fa4b08cfc91da
-SHARED_LIBS += vterm 0.0 # 0.0
+# Note upstream doesn't bump the library version properly.
+# Diff the headers and check for bump-worthy changes.
+SHARED_LIBS += vterm 1.0 # 0.0
CATEGORIES = devel
# MIT
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
WANTLIB += c
USE_GMAKE =Yes
diff --git distinfo distinfo
index 63c4d8e..4c90892 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libvterm-20170211-224b8dcd.tar.gz) =
W8Dol01zXaTVrjOGrEEiylL+gPHFMveyO3nGPsXYzs0=
-SIZE (libvterm-20170211-224b8dcd.tar.gz) = 67291
+SHA256 (libvterm-20191009-7c72294d.tar.gz) =
8wxNQ+DG2z4JEtr3GI2Y+/buiPl1idcvbzBOXbSIJqg=
+SIZE (libvterm-20191009-7c72294d.tar.gz) = 73002
diff --git patches/patch-bin_vterm-ctrl_c patches/patch-bin_vterm-ctrl_c
index 529b571..a3f5e1a 100644
--- patches/patch-bin_vterm-ctrl_c
+++ patches/patch-bin_vterm-ctrl_c
@@ -1,16 +1,42 @@
-$OpenBSD: patch-bin_vterm-ctrl_c,v 1.1.1.1 2017/02/28 22:40:11 edd Exp $
+$OpenBSD$
Fix signed versus unsigned comparison.
https://bugs.launchpad.net/libvterm/+bug/1668780
bin/vterm-ctrl.c.orig Sun Dec 18 21:03:40 2016
-+++ bin/vterm-ctrl.c Sat Feb 25 16:29:14 2017
-@@ -81,7 +81,7 @@ static char *read_csi()
+Patch updated to apply on:
+https://github.com/neovim/libvterm/tree/nvim
+
+diff --git bin/vterm-ctrl.c bin/vterm-ctrl.c
+index ba0d61e..92a365f 100644
+--- bin/vterm-ctrl.c
bin/vterm-ctrl.c
+@@ -79,9 +79,9 @@ static bool seticanon(bool icanon, bool echo)
+ return ret;
+ }
+
+-static void await_c1(unsigned char c1)
++static void await_c1(int c1)
{
- /* TODO: This really should be a more robust CSI parser
-*/
-- char c;
+- unsigned char c;
+ int c;
/* await CSI - 8bit or 2byte 7bit form */
bool in_esc = false;
+@@ -106,7 +106,7 @@ static char *read_csi()
+ char csi[32];
+ int i = 0;
+ for(; i < sizeof(csi)-1; i++) {
+-char c = csi[i] = getchar();
++int c = csi[i] = getchar();
+ if(c >= 0x40 && c <= 0x7e)
+ break;
+ }
+@@ -125,7 +125,7 @@ static char *read_dcs()
+ bool in_esc = false;
+ int i = 0;
+ for(; i < sizeof(dcs)-1; ) {
+-char c = getchar();
++int c = getchar();
+ if(c == 0x9c) // ST
+ break;
+ if(in_esc && c == 0x5c)
diff --git pkg/PLIST pkg/PLIST
index 58b664f..a4cc9ea 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -4,7 +4,7 @@
@bin bin/vterm-dump
include/vterm.h
include/vterm_keycodes.h
-lib/libvterm.a
+@static-lib lib/libvterm.a
lib/libvterm.la
@lib lib/libvterm.so.${LIBvterm_VERSION}
lib/pkgconfig/vterm.pc
diff --git Makefile Makefile
index ddf0f18..1ea5cc4 100644
--- Makefile
+++ Makefile
@@ -1,20 +1,22 @@
# $OpenBSD: Makefile,v 1.2 2019/07/12 20:46:03 sthen Exp $
COMMENT = very basic terminfo library
-VERSION = 1.2.0
+VERSION = 2.0.0
DISTNAME = unibilium-${VERSION}
-GH_ACCOUNT = mauke
+GH_ACCOUNT = neovim
GH_PROJECT = unibilium
GH_TAGNAME = v${VERSION}
-SHARED_LIBS += unibilium 0.0 # 3.0
+SHARED_LIBS += unibilium 1.0 # 4.0
CATEGORIES = devel
# LGPLv3+
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
MAKE_FLAGS = PREFIX=${PREFIX} \
MANDIR=${PREFIX}/man
diff --git distinfo distinfo
index 61047b4..b531af4 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (unibilium-1.2.0.tar.gz) = YjrxCZUV5nOr/TyuXy+oCKCcpV3aHGWntclCTrME6tg=
-SIZE (unibilium-1.2.0.tar.gz) = 88488
+SHA256 (unibilium-2.0.0.tar.gz) = eJl9ONTIF3xg09DBqoxT/QgG6yGCW3szWxdo1xFrwcE=
+SIZE (unibilium-2.0.0.tar.gz) = 112570
diff --git pkg/PLIST pkg/PLIST
index 683d93b..2012515 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -1,6 +1,6 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2017/01/19 19:44:47 edd Exp $
include/unibilium.h
-lib/libunibilium.a
+@static-lib lib/libunibilium.a
lib/libunibilium.la
@lib lib/libunibilium.so.${LIBunibilium_VERSION}
lib/pkgconfig/unibilium.pc
Index: Makefile
===
RCS file:
Re: Neovim update and new libluv port
Hey there,
I have an updated diff.
On Sat, Nov 16, 2019, at 06:54, Edd Barrett wrote:
> Hi Rafael,
>
> On Sat, Nov 16, 2019 at 01:03:05PM +0100, Rafael Sadowski wrote:
> > -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
>
> Yeah, looks like I missed that. If it works, we can add it.
I've added it. It also requires we do ${MAKE_PROGRAM} && ${MAKE_PROGRAM} install
> > -G ${_MODCMAKE_GEN}
>
> It would be nice if this one worked, but to use it properly, we'd also
> have to invoke ${MODCMAKE_BUILD_TARGET} (instead of hard-coding make or
> ninja). Sadly the target does a `cd ${WRKBUILD}` which isn't right for
> us.
>
> So I guess it's better to hard-code make or ninja. My diff used make.
>
> > ${CONFIGURE_ARGS} \
>
> This one breaks the cmake configure, as we end up passing neovim
> configure args to luv's configure.
>
> > exec ${SETENV} ${MAKE_ENV} ${FAKE_SETUP} ${NINJA} ${NINJA_FLAGS} install
>
> Right, so hard-coding ninja. I don't mind which (make or ninja) we use.
>
> Thanks!
This diff merges edd's diff with my latest, along with the top suggestion above.
diff --git a/Makefile b/Makefile
index e9b174a..ea39749 100644
--- a/Makefile
+++ b/Makefile
@@ -4,15 +4,24 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.3
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
MAINTAINER = Edd Barrett
+# Neovim must be statically linked with libluv, which isn't yet ported.
+LUV_VER= 1.30.1-1
+LUV =luv-${LUV_VER}
+MASTER_SITES0 = https://github.com/luvit/luv/releases/download/${LUV_VER}/
+DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
+ ${LUV}${EXTRACT_SUFX}:0
+
# Apache 2.0 + Vim License
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES =${BUILD_PACKAGES}
+
WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
WANTLIB += unibilium util uv vterm
@@ -30,18 +39,20 @@ BUILD_DEPENDS = ${RUN_DEPENDS} \
LIB_DEPENDS = devel/gettext,-runtime \
devel/libtermkey \
devel/libuv \
- devel/libvterm \
+ devel/libvterm>=1.0 \
devel/msgpack \
- devel/unibilium
+ devel/unibilium>=1.0
RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-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} \
+ -DLIBLUV_INCLUDE_DIR=${WRKBUILD}/deps/include \
+ -DLIBLUV_LIBRARY=${WRKBUILD}/deps/lib/libluv.a \
-DPREFER_LUA=ON # disables LuaJIT
# Tests need gmake
@@ -51,6 +62,27 @@ TEST_DEPENDS = shells/bash \
editors/py-neovim \
editors/py-neovim,python3
+# Build libluv first as a static library. We opted not to create a libluv
+# port because it must be built for a specific Lua version and we don't know
+# what version future ports might need. Currently no other port requires
+# libluv, so it's simpler to build a static library here.
+#
+# Most of this target is lifted from ${MODCMAKE_configure} in cmake.port.mk.
+# Unfortunately we can't use it directly, as some of the arguments make
+# assumptions that can't work for us here.
+pre-configure:
+ mkdir -p ${WRKBUILD}/build
+ cd ${WRKBUILD}/build && \
+ ${SETENV} CC="${CC}" CXX="${CXX}" \
+ CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \
+ ${CONFIGURE_ENV} ${LOCALBASE}/bin/cmake \
+ -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
+ -DWITH_LUA_ENGINE=Lua -DLUA_LIBRARIES=${MODLUA_LIB} \
+ -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR} -DBUILD_MODULE=OFF \
+ -DLUA_BUILD_TYPE=System -DCMAKE_COLOR_MAKEFILE=OFF \
+ -DCMAKE_INSTALL_PREFIX=${WRKBUILD}/deps ${WRKDIR}/${LUV} && \
+ env VERBOSE=1 ${MAKE_PROGRAM} && ${MAKE_PROGRAM} install
+
# These are the "old tests". There is also a new suite, but we would need the
# "busted" test suite for Lua, which is not yet ported.
#
diff --git a/distinfo b/distinfo
index 890fd75..1c1e58a 100644
--- a/distinfo
+++ b/distinfo
@@ -1,2 +1,4 @@
-SHA256 (neovim-0.3.8.tar.gz) = lT4TRWjYJNrXy/Mu4xFJUXMvmnUMRi5DDmtZP0GK92w=
-SIZE (neovim-0.3.8.tar.gz) = 9233661
+SHA256 (luv-1.30.1-1.tar.gz) = Tih77W9R/VDOA7p/qMwz2E4bnLhpEcSBK7H0eh4+0So=
+SHA256 (neovim-0.4.3.tar.gz) = kaC10yIEqCG/QUaQ5rSM9pIk0ZYdNxWMKzg/amz4VNI=
+SIZE (luv-1.30.1-1.tar.gz) = 1354232
+SIZE (neovim-0.4.3.tar.gz) = 9556199
diff --git a/patches/patch-src_nvim_os_process_c
b/patches/patch-src_nvim_os_process_c
deleted file mode 100644
index a2e2b6f..000
---
Re: Neovim update and new libluv port
Hi Rafael,
On Sat, Nov 16, 2019 at 01:03:05PM +0100, Rafael Sadowski wrote:
> -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
Yeah, looks like I missed that. If it works, we can add it.
> -G ${_MODCMAKE_GEN}
It would be nice if this one worked, but to use it properly, we'd also
have to invoke ${MODCMAKE_BUILD_TARGET} (instead of hard-coding make or
ninja). Sadly the target does a `cd ${WRKBUILD}` which isn't right for
us.
So I guess it's better to hard-code make or ninja. My diff used make.
> ${CONFIGURE_ARGS} \
This one breaks the cmake configure, as we end up passing neovim
configure args to luv's configure.
> exec ${SETENV} ${MAKE_ENV} ${FAKE_SETUP} ${NINJA} ${NINJA_FLAGS} install
Right, so hard-coding ninja. I don't mind which (make or ninja) we use.
Thanks!
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: Neovim update and new libluv port
On Sat Nov 16, 2019 at 11:40:57AM +, Edd Barrett wrote:
> Hi Travis,
>
> On Fri, Nov 15, 2019 at 09:04:13PM -0800, Travis Cole wrote:
> > Are you sure you sent the right diff? It looks like one of the ones
> > I'd sent previously, but I don't notice any changes.
> >
> > If you could resend, or point out what I missed, I can merge it with
> > my latest diff.
>
> My apologies. That was indeed the wrong diff!
>
> Here it is. Please merge your changes in, and we can ask Stuart what he
> thinks.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/editors/neovim/Makefile,v
> retrieving revision 1.18
> diff -u -p -r1.18 Makefile
> --- Makefile 9 Jul 2019 09:46:16 - 1.18
> +++ Makefile 15 Nov 2019 11:17:57 -
> @@ -4,15 +4,24 @@ COMMENT = continuation and extension of
>
> GH_ACCOUNT = neovim
> GH_PROJECT = neovim
> -GH_TAGNAME = v0.3.8
> +GH_TAGNAME = v0.4.3
>
> CATEGORIES = editors devel
> HOMEPAGE = https://neovim.io
> MAINTAINER = Edd Barrett
>
> +# Neovim must be statically linked with libluv, which isn't yet ported.
> +LUV_VER= 1.30.1-1
> +LUV =luv-${LUV_VER}
> +MASTER_SITES0 = https://github.com/luvit/luv/releases/download/${LUV_VER}/
> +DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
> + ${LUV}${EXTRACT_SUFX}:0
> +
> # Apache 2.0 + Vim License
> PERMIT_PACKAGE = Yes
>
> +DEBUG_PACKAGES =${BUILD_PACKAGES}
> +
> WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
> WANTLIB += unibilium util uv vterm
>
> @@ -30,18 +39,20 @@ BUILD_DEPENDS = ${RUN_DEPENDS} \
> LIB_DEPENDS =devel/gettext,-runtime \
> devel/libtermkey \
> devel/libuv \
> - devel/libvterm \
> + devel/libvterm>=1.0 \
> devel/msgpack \
> - devel/unibilium
> + devel/unibilium>=1.0
>
> RUN_DEPENDS += devel/libmpack/lua \
> devel/libmpack/main \
> devel/desktop-file-utils
>
> -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} \
> + -DLIBLUV_INCLUDE_DIR=${WRKBUILD}/deps/include \
> + -DLIBLUV_LIBRARY=${WRKBUILD}/deps/lib/libluv.a \
> -DPREFER_LUA=ON # disables LuaJIT
>
> # Tests need gmake
> @@ -50,6 +61,27 @@ USE_GMAKE = Yes
> TEST_DEPENDS = shells/bash \
> editors/py-neovim \
> editors/py-neovim,python3
> +
> +# Build libluv first as a static library. We opted not to create a libluv
> +# port because it must be built for a specific Lua version and we don't know
> +# what version future ports might need. Currently no other port requires
> +# libluv, so it's simpler to build a static library here.
> +#
> +# Most of this target is lifted from ${MODCMAKE_configure} in cmake.port.mk.
> +# Unfortunately we can't use it directly, as some of the arguments make
> +# assumptions that can't work for us here.
> +pre-configure:
> + mkdir -p ${WRKBUILD}/build
> + cd ${WRKBUILD}/build && \
> + ${SETENV} CC="${CC}" CXX="${CXX}" \
> + CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \
> + ${CONFIGURE_ENV} ${LOCALBASE}/bin/cmake \
Based on cmake.port.mk, I would like to see the following lines:
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
-G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} \
> + -DWITH_LUA_ENGINE=Lua \
> + -DLUA_LIBRARIES=${MODLUA_LIB} \
> + -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR} -DBUILD_MODULE=OFF \
> + -DLUA_BUILD_TYPE=System -DCMAKE_COLOR_MAKEFILE=OFF \
> + -DCMAKE_INSTALL_PREFIX=${WRKBUILD}/deps ${WRKDIR}/${LUV} && \
Instead of this:
> + env VERBOSE=1 ${MAKE_PROGRAM} install
We can do a similar approach like in cmake.port.mk:
exec ${SETENV} ${MAKE_ENV} ${FAKE_SETUP} ${NINJA} ${NINJA_FLAGS} install
>
> # These are the "old tests". There is also a new suite, but we would need the
> # "busted" test suite for Lua, which is not yet ported.
> Index: distinfo
> ===
> RCS file: /cvs/ports/editors/neovim/distinfo,v
> retrieving revision 1.6
> diff -u -p -r1.6 distinfo
> --- distinfo 9 Jul 2019 09:46:16 - 1.6
> +++ distinfo 15 Nov 2019 10:10:08 -
> @@ -1,2 +1,4 @@
> -SHA256 (neovim-0.3.8.tar.gz) = lT4TRWjYJNrXy/Mu4xFJUXMvmnUMRi5DDmtZP0GK92w=
> -SIZE (neovim-0.3.8.tar.gz) = 9233661
> +SHA256 (luv-1.30.1-1.tar.gz) = Tih77W9R/VDOA7p/qMwz2E4bnLhpEcSBK7H0eh4+0So=
> +SHA256 (neovim-0.4.3.tar.gz) = kaC10yIEqCG/QUaQ5rSM9pIk0ZYdNxWMKzg/amz4VNI=
> +SIZE (luv-1.30.1-1.tar.gz) = 1354232
> +SIZE
Re: Neovim update and new libluv port
Hi Travis,
On Fri, Nov 15, 2019 at 09:04:13PM -0800, Travis Cole wrote:
> Are you sure you sent the right diff? It looks like one of the ones
> I'd sent previously, but I don't notice any changes.
>
> If you could resend, or point out what I missed, I can merge it with
> my latest diff.
My apologies. That was indeed the wrong diff!
Here it is. Please merge your changes in, and we can ask Stuart what he
thinks.
Index: Makefile
===
RCS file: /cvs/ports/editors/neovim/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile9 Jul 2019 09:46:16 - 1.18
+++ Makefile15 Nov 2019 11:17:57 -
@@ -4,15 +4,24 @@ COMMENT = continuation and extension of
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.3
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
MAINTAINER = Edd Barrett
+# Neovim must be statically linked with libluv, which isn't yet ported.
+LUV_VER= 1.30.1-1
+LUV =luv-${LUV_VER}
+MASTER_SITES0 = https://github.com/luvit/luv/releases/download/${LUV_VER}/
+DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
+ ${LUV}${EXTRACT_SUFX}:0
+
# Apache 2.0 + Vim License
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES =${BUILD_PACKAGES}
+
WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
WANTLIB += unibilium util uv vterm
@@ -30,18 +39,20 @@ BUILD_DEPENDS = ${RUN_DEPENDS} \
LIB_DEPENDS = devel/gettext,-runtime \
devel/libtermkey \
devel/libuv \
- devel/libvterm \
+ devel/libvterm>=1.0 \
devel/msgpack \
- devel/unibilium
+ devel/unibilium>=1.0
RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-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} \
+ -DLIBLUV_INCLUDE_DIR=${WRKBUILD}/deps/include \
+ -DLIBLUV_LIBRARY=${WRKBUILD}/deps/lib/libluv.a \
-DPREFER_LUA=ON # disables LuaJIT
# Tests need gmake
@@ -50,6 +61,27 @@ USE_GMAKE = Yes
TEST_DEPENDS = shells/bash \
editors/py-neovim \
editors/py-neovim,python3
+
+# Build libluv first as a static library. We opted not to create a libluv
+# port because it must be built for a specific Lua version and we don't know
+# what version future ports might need. Currently no other port requires
+# libluv, so it's simpler to build a static library here.
+#
+# Most of this target is lifted from ${MODCMAKE_configure} in cmake.port.mk.
+# Unfortunately we can't use it directly, as some of the arguments make
+# assumptions that can't work for us here.
+pre-configure:
+ mkdir -p ${WRKBUILD}/build
+ cd ${WRKBUILD}/build && \
+ ${SETENV} CC="${CC}" CXX="${CXX}" \
+ CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \
+ ${CONFIGURE_ENV} ${LOCALBASE}/bin/cmake \
+ -DWITH_LUA_ENGINE=Lua \
+ -DLUA_LIBRARIES=${MODLUA_LIB} \
+ -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR} -DBUILD_MODULE=OFF \
+ -DLUA_BUILD_TYPE=System -DCMAKE_COLOR_MAKEFILE=OFF \
+ -DCMAKE_INSTALL_PREFIX=${WRKBUILD}/deps ${WRKDIR}/${LUV} && \
+ env VERBOSE=1 ${MAKE_PROGRAM} install
# These are the "old tests". There is also a new suite, but we would need the
# "busted" test suite for Lua, which is not yet ported.
Index: distinfo
===
RCS file: /cvs/ports/editors/neovim/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo9 Jul 2019 09:46:16 - 1.6
+++ distinfo15 Nov 2019 10:10:08 -
@@ -1,2 +1,4 @@
-SHA256 (neovim-0.3.8.tar.gz) = lT4TRWjYJNrXy/Mu4xFJUXMvmnUMRi5DDmtZP0GK92w=
-SIZE (neovim-0.3.8.tar.gz) = 9233661
+SHA256 (luv-1.30.1-1.tar.gz) = Tih77W9R/VDOA7p/qMwz2E4bnLhpEcSBK7H0eh4+0So=
+SHA256 (neovim-0.4.3.tar.gz) = kaC10yIEqCG/QUaQ5rSM9pIk0ZYdNxWMKzg/amz4VNI=
+SIZE (luv-1.30.1-1.tar.gz) = 1354232
+SIZE (neovim-0.4.3.tar.gz) = 9556199
Index: patches/patch-src_nvim_os_process_c
===
RCS file: patches/patch-src_nvim_os_process_c
diff -N patches/patch-src_nvim_os_process_c
--- patches/patch-src_nvim_os_process_c 17 Mar 2019 13:13:40 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,40 +0,0 @@
-$OpenBSD: patch-src_nvim_os_process_c,v 1.1 2019/03/17 13:13:40 edd Exp $
-
-Port job stopping bug fix to neovim:
-
-Original vim fix:
Re: Neovim update and new libluv port
On Fri, Nov 15, 2019, at 03:30, Edd Barrett wrote:
>
> Here is my review of the old diff. You probably want to merge my changes
> with yours.
>
> On Thu, Nov 14, 2019 at 11:54:30AM -0800, Travis Cole wrote:
> > +pre-configure:
> > + @mkdir -p ${WRKBUILD}/build
> > + @(cd ${WRKBUILD}/build && \
> > + cmake -DWITH_LUA_ENGINE=Lua \
> > + -DLUA_LIBRARIES=${MODLUA_LIB} \
> > + -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR} -DBUILD_MODULE=OFF \
> > + -DLUA_BUILD_TYPE=System -DCMAKE_COLOR_MAKEFILE=OFF \
> > + -DCMAKE_INSTALL_PREFIX=${WRKBUILD}/deps ${WRKDIR}/${LUV} && \
> > + ${MAKE_PROGRAM} install)
>
> At the very least, this part of the build needs to honour CC, CXX,
> CFLAGS and CXXFLAGS.
Ok noted.
> At the moment it doesn't. You can verify this by adding something like:
> CFLAGS += -DXXX
>
> to the port Makefile, and adding `env VERBOSE=1` where you run make.
>
> This will print the compiler invocations, and you will see that the
> output doesn't contain our (otherwise conspicuous) -DXXX flag.
>
> If we look in ports/devel/cmake/cmake.port.mk, we see the cmake
> invocation is as follows:
I'd been trying to figure out where that stuff was defined. Now I know. Thanks!
> ---8<---
> MODCMAKE_configure= cd ${WRKBUILD} && ${SETENV} \
> CC="${CC}" CFLAGS="${CFLAGS}" \
> CXX="${CXX}" CXXFLAGS="${CXXFLAGS}" \
> ${CONFIGURE_ENV} ${LOCALBASE}/bin/cmake \
> -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
> -G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} ${WRKSRC}
> --->8---
>
> Ideally, we'd just invoke ${MODCMAKE_configure} having set any extra configure
> flags needed for luv, but we can't do that without also adding flags to the
> main build, so I *think* we probably want to copy as much of the above cmake
> invocation as possible, and put a comment saying that this fragment needs to
> be
> kept close to cmake.port.mk.
I worry a bit that /usr/ports/devel/cmake/cmake.port.mk will drift without us
and we might miss changes except when it's time to update the neovim port again.
But I don't have a better solution.
> Ideally we'd also use `-G ${_MODCMAKE_GEN}` and
> ${MODCMAKE_INSTALL_TARGET} to invoke either make or ninja automatically,
> but it makes assumptions about the build dir, so we can't.
>
> I wouldn't bother prefixing commands in make targets with @ myself.
Ok noted.
> I've posted below an updated diff, but are you sure it isn't easier to invoke
> the neovim deps builder, just having downloaded the luv distfile on its
> behalf?
So if I understand the above correctly, we'd still have to define the extra
stuff from
/usr/ports/devel/cmake/cmake.port.mk because I'm calling cmake directly in that
pre-configure. Is that right?
I'm also running into at least two issues using the neovim deps builder:
1. They download the luv tar from the github archive URL. This download does
not include
the lua-compat53 headers, which are required for the build (and that don't
exist in ports).
So they also download the lua-compat53 tar, also from an archive URL.
The luv tar that I'm downloading comes from the github download URL and
includes a bundled
lua-compat53, so it skips having to deal with that. This could be patched away,
but...
2. When I use the neovim deps builder it always wants to pick up Lua5.3, which
then
means the final build doesn't link. That's the issue you saw previously. I
haven't
figured out why this is happening.
> (edit: remember the diff is based on your older diff)
>
> I fell we are close to having this working.
I feel like it's close too.
Are you sure you sent the right diff? It looks like one of the ones I'd sent
previously, but I don't notice
any changes.
If you could resend, or point out what I missed, I can merge it with my latest
diff.
Thanks!
Re: Neovim update and new libluv port
On Thu, Nov 14, 2019 at 11:54:30AM -0800, Travis Cole wrote:
> Oops, sorry found a couple of things I didn't like in my neovim diff.
Doh! We've raced.
Here is my review of the old diff. You probably want to merge my changes
with yours.
On Thu, Nov 14, 2019 at 11:54:30AM -0800, Travis Cole wrote:
> +pre-configure:
> + @mkdir -p ${WRKBUILD}/build
> + @(cd ${WRKBUILD}/build && \
> + cmake -DWITH_LUA_ENGINE=Lua \
> + -DLUA_LIBRARIES=${MODLUA_LIB} \
> + -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR} -DBUILD_MODULE=OFF \
> + -DLUA_BUILD_TYPE=System -DCMAKE_COLOR_MAKEFILE=OFF \
> + -DCMAKE_INSTALL_PREFIX=${WRKBUILD}/deps ${WRKDIR}/${LUV} && \
> + ${MAKE_PROGRAM} install)
At the very least, this part of the build needs to honour CC, CXX,
CFLAGS and CXXFLAGS.
At the moment it doesn't. You can verify this by adding something like:
CFLAGS += -DXXX
to the port Makefile, and adding `env VERBOSE=1` where you run make.
This will print the compiler invocations, and you will see that the
output doesn't contain our (otherwise conspicuous) -DXXX flag.
If we look in ports/devel/cmake/cmake.port.mk, we see the cmake
invocation is as follows:
---8<---
MODCMAKE_configure= cd ${WRKBUILD} && ${SETENV} \
CC="${CC}" CFLAGS="${CFLAGS}" \
CXX="${CXX}" CXXFLAGS="${CXXFLAGS}" \
${CONFIGURE_ENV} ${LOCALBASE}/bin/cmake \
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON \
-G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} ${WRKSRC}
--->8---
Ideally, we'd just invoke ${MODCMAKE_configure} having set any extra configure
flags needed for luv, but we can't do that without also adding flags to the
main build, so I *think* we probably want to copy as much of the above cmake
invocation as possible, and put a comment saying that this fragment needs to be
kept close to cmake.port.mk.
Ideally we'd also use `-G ${_MODCMAKE_GEN}` and
${MODCMAKE_INSTALL_TARGET} to invoke either make or ninja automatically,
but it makes assumptions about the build dir, so we can't.
I wouldn't bother prefixing commands in make targets with @ myself.
I've posted below an updated diff, but are you sure it isn't easier to invoke
the neovim deps builder, just having downloaded the luv distfile on its behalf?
(edit: remember the diff is based on your older diff)
I fell we are close to having this working.
diff --git Makefile Makefile
index e9b174a..c717c94 100644
--- Makefile
+++ Makefile
@@ -4,7 +4,7 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.2
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
@@ -30,18 +30,29 @@ BUILD_DEPENDS = ${RUN_DEPENDS} \
LIB_DEPENDS = devel/gettext,-runtime \
devel/libtermkey \
devel/libuv \
- devel/libvterm \
+ devel/libvterm>=1.0 \
devel/msgpack \
- devel/unibilium
+ devel/unibilium>=1.0
RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-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
# Tests need gmake
@@ -51,6 +62,15 @@ TEST_DEPENDS = shells/bash \
editors/py-neovim \
editors/py-neovim,python3
+# Build third-party dependencies first for libluv. We opted not to create a
+# libluv port because it must be built for a specific Lua version and we don't
+# know what version future ports might need. Currently no other port requires
+# libluv, so it's simpler to use the bundled library.
+pre-configure:
+ mkdir -p ${WRKBUILD}/.deps
+ cd ${WRKBUILD}/.deps && cmake ${CONFIGURE_ARGS} ${WRKSRC}/third-party
&& \
+ ${MAKE_PROGRAM}
+
# These are the "old tests". There is also a new suite, but we would need the
# "busted" test suite for Lua, which is not yet ported.
#
diff --git distinfo distinfo
index 890fd75..d0dd0a3 100644
---
Re: Neovim update and new libluv port
On Thu, Nov 14, 2019, at 09:09, Travis Cole wrote:
> Hey Edd,
>
> I have some revised diffs that should address your concerns and fix the build
> for you.
>
Oops, sorry found a couple of things I didn't like in my neovim diff.
The attached one is better.
Disables cmake color in the luv build.
Use ${MAKE_PROGRAM} instead of ${MAKE} in the luv build. I *think* that's a bit
more correct.
So please use this diff. Thanks!diff --git Makefile Makefile
index e9b174a..606b44e 100644
--- Makefile
+++ Makefile
@@ -4,15 +4,24 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.3
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
MAINTAINER = Edd Barrett
+# Neovim must be statically linked with libluv, which isn't yet ported.
+LUV_VER= 1.30.1-1
+LUV = luv-${LUV_VER}
+MASTER_SITES0 = https://github.com/luvit/luv/releases/download/${LUV_VER}/
+DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
+ ${LUV}${EXTRACT_SUFX}:0
+
# Apache 2.0 + Vim License
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES =${BUILD_PACKAGES}
+
WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
WANTLIB += unibilium util uv vterm
@@ -30,18 +39,20 @@ BUILD_DEPENDS = ${RUN_DEPENDS} \
LIB_DEPENDS = devel/gettext,-runtime \
devel/libtermkey \
devel/libuv \
- devel/libvterm \
+ devel/libvterm>=1.0 \
devel/msgpack \
- devel/unibilium
+ devel/unibilium>=1.0
RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-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} \
+ -DLIBLUV_INCLUDE_DIR=${WRKBUILD}/deps/include \
+ -DLIBLUV_LIBRARY=${WRKBUILD}/deps/lib/libluv.a \
-DPREFER_LUA=ON # disables LuaJIT
# Tests need gmake
@@ -51,6 +62,20 @@ TEST_DEPENDS = shells/bash \
editors/py-neovim \
editors/py-neovim,python3
+# Build libluv first as a static library. We opted not to create a libluv
+# port because it must be built for a specific Lua version and we don't know
+# what version future ports might need. Currently no other port requires
+# libluv, so it's simpler to build a static library here.
+pre-configure:
+ @mkdir -p ${WRKBUILD}/build
+ @(cd ${WRKBUILD}/build && \
+ cmake -DWITH_LUA_ENGINE=Lua \
+ -DLUA_LIBRARIES=${MODLUA_LIB} \
+ -DLUA_INCLUDE_DIR=${MODLUA_INCL_DIR} -DBUILD_MODULE=OFF \
+ -DLUA_BUILD_TYPE=System -DCMAKE_COLOR_MAKEFILE=OFF \
+ -DCMAKE_INSTALL_PREFIX=${WRKBUILD}/deps ${WRKDIR}/${LUV} && \
+ ${MAKE_PROGRAM} install)
+
# These are the "old tests". There is also a new suite, but we would need the
# "busted" test suite for Lua, which is not yet ported.
#
diff --git distinfo distinfo
index 890fd75..1c1e58a 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,4 @@
-SHA256 (neovim-0.3.8.tar.gz) = lT4TRWjYJNrXy/Mu4xFJUXMvmnUMRi5DDmtZP0GK92w=
-SIZE (neovim-0.3.8.tar.gz) = 9233661
+SHA256 (luv-1.30.1-1.tar.gz) = Tih77W9R/VDOA7p/qMwz2E4bnLhpEcSBK7H0eh4+0So=
+SHA256 (neovim-0.4.3.tar.gz) = kaC10yIEqCG/QUaQ5rSM9pIk0ZYdNxWMKzg/amz4VNI=
+SIZE (luv-1.30.1-1.tar.gz) = 1354232
+SIZE (neovim-0.4.3.tar.gz) = 9556199
diff --git patches/patch-src_nvim_os_process_c patches/patch-src_nvim_os_process_c
deleted file mode 100644
index a2e2b6f..000
--- patches/patch-src_nvim_os_process_c
+++ /dev/null
@@ -1,40 +0,0 @@
-$OpenBSD: patch-src_nvim_os_process_c,v 1.1 2019/03/17 13:13:40 edd Exp $
-
-Port job stopping bug fix to neovim:
-
-Original vim fix:
-https://github.com/vim/vim/commit/76ab4fd61901090e6af3451ca6c5ca0fc370571f#diff-b68adb4fa34020d8d7f0ab40a2704335
-
-Index: src/nvim/os/process.c
src/nvim/os/process.c.orig
-+++ src/nvim/os/process.c
-@@ -89,21 +89,16 @@ bool os_proc_tree_kill(int pid, int sig)
- bool os_proc_tree_kill(int pid, int sig)
- {
- assert(sig == SIGTERM || sig == SIGKILL);
-- int pgid = getpgid(pid);
-- if (pgid > 0) { // Ignore error. Never kill self (pid=0).
--if (pgid == pid) {
-- ILOG("sending %s to process group: -%d",
-- sig == SIGTERM ? "SIGTERM" : "SIGKILL", pgid);
-- int rv = uv_kill(-pgid, sig);
-- return rv == 0;
--} else {
-- // Should never happen, because process_spawn() did setsid() in the child.
-- ELOG("pgid %d != pid %d", pgid, pid);
--}
-+ if (pid != 0) { // Never kill self (pid=0).
-+ILOG("sending %s to PIDs %d and %d",
-+ sig == SIGTERM ? "SIGTERM" : "SIGKILL", -pid, pid);
-+
-+int rv1 = uv_kill(-pid, sig);
-+int rv2 = uv_kill(pid, sig);
-+return (rv1 == 0) && (rv2 == 0);
- } else {
--ELOG("getpgid(%d) returned %d", pid, pgid);
-+return false;
- }
-- return false;
- }
- #endif
-
diff --git pkg/PLIST pkg/PLIST
index 38ff796..65288f9 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -220,7 +220,6 @@ share/nvim/runtime/doc/diff.txt
share/nvim/runtime/doc/digraph.txt
share/nvim/runtime/doc/editing.txt
Re: Neovim update and new libluv port
Hey Edd,
I have some revised diffs that should address your concerns and fix the build
for you.
On Thu, Nov 7, 2019, at 04:13, Edd Barrett wrote:
> Hi Travis,
>
> Thanks for the revised diffs.
>
> unibilium now looks fine.
I've updated this again to include the new debug package functionality. So
attaching the diff again.
> libvterm:
>
> On Mon, Nov 04, 2019 at 08:40:19PM -0800, Travis Cole wrote:
> > > SHARED_LIBS += vterm 1.0 # 0.0
> >
> > I've bumped the version
>
> Cool. I suppose we should probably add a comment warning other porters
> that they don't properly version their shared libs.
>
> Something like:
> ---8<---
> # Note: Upstream doesn't bump the library version properly.
> # Diff the headers and check for bump-worthy cnahges."
> --->8---
Also fixed and I've added the debug package bits here too. So I've attached
that diff.
> Neovim itself fails to link for me:
I believe I've fixed this in my latest diff.
>
> luv is picking up Lua-5.3. I guess you don't see the symbol errors as you only
> have Lua-5.1 installed? You need to patch the build to pick up the
> MODLUA_VERSION one. Hopefully that will fix it.
>
Yeah, I didn't have Lua-5.3 installed. I've since installed it for testing this
build
and verified that it's picking up Lua-5.1.
> I also notice:
> ---8<---
> -- downloading...
> src='https://github.com/keplerproject/lua-compat-5.3/archive/v0.7.tar.gz'
> --->8---
>
> We can't have the build download stuff. I think you can have a play with
> MASTER_SITES1 and a DISTFILE with a :1 suffix to fetch that tarball, then use
> a
> post-fetch target to put it wherever it needs to go. I'm hand-waving a bit,
> but
> you get the gist of it. Grep the tree for examples.
I fixed this with a MASTER_SITES0 and a refactor to the pre-configure.
I realized it would be simpler to not use neovim's third-party deps build
system,
while excluding most of it, just to get libluv. Instead just download and build
libluv as part
of the port build. This solve the issues with the build quietly doing it's own
downloads.
It also cleans up some of the warnings cmake was giving about unused command
line options.
This also happens to be very similar to how Homebrew does it for neovim...
I also went ahead and bumped the Neovim version to 0.4.3.
> I'd fix the symbol problems first.
Fixed. Please see attached, and let me know if there are any style nits or
other major
issues that I failed to account for.
Thanks!diff --git Makefile Makefile
index 0063676..793389b 100644
--- Makefile
+++ Makefile
@@ -1,22 +1,29 @@
-# $OpenBSD:
+# $OpenBSD$
COMMENT = VT220/xterm/ECMA-48 terminal emulator library
# No releases, so use date and a git hash.
# Note that the github repo is a mirror of a bzr repo.
-VERSION = 20170211
+VERSION = 20191009
DISTNAME = libvterm-${VERSION}
GH_ACCOUNT = neovim
GH_PROJECT = libvterm
-GH_COMMIT = 224b8dcde1c9640c29a34aa60c0f0d56ad298449
+# Note this git sha is from the nvim branch because
+# Neovim requires patches from this branch to build.
+# see https://github.com/neovim/neovim/wiki/Deps
+GH_COMMIT = 7c72294d84ce20da4c27362dbd7fa4b08cfc91da
-SHARED_LIBS += vterm 0.0 # 0.0
+# Note upstream doesn't bump the library version properly.
+# Diff the headers and check for bump-worthy changes.
+SHARED_LIBS += vterm 1.0 # 0.0
CATEGORIES = devel
# MIT
PERMIT_PACKAGE = Yes
+DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
WANTLIB += c
USE_GMAKE = Yes
diff --git distinfo distinfo
index 63c4d8e..4c90892 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libvterm-20170211-224b8dcd.tar.gz) = W8Dol01zXaTVrjOGrEEiylL+gPHFMveyO3nGPsXYzs0=
-SIZE (libvterm-20170211-224b8dcd.tar.gz) = 67291
+SHA256 (libvterm-20191009-7c72294d.tar.gz) = 8wxNQ+DG2z4JEtr3GI2Y+/buiPl1idcvbzBOXbSIJqg=
+SIZE (libvterm-20191009-7c72294d.tar.gz) = 73002
diff --git patches/patch-bin_vterm-ctrl_c patches/patch-bin_vterm-ctrl_c
index 529b571..a3f5e1a 100644
--- patches/patch-bin_vterm-ctrl_c
+++ patches/patch-bin_vterm-ctrl_c
@@ -1,16 +1,42 @@
-$OpenBSD: patch-bin_vterm-ctrl_c,v 1.1.1.1 2017/02/28 22:40:11 edd Exp $
+$OpenBSD$
Fix signed versus unsigned comparison.
https://bugs.launchpad.net/libvterm/+bug/1668780
bin/vterm-ctrl.c.orig Sun Dec 18 21:03:40 2016
-+++ bin/vterm-ctrl.c Sat Feb 25 16:29:14 2017
-@@ -81,7 +81,7 @@ static char *read_csi()
+Patch updated to apply on:
+https://github.com/neovim/libvterm/tree/nvim
+
+diff --git bin/vterm-ctrl.c bin/vterm-ctrl.c
+index ba0d61e..92a365f 100644
+--- bin/vterm-ctrl.c
bin/vterm-ctrl.c
+@@ -79,9 +79,9 @@ static bool seticanon(bool icanon, bool echo)
+ return ret;
+ }
+
+-static void await_c1(unsigned char c1)
++static void await_c1(int c1)
{
- /* TODO: This really should be a more robust CSI parser
-*/
-- char c;
+- unsigned char c;
+ int c;
/* await CSI - 8bit or 2byte 7bit form */
bool in_esc = false;
+@@ -106,7 +106,7 @@ static char *read_csi()
+ char csi[32];
+
Re: Neovim update and new libluv port
Hey Edd,
Thanks for another review!
On Thu, Nov 7, 2019, at 04:13, Edd Barrett wrote:
> Hi Travis,
>
> Thanks for the revised diffs.
>
> unibilium now looks fine.
Great! that's progress. :)
> libvterm:
>
> On Mon, Nov 04, 2019 at 08:40:19PM -0800, Travis Cole wrote:
> > > SHARED_LIBS += vterm 1.0 # 0.0
> >
> > I've bumped the version
>
> Cool. I suppose we should probably add a comment warning other porters
> that they don't properly version their shared libs.
>
> Something like:
> ---8<---
> # Note: Upstream doesn't bump the library version properly.
> # Diff the headers and check for bump-worthy cnahges."
> --->8---
I've included a new diff with the comment.
> third-party/CMakelists seems to use Lua-5.1.
>
> Confused? I was too. But here's what I think the problem is. When building
> luv:
> ---8<---
> ...
> -- Found LIBUV: /usr/local/lib/libuv.so.2.1
> -- Found Lua: /usr/local/lib/liblua5.3.so.5.3;/usr/lib/libm.so.10.1 (found
> version "5.3.5")
> --->8---
>
> luv is picking up Lua-5.3. I guess you don't see the symbol errors as you only
> have Lua-5.1 installed? You need to patch the build to pick up the
> MODLUA_VERSION one. Hopefully that will fix it.
Thanks for all the detective work. I'll give this a try.
And yep, you're right, I only have Lua-5.1 installed.
> I also notice:
> ---8<---
> -- downloading...
> src='https://github.com/keplerproject/lua-compat-5.3/archive/v0.7.tar.gz'
> --->8---
>
> We can't have the build download stuff. I think you can have a play with
> MASTER_SITES1 and a DISTFILE with a :1 suffix to fetch that tarball, then use
> a
> post-fetch target to put it wherever it needs to go. I'm hand-waving a bit,
> but
> you get the gist of it. Grep the tree for examples.
Thanks, I'll fix this too.
> I'd fix the symbol problems first.
>
>
> Isn't porting FUN!
It is indeed!
Thanks a lot for your patience and guidance on this.
I likely won't have much time to dig into this again until mid-next week.
But here is the updated libvterm diff.
diff --git Makefile Makefile
index 0063676..3e8d729 100644
--- Makefile
+++ Makefile
@@ -1,16 +1,21 @@
-# $OpenBSD:
+# $OpenBSD$
COMMENT = VT220/xterm/ECMA-48 terminal emulator library
# No releases, so use date and a git hash.
# Note that the github repo is a mirror of a bzr repo.
-VERSION = 20170211
+VERSION = 20191009
DISTNAME = libvterm-${VERSION}
GH_ACCOUNT = neovim
GH_PROJECT = libvterm
-GH_COMMIT =224b8dcde1c9640c29a34aa60c0f0d56ad298449
-
-SHARED_LIBS += vterm 0.0 # 0.0
+# Note this git sha is from the nvim branch because
+# Neovim requires patches from this branch to build.
+# see https://github.com/neovim/neovim/wiki/Deps
+GH_COMMIT =7c72294d84ce20da4c27362dbd7fa4b08cfc91da
+
+# Note upstream doesn't bump the library version properly.
+# Diff the headers and check for bump-worthy changes.
+SHARED_LIBS += vterm 1.0 # 0.0
CATEGORIES = devel
diff --git distinfo distinfo
index 63c4d8e..4c90892 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libvterm-20170211-224b8dcd.tar.gz) =
W8Dol01zXaTVrjOGrEEiylL+gPHFMveyO3nGPsXYzs0=
-SIZE (libvterm-20170211-224b8dcd.tar.gz) = 67291
+SHA256 (libvterm-20191009-7c72294d.tar.gz) =
8wxNQ+DG2z4JEtr3GI2Y+/buiPl1idcvbzBOXbSIJqg=
+SIZE (libvterm-20191009-7c72294d.tar.gz) = 73002
diff --git patches/patch-bin_vterm-ctrl_c patches/patch-bin_vterm-ctrl_c
index 529b571..a3f5e1a 100644
--- patches/patch-bin_vterm-ctrl_c
+++ patches/patch-bin_vterm-ctrl_c
@@ -1,16 +1,42 @@
-$OpenBSD: patch-bin_vterm-ctrl_c,v 1.1.1.1 2017/02/28 22:40:11 edd Exp $
+$OpenBSD$
Fix signed versus unsigned comparison.
https://bugs.launchpad.net/libvterm/+bug/1668780
bin/vterm-ctrl.c.orig Sun Dec 18 21:03:40 2016
-+++ bin/vterm-ctrl.c Sat Feb 25 16:29:14 2017
-@@ -81,7 +81,7 @@ static char *read_csi()
+Patch updated to apply on:
+https://github.com/neovim/libvterm/tree/nvim
+
+diff --git bin/vterm-ctrl.c bin/vterm-ctrl.c
+index ba0d61e..92a365f 100644
+--- bin/vterm-ctrl.c
bin/vterm-ctrl.c
+@@ -79,9 +79,9 @@ static bool seticanon(bool icanon, bool echo)
+ return ret;
+ }
+
+-static void await_c1(unsigned char c1)
++static void await_c1(int c1)
{
- /* TODO: This really should be a more robust CSI parser
-*/
-- char c;
+- unsigned char c;
+ int c;
/* await CSI - 8bit or 2byte 7bit form */
bool in_esc = false;
+@@ -106,7 +106,7 @@ static char *read_csi()
+ char csi[32];
+ int i = 0;
+ for(; i < sizeof(csi)-1; i++) {
+-char c = csi[i] = getchar();
++int c = csi[i] = getchar();
+ if(c >= 0x40 && c <= 0x7e)
+ break;
+ }
+@@ -125,7 +125,7 @@ static char *read_dcs()
+ bool in_esc = false;
+ int i = 0;
+ for(; i < sizeof(dcs)-1; ) {
+-char c = getchar();
++int c = getchar();
+ if(c == 0x9c) // ST
+ break;
+ if(in_esc && c == 0x5c)
Re: Neovim update and new libluv port
Hi Travis,
Thanks for the revised diffs.
unibilium now looks fine.
libvterm:
On Mon, Nov 04, 2019 at 08:40:19PM -0800, Travis Cole wrote:
> > SHARED_LIBS += vterm 1.0 # 0.0
>
> I've bumped the version
Cool. I suppose we should probably add a comment warning other porters
that they don't properly version their shared libs.
Something like:
---8<---
# Note: Upstream doesn't bump the library version properly.
# Diff the headers and check for bump-worthy cnahges."
--->8---
> I did also notice some minor compiler
> warnings in libvterm. I'm not sure if we want to address them?
The warnings looks harmless, so I wouldn't waste your time on fixing
them.
Neovim itself fails to link for me:
---8<---
/usr/local/pobj/neovim-0.4.2/bin/cc -O2 -pipe ... -o bin/nvim ...
ld: error: undefined symbol: lua_tointegerx
>>> referenced by luv.c
>>> luv.c.o:(luv_stack_dump) in archive .deps/usr/lib/libluv.a
ld: error: undefined symbol: lua_rotate
>>> referenced by luv.c
>>> luv.c.o:(luv_cfpcall) in archive .deps/usr/lib/libluv.a
ld: error: undefined symbol: lua_pcallk
>>> referenced by luv.c
>>> luv.c.o:(luv_cfpcall) in archive .deps/usr/lib/libluv.a
ld: error: undefined symbol: lua_rotate
>>> referenced by luv.c
>>> luv.c.o:(luv_cfpcall) in archive .deps/usr/lib/libluv.a
...
--->8---
I reckon our default Lua version (currently 5.1) is too old. `lua_rotate` is
one of the symbols needed for linkage:
---8<---
$ nm liblua5.1.so.5.1 | grep lua_rotate
$ nm liblua5.2.so.5.2 | grep lua_rotate
$ nm liblua5.3.so.5.3 | grep lua_rotate
00011580 T lua_rotate
--->8---
This shows that some part of the build expects a symbol non-existent in
versions of lua older than 5.3, So we could add:
---8<---
MODLUA_VERSION =5.3
--->8---
And then change the FLAVORS of all of the Lua RUN/BUILD dependencies, e.g.:
---8<---
devel/libmpack/lua,${MODLUA_FLAVOR}
--->8---
(We should do that *anyway*, even if we stick with the default Lua
version)
Except we can't use Lua-5.3 for lua-bitop! It only supports Lua5.1 and
Lua5.2!
Further, the fact that they build lua53-compat suggests that neovim requires an
earlier version than 5.3 itself.
third-party/CMakelists seems to use Lua-5.1.
Confused? I was too. But here's what I think the problem is. When building luv:
---8<---
...
-- Found LIBUV: /usr/local/lib/libuv.so.2.1
-- Found Lua: /usr/local/lib/liblua5.3.so.5.3;/usr/lib/libm.so.10.1 (found
version "5.3.5")
--->8---
luv is picking up Lua-5.3. I guess you don't see the symbol errors as you only
have Lua-5.1 installed? You need to patch the build to pick up the
MODLUA_VERSION one. Hopefully that will fix it.
I also notice:
---8<---
-- downloading...
src='https://github.com/keplerproject/lua-compat-5.3/archive/v0.7.tar.gz'
--->8---
We can't have the build download stuff. I think you can have a play with
MASTER_SITES1 and a DISTFILE with a :1 suffix to fetch that tarball, then use a
post-fetch target to put it wherever it needs to go. I'm hand-waving a bit, but
you get the gist of it. Grep the tree for examples.
I'd fix the symbol problems first.
Isn't porting FUN!
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: Neovim update and new libluv port
Thanks for the thorough review. On Mon, Nov 4, 2019, at 15:01, Edd Barrett wrote: > Hi, > > CCing Stuart, as there are a couple of things I'm not certain about. > > So now looking at the unibilium, vterm and neovim updates (now assuming > we will use a bundled luv)... > > First unibilium: > > On Sun, Sep 29, 2019 at 01:16:13PM -0700, Travis Cole wrote: > > -SHARED_LIBS += unibilium 0.0 # 3.0 > > +SHARED_LIBS += unibilium 1.0 # 3.0 I wasn't sure what the library comment convention meant there. > Something is potentially fishy here. We've done a major bump to the > OpenBSD version, but he upstream version remains the same. If upstream > is to be trusted, then they are on version 4.0 (see shared_libs.log in > $WRKBUILD after a build). > > (4.0 comes from LT_* in their Makefile) > > There's a method here you can do to see if upstream bumped properly: > https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs > > I've just done this, and the output is identical, but as the docs say, > this won't diff the types of arguments. So I diffed the header and the > first hunk is: > > ---8<--- > -short unibi_get_num(const unibi_term *, enum unibi_numeric); > -void unibi_set_num(unibi_term *, enum unibi_numeric, short); > +int unibi_get_num(const unibi_term *, enum unibi_numeric); > +void unibi_set_num(unibi_term *, enum unibi_numeric, int); > --->8--- > > A return value changed: short -> int, so a major bump is correct I > think. So we want: > > SHARED_LIBS += unibilium 1.0 # 4.0 Cool thanks for explaining this. I've noted this for any future port work I may do. I don't remember the details now, and should have kept notes, but I'm pretty sure I did the major bump because I'd seen or read that they made an API change. > libvterm: > > > -GH_COMMIT = 224b8dcde1c9640c29a34aa60c0f0d56ad298449 > > +# commit sha from the nvim branch > > +GH_COMMIT = 4a5fa43e0dbc0db4fe67d40d788d60852864df9e > > How comes? Is this going to interfere with any other port that might > depend on this in the future? I couldn't get neovim to build with master. I just tried again with the latest master and the compile failed. Going by this: https://github.com/neovim/neovim/wiki/Deps#forks It's mostly just small bug fixes that haven't been accepted upstream. The changes are fairly minor: https://github.com/neovim/libvterm/compare/master...kelp:nvim I don't think this creates issues for someone that depends on it, but to be honest I'm not sure. > At the very least I think we need a comment in the port explaining this. > > > -SHARED_LIBS += vterm 0.0 # 0.0 > > +SHARED_LIBS += vterm 0.1 # 0.0 > > I'd give that a major bump too. Diffing the headers shows lots of scary > type changes. The upstream version is still 0.0 though! I guess they > don't take versioning very seriously. > > SHARED_LIBS += vterm 1.0 # 0.0 I've bumped the version and included a more detailed comment to explain what's going on with the nvim branch. I did also notice some minor compiler warnings in libvterm. I'm not sure if we want to address them? I also took the liberty of bumping the git sha to the latest version in the nvim branch. It has some fixes that looked important, including a memory leak fix. > > > +Patch updated to apply on: > > +https://github.com/neovim/libvterm/tree/nvim > > I *think* this 'char -> int' patch is right, but I'd like someone else > to have a look too. > > > And finally, the updated neovim patch you sent: > > ---8<--- > $ patch -CEsp0 < /tmp/neovim.diff > 2 out of 4 hunks failed > --->8--- > > Hrm. Do you need to regenerate the diff? I'll review what you sent > anyway, but I can't test it. Oops, I must have diffed against the wrong git sha... Fixed, and I tested the patch this time on a clean copy from ports. > > -WANTLIB += unibilium util uv vterm > > +WANTLIB += unibilium>=1.0 util uv vterm>=0.1 > > I'm not sure if that's right. I'd probably put my version constraints on > the LIB_DEPENDS instead. I may be wrong. Stuart? I greped through the ports tree and both styles seem to exist, but the LIB_DEPENDS one is more popular so I switched to that. Though https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs does show putting version in WANTLIB. > > +# Build third-party dependencies first. This is necessary because we > > require > > +# the bundled libluv. > > +pre-configure: > > Let's expand this comment to explain why we are going to use a bundled > luv. You'd just need to summarise the discussion we've had on this > thread in a couple more sentences. Ok I've done that. Let me know if that is clear enough. A few other things to call out. I've noticed nvim crashes on exit sometimes. I can reproduce it 100% by opening any file, and then trying to open it again in another nvim instance. Then hitting q. But I can also reproduce this on Arch Linux with the same nvim version. I didn't see any obvious bug reports to upstream, but I'll take a harder look. The cmake build shows a few errors about
Re: Neovim update and new libluv port
Hi, CCing Stuart, as there are a couple of things I'm not certain about. So now looking at the unibilium, vterm and neovim updates (now assuming we will use a bundled luv)... First unibilium: On Sun, Sep 29, 2019 at 01:16:13PM -0700, Travis Cole wrote: > -SHARED_LIBS += unibilium 0.0 # 3.0 > +SHARED_LIBS += unibilium 1.0 # 3.0 Something is potentially fishy here. We've done a major bump to the OpenBSD version, but he upstream version remains the same. If upstream is to be trusted, then they are on version 4.0 (see shared_libs.log in $WRKBUILD after a build). (4.0 comes from LT_* in their Makefile) There's a method here you can do to see if upstream bumped properly: https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs I've just done this, and the output is identical, but as the docs say, this won't diff the types of arguments. So I diffed the header and the first hunk is: ---8<--- -short unibi_get_num(const unibi_term *, enum unibi_numeric); -void unibi_set_num(unibi_term *, enum unibi_numeric, short); +int unibi_get_num(const unibi_term *, enum unibi_numeric); +void unibi_set_num(unibi_term *, enum unibi_numeric, int); --->8--- A return value changed: short -> int, so a major bump is correct I think. So we want: SHARED_LIBS += unibilium 1.0 # 4.0 libvterm: > -GH_COMMIT = 224b8dcde1c9640c29a34aa60c0f0d56ad298449 > +# commit sha from the nvim branch > +GH_COMMIT = 4a5fa43e0dbc0db4fe67d40d788d60852864df9e How comes? Is this going to interfere with any other port that might depend on this in the future? At the very least I think we need a comment in the port explaining this. > -SHARED_LIBS += vterm 0.0 # 0.0 > +SHARED_LIBS += vterm 0.1 # 0.0 I'd give that a major bump too. Diffing the headers shows lots of scary type changes. The upstream version is still 0.0 though! I guess they don't take versioning very seriously. SHARED_LIBS += vterm 1.0 # 0.0 > +Patch updated to apply on: > +https://github.com/neovim/libvterm/tree/nvim I *think* this 'char -> int' patch is right, but I'd like someone else to have a look too. And finally, the updated neovim patch you sent: ---8<--- $ patch -CEsp0 < /tmp/neovim.diff 2 out of 4 hunks failed --->8--- Hrm. Do you need to regenerate the diff? I'll review what you sent anyway, but I can't test it. > -WANTLIB += unibilium util uv vterm > +WANTLIB += unibilium>=1.0 util uv vterm>=0.1 I'm not sure if that's right. I'd probably put my version constraints on the LIB_DEPENDS instead. I may be wrong. Stuart? > +# Build third-party dependencies first. This is necessary because we require > +# the bundled libluv. > +pre-configure: Let's expand this comment to explain why we are going to use a bundled luv. You'd just need to summarise the discussion we've had on this thread in a couple more sentences. That's all for now. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: Neovim update and new libluv port
On 2019/11/04 10:45, Edd Barrett wrote: > Hi Stuart, > > On Mon, Nov 04, 2019 at 10:34:52AM +, Stuart Henderson wrote: > > 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. > > So do I read it correctly that we should continue using the bundled luv > until another port needs it too? Or do we bite the bullet and just do > the luv port form the outset? > > Thanks > > -- > Best Regards > Edd Barrett > > http://www.theunixzoo.co.uk > Yes I think bundled. When there's another actual user we'll have some idea which lua version it needs, etc.
Re: Neovim update and new libluv port
Hi Stuart, On Mon, Nov 04, 2019 at 10:34:52AM +, Stuart Henderson wrote: > 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. So do I read it correctly that we should continue using the bundled luv until another port needs it too? Or do we bite the bullet and just do the luv port form the outset? Thanks -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: Neovim update and new libluv port
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.
Re: Neovim update and new libluv port
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.
> -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.
> 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...
Thanks!
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: Neovim update and new libluv port
On Sun, Nov 3, 2019, at 01:05, Stuart Henderson wrote:
> 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?
>
Thanks,
I understand what you were saying now. I went to look at what others were
doing to solve this. It looks like FreeBSD and Arch don't do it in a way that
addresses your concerns.
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 found this:
https://github.com/neovim/neovim/wiki/Building-Neovim#third-party-dependencies
And then went and looked harder at just using the bundled luv dep, and I got it
to work.
How does this look? It will also require the updated unibilium and libvterm
that I'd
previously provided.
diff --git Makefile Makefile
index e9b174a..368a5df 100644
--- Makefile
+++ Makefile
@@ -4,7 +4,7 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.2
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
@@ -14,7 +14,7 @@ MAINTAINER = Edd Barrett
PERMIT_PACKAGE = Yes
WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
-WANTLIB += unibilium util uv vterm
+WANTLIB += unibilium>=1.0 util uv vterm>=0.1
COMPILER = base-clang ports-gcc base-gcc
@@ -38,10 +38,21 @@ RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-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
# Tests need gmake
@@ -51,6 +62,13 @@ TEST_DEPENDS = shells/bash \
editors/py-neovim \
editors/py-neovim,python3
+# Build third-party dependencies first. This is necessary because we require
+# the bundled libluv.
+pre-configure:
+ mkdir -p ${WRKBUILD}/.deps
+ cd ${WRKBUILD}/.deps && cmake ${CONFIGURE_ARGS} ${WRKSRC}/third-party
&& \
+ ${MAKE_PROGRAM}
+
# These are the "old tests". There is also a new suite, but we would need the
# "busted" test suite for Lua, which is not yet ported.
#
Re: Neovim update and new libluv port
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? >
Re: Neovim update and new libluv port
On Wed, Oct 30, 2019, at 10:23, Travis Cole wrote: > > > On Wed, Oct 30, 2019, at 09:38, Edd Barrett wrote: > > Hi Travis, > > > > On Wed, Oct 23, 2019 at 11:02:28AM +0100, Stuart Henderson wrote: > > > So you should be able to do > > > > > > -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 > > > > Any joy with Stuart's suggestion? ^ > > Hey Ed, > > I've had limited time to try, but I did dig in a bit. I don't think it's so > simple as above > and I haven't got a successful build yet. Just setting the above makes it not > try > to use any bundled deps at all. > > So I've tried to build the deps in pre-configure, which works, but still > haven't got a > successful build. > I've looked into this some more and convinced myself that the Neovim build system currently doesn't support using partial bundled deps and would need several changes to make that work. Why not use the libluv port with Stuart's improvements? Thanks.
Re: Neovim update and new libluv port
On Wed, Oct 30, 2019, at 09:38, Edd Barrett wrote:
> Hi Travis,
>
> On Wed, Oct 23, 2019 at 11:02:28AM +0100, Stuart Henderson wrote:
> > So you should be able to do
> >
> > -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
>
> Any joy with Stuart's suggestion? ^
Hey Ed,
I've had limited time to try, but I did dig in a bit. I don't think it's so
simple as above
and I haven't got a successful build yet. Just setting the above makes it not
try
to use any bundled deps at all.
So I've tried to build the deps in pre-configure, which works, but still
haven't got a
successful build.
Here is the hacky WIP diff that does get a partial, but failing build.
diff --git Makefile Makefile
index e9b174a..173bbfe 100644
--- Makefile
+++ Makefile
@@ -4,7 +4,7 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.2
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
@@ -14,7 +14,7 @@ MAINTAINER = Edd Barrett
PERMIT_PACKAGE = Yes
WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
-WANTLIB += unibilium util uv vterm
+WANTLIB += unibilium>=1.0 util uv vterm>=0.1
COMPILER = base-clang ports-gcc base-gcc
@@ -38,12 +38,28 @@ RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-MAKE_FLAGS += USE_BUNDLED_DEPS=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 \
-DPREFER_LUA=ON # disables LuaJIT
+pre-configure:
+ mkdir -p ${WRKBUILD}/deps
+ @cd ${WRKBUILD}/deps && \
+ cmake -G 'Ninja' ${CONFIGURE_ARGS} ${WRKSRC}/third-party && \
+ ninja
+
# Tests need gmake
USE_GMAKE = Yes
# `test_startup_utf8.vim' requires either bash or zsh
The failure is here:
FAILED: bin/nvim
: && /home/pobj/neovim-0.4.2/bin/cc -O2 -pipe -Wall -DNDEBUG
-DMIN_LOG_LEVEL=3 -flto=thin -Wl,--no-undefined
src/nvim/CMakeFiles/nvim.dir/auto/msgpack_lua_c_bindings.generated.c.o
src/nvim/CMakeFiles/nvim.dir/__/__/config/auto/pathdef.c.o
src/nvim/CMakeFiles/nvim.dir/api/buffer.c.o
src/nvim/CMakeFiles/nvim.dir/api/private/dispatch.c.o
src/nvim/CMakeFiles/nvim.dir/api/private/handle.c.o
src/nvim/CMakeFiles/nvim.dir/api/private/helpers.c.o
src/nvim/CMakeFiles/nvim.dir/api/tabpage.c.o
src/nvim/CMakeFiles/nvim.dir/api/ui.c.o
src/nvim/CMakeFiles/nvim.dir/api/vim.c.o
src/nvim/CMakeFiles/nvim.dir/api/window.c.o
src/nvim/CMakeFiles/nvim.dir/arabic.c.o src/nvim/CMakeFiles/nvim.dir/aucmd.c.o
src/nvim/CMakeFiles/nvim.dir/buffer.c.o
src/nvim/CMakeFiles/nvim.dir/buffer_updates.c.o
src/nvim/CMakeFiles/nvim.dir/change.c.o
src/nvim/CMakeFiles/nvim.dir/channel.c.o
src/nvim/CMakeFiles/nvim.dir/charset.c.o
src/nvim/CMakeFiles/nvim.dir/context.c.o
src/nvim/CMakeFiles/nvim.dir/cursor.c.o
src/nvim/CMakeFiles/nvim.dir/cursor_shape.c.o
src/nvim/CMakeFiles/nvim.dir/diff.c.o src/nvim/CMakeFiles/nvim.dir/digraph.c.o
src/nvim/CMakeFiles/nvim.dir/edit.c.o src/nvim/CMakeFiles/nvim.dir/eval.c.o
src/nvim/CMakeFiles/nvim.dir/eval/decode.c.o
src/nvim/CMakeFiles/nvim.dir/eval/encode.c.o
src/nvim/CMakeFiles/nvim.dir/eval/executor.c.o
src/nvim/CMakeFiles/nvim.dir/eval/gc.c.o
src/nvim/CMakeFiles/nvim.dir/eval/typval.c.o
src/nvim/CMakeFiles/nvim.dir/event/libuv_process.c.o
src/nvim/CMakeFiles/nvim.dir/event/loop.c.o
src/nvim/CMakeFiles/nvim.dir/event/multiqueue.c.o
src/nvim/CMakeFiles/nvim.dir/event/process.c.o
src/nvim/CMakeFiles/nvim.dir/event/rstream.c.o
src/nvim/CMakeFiles/nvim.dir/event/signal.c.o
src/nvim/CMakeFiles/nvim.dir/event/socket.c.o
src/nvim/CMakeFiles/nvim.dir/event/stream.c.o
src/nvim/CMakeFiles/nvim.dir/event/time.c.o
src/nvim/CMakeFiles/nvim.dir/event/wstream.c.o
src/nvim/CMakeFiles/nvim.dir/ex_cmds.c.o
src/nvim/CMakeFiles/nvim.dir/ex_cmds2.c.o
src/nvim/CMakeFiles/nvim.dir/ex_docmd.c.o
src/nvim/CMakeFiles/nvim.dir/ex_eval.c.o
src/nvim/CMakeFiles/nvim.dir/ex_getln.c.o
Re: Neovim update and new libluv port
Hi Travis, On Wed, Oct 23, 2019 at 11:02:28AM +0100, Stuart Henderson wrote: > So you should be able to do > > -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 Any joy with Stuart's suggestion? ^ -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: Neovim update and new libluv port
On 2019/10/22 21:45, Travis Cole wrote:
> On Mon, Oct 21, 2019, at 06:10, Edd Barrett wrote:
> > Hi Stuart,
> >
> > Thanks for looking at this is more detail.
> >
> > On Mon, Oct 21, 2019 at 01:12:57PM +0100, Stuart Henderson wrote:
> > > 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?
> >
> > I don't object as long as we have a comment in the neovim port
> > describing this decision.
> >
>
> Thanks for looking at this again!
>
> I went to see if I could just add -DUSE_BUNDLED_LOV=ON to
> MAKE_FLAGS and sadly, it doesn't seem so simple. The configure step fails
> because it can't find luv.
>
> -- Found Msgpack: /usr/local/lib/libmsgpackc.so.1.0 (found suitable version
> "2.1.5", minimum required is "1.0.0")
> CMake Error at
> /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137
> (message):
> Could NOT find LibLUV (missing: LIBLUV_LIBRARY LIBLUV_INCLUDE_DIR)
> (Required is at least version "1.30.0")
> Call Stack (most recent call first):
> /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378
> (_FPHSA_FAILURE_MESSAGE)
> cmake/FindLibLUV.cmake:29 (find_package_handle_standard_args)
> CMakeLists.txt:375 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
>
>
> I'm a bit new to cmake, but from my reading of this, the USE_BUNDLED
> is all or nothing.
>
> from: neovim-0.4.2/third-party/CMakeLists.txt
>
> option(USE_BUNDLED "Use bundled dependencies." ON)
>
> option(USE_BUNDLED_GPERF "Use the bundled version of gperf." ${USE_BUNDLED})
> option(USE_BUNDLED_UNIBILIUM "Use the bundled unibilium." ${USE_BUNDLED})
> option(USE_BUNDLED_LIBTERMKEY "Use the bundled libtermkey." ${USE_BUNDLED})
> option(USE_BUNDLED_LIBVTERM "Use the bundled libvterm." ${USE_BUNDLED})
> option(USE_BUNDLED_LIBUV "Use the bundled libuv." ${USE_BUNDLED})
> option(USE_BUNDLED_MSGPACK "Use the bundled msgpack." ${USE_BUNDLED})
> option(USE_BUNDLED_LUAJIT "Use the bundled version of luajit." ${USE_BUNDLED})
> option(USE_BUNDLED_LUAROCKS "Use the bundled version of luarocks."
> ${USE_BUNDLED})
> option(USE_BUNDLED_LUV "Use the bundled version of luv." ${USE_BUNDLED})
>
> And hard coding USE_BUNDLED_LUV to ON didn't do it either.
>
> Similar with their included Makefile:
>
> deps: | build/.ran-third-party-cmake
> ifeq ($(call filter-true,$(USE_BUNDLED)),)
> +$(BUILD_CMD) -C $(DEPS_BUILD_DIR)
> endif
>
> Setting USE_BUNDLED=ON doesn't even work... I think neovim is actually using
> gmake
> AND cmake for much of the 3rd party deps. So some of that may have to be
> replicated.
>
> So I think it will require some more surgery to make this work.
>
> I'll see what headway I can make in evenings this week, unless someone else
> has
> a smarter solution.
So you should be able to do
-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
Re: Neovim update and new libluv port
On Mon, Oct 21, 2019, at 06:10, Edd Barrett wrote:
> Hi Stuart,
>
> Thanks for looking at this is more detail.
>
> On Mon, Oct 21, 2019 at 01:12:57PM +0100, Stuart Henderson wrote:
> > 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?
>
> I don't object as long as we have a comment in the neovim port
> describing this decision.
>
Thanks for looking at this again!
I went to see if I could just add -DUSE_BUNDLED_LOV=ON to
MAKE_FLAGS and sadly, it doesn't seem so simple. The configure step fails
because it can't find luv.
-- Found Msgpack: /usr/local/lib/libmsgpackc.so.1.0 (found suitable version
"2.1.5", minimum required is "1.0.0")
CMake Error at
/usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137
(message):
Could NOT find LibLUV (missing: LIBLUV_LIBRARY LIBLUV_INCLUDE_DIR)
(Required is at least version "1.30.0")
Call Stack (most recent call first):
/usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378
(_FPHSA_FAILURE_MESSAGE)
cmake/FindLibLUV.cmake:29 (find_package_handle_standard_args)
CMakeLists.txt:375 (find_package)
-- Configuring incomplete, errors occurred!
I'm a bit new to cmake, but from my reading of this, the USE_BUNDLED
is all or nothing.
from: neovim-0.4.2/third-party/CMakeLists.txt
option(USE_BUNDLED "Use bundled dependencies." ON)
option(USE_BUNDLED_GPERF "Use the bundled version of gperf." ${USE_BUNDLED})
option(USE_BUNDLED_UNIBILIUM "Use the bundled unibilium." ${USE_BUNDLED})
option(USE_BUNDLED_LIBTERMKEY "Use the bundled libtermkey." ${USE_BUNDLED})
option(USE_BUNDLED_LIBVTERM "Use the bundled libvterm." ${USE_BUNDLED})
option(USE_BUNDLED_LIBUV "Use the bundled libuv." ${USE_BUNDLED})
option(USE_BUNDLED_MSGPACK "Use the bundled msgpack." ${USE_BUNDLED})
option(USE_BUNDLED_LUAJIT "Use the bundled version of luajit." ${USE_BUNDLED})
option(USE_BUNDLED_LUAROCKS "Use the bundled version of luarocks."
${USE_BUNDLED})
option(USE_BUNDLED_LUV "Use the bundled version of luv." ${USE_BUNDLED})
And hard coding USE_BUNDLED_LUV to ON didn't do it either.
Similar with their included Makefile:
deps: | build/.ran-third-party-cmake
ifeq ($(call filter-true,$(USE_BUNDLED)),)
+$(BUILD_CMD) -C $(DEPS_BUILD_DIR)
endif
Setting USE_BUNDLED=ON doesn't even work... I think neovim is actually using
gmake
AND cmake for much of the 3rd party deps. So some of that may have to be
replicated.
So I think it will require some more surgery to make this work.
I'll see what headway I can make in evenings this week, unless someone else has
a smarter solution.
Re: Neovim update and new libluv port
Hi Stuart, Thanks for looking at this is more detail. On Mon, Oct 21, 2019 at 01:12:57PM +0100, Stuart Henderson wrote: > 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? I don't object as long as we have a comment in the neovim port describing this decision. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: Neovim update and new libluv port
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. 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? libluv.tgz Description: application/tar-gz
Re: Neovim update and new libluv port
On Wed, Oct 2, 2019, at 19:43, Travis Cole wrote:
>
> Attached is a tar of the luv port with Stuart's diff applied.
And I've cleaned up my previous diffs to work with the renamed luv, and fixed a
few minor issues.
Here are the updated diffs and I've attached the luv.tar.gz to this email also.
libvterm:
diff --git Makefile Makefile
index 0063676..f0fc441 100644
--- Makefile
+++ Makefile
@@ -1,16 +1,17 @@
-# $OpenBSD:
+# $OpenBSD$
COMMENT = VT220/xterm/ECMA-48 terminal emulator library
# No releases, so use date and a git hash.
# Note that the github repo is a mirror of a bzr repo.
-VERSION = 20170211
+VERSION = 20190910
DISTNAME = libvterm-${VERSION}
GH_ACCOUNT = neovim
GH_PROJECT = libvterm
-GH_COMMIT = 224b8dcde1c9640c29a34aa60c0f0d56ad298449
+# commit sha from the nvim branch
+GH_COMMIT = 4a5fa43e0dbc0db4fe67d40d788d60852864df9e
-SHARED_LIBS += vterm 0.0 # 0.0
+SHARED_LIBS += vterm 0.1 # 0.0
CATEGORIES = devel
diff --git distinfo distinfo
index 63c4d8e..9d06423 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libvterm-20170211-224b8dcd.tar.gz) =
W8Dol01zXaTVrjOGrEEiylL+gPHFMveyO3nGPsXYzs0=
-SIZE (libvterm-20170211-224b8dcd.tar.gz) = 67291
+SHA256 (libvterm-20190910-4a5fa43e.tar.gz) =
SbPPLcuYi4h2cbEBHP6smP+Bu1wj+0rDS5GllSSZKTU=
+SIZE (libvterm-20190910-4a5fa43e.tar.gz) = 72448
diff --git patches/patch-bin_vterm-ctrl_c patches/patch-bin_vterm-ctrl_c
index 529b571..a3f5e1a 100644
--- patches/patch-bin_vterm-ctrl_c
+++ patches/patch-bin_vterm-ctrl_c
@@ -1,16 +1,42 @@
-$OpenBSD: patch-bin_vterm-ctrl_c,v 1.1.1.1 2017/02/28 22:40:11 edd Exp $
+$OpenBSD$
Fix signed versus unsigned comparison.
https://bugs.launchpad.net/libvterm/+bug/1668780
bin/vterm-ctrl.c.orig Sun Dec 18 21:03:40 2016
-+++ bin/vterm-ctrl.c Sat Feb 25 16:29:14 2017
-@@ -81,7 +81,7 @@ static char *read_csi()
+Patch updated to apply on:
+https://github.com/neovim/libvterm/tree/nvim
+
+diff --git bin/vterm-ctrl.c bin/vterm-ctrl.c
+index ba0d61e..92a365f 100644
+--- bin/vterm-ctrl.c
bin/vterm-ctrl.c
+@@ -79,9 +79,9 @@ static bool seticanon(bool icanon, bool echo)
+ return ret;
+ }
+
+-static void await_c1(unsigned char c1)
++static void await_c1(int c1)
{
- /* TODO: This really should be a more robust CSI parser
- */
-- char c;
+- unsigned char c;
+ int c;
/* await CSI - 8bit or 2byte 7bit form */
bool in_esc = false;
+@@ -106,7 +106,7 @@ static char *read_csi()
+ char csi[32];
+ int i = 0;
+ for(; i < sizeof(csi)-1; i++) {
+- char c = csi[i] = getchar();
++ int c = csi[i] = getchar();
+ if(c >= 0x40 && c <= 0x7e)
+ break;
+ }
+@@ -125,7 +125,7 @@ static char *read_dcs()
+ bool in_esc = false;
+ int i = 0;
+ for(; i < sizeof(dcs)-1; ) {
+- char c = getchar();
++ int c = getchar();
+ if(c == 0x9c) // ST
+ break;
+ if(in_esc && c == 0x5c)
unibilium:
Unsure what to do about the comment after the SHARED_LIBS line.
diff --git Makefile Makefile
index ddf0f18..1b0109f 100644
--- Makefile
+++ Makefile
@@ -1,14 +1,14 @@
# $OpenBSD: Makefile,v 1.2 2019/07/12 20:46:03 sthen Exp $
COMMENT = very basic terminfo library
-VERSION = 1.2.0
+VERSION = 2.0.0
DISTNAME = unibilium-${VERSION}
-GH_ACCOUNT = mauke
+GH_ACCOUNT = neovim
GH_PROJECT = unibilium
GH_TAGNAME = v${VERSION}
-SHARED_LIBS += unibilium 0.0 # 3.0
+SHARED_LIBS += unibilium 1.0 # 3.0
CATEGORIES = devel
diff --git distinfo distinfo
index 61047b4..b531af4 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (unibilium-1.2.0.tar.gz) = YjrxCZUV5nOr/TyuXy+oCKCcpV3aHGWntclCTrME6tg=
-SIZE (unibilium-1.2.0.tar.gz) = 88488
+SHA256 (unibilium-2.0.0.tar.gz) = eJl9ONTIF3xg09DBqoxT/QgG6yGCW3szWxdo1xFrwcE=
+SIZE (unibilium-2.0.0.tar.gz) = 112570
And neovim:
diff --git Makefile Makefile
index e9b174a..b6ff812 100644
--- Makefile
+++ Makefile
@@ -4,7 +4,7 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
-GH_TAGNAME = v0.3.8
+GH_TAGNAME = v0.4.2
CATEGORIES = editors devel
HOMEPAGE = https://neovim.io
@@ -13,8 +13,8 @@ MAINTAINER = Edd Barrett
# Apache 2.0 + Vim License
PERMIT_PACKAGE = Yes
-WANTLIB += c iconv intl ${MODLUA_WANTLIB} m msgpackc pthread termkey
-WANTLIB += unibilium util uv vterm
+WANTLIB += c iconv intl luv ${MODLUA_WANTLIB} m msgpackc pthread termkey
+WANTLIB += unibilium>=1.0 util uv vterm>=0.1
COMPILER = base-clang ports-gcc base-gcc
@@ -31,6 +31,7 @@ LIB_DEPENDS = devel/gettext,-runtime \
devel/libtermkey \
devel/libuv \
devel/libvterm \
+ devel/luv \
devel/msgpack \
devel/unibilium
@@ -38,7 +39,7 @@ RUN_DEPENDS += devel/libmpack/lua \
devel/libmpack/main \
devel/desktop-file-utils
-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} \
diff --git distinfo distinfo
index 890fd75..d0dd0a3 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (neovim-0.3.8.tar.gz) = lT4TRWjYJNrXy/Mu4xFJUXMvmnUMRi5DDmtZP0GK92w=
-SIZE (neovim-0.3.8.tar.gz) = 9233661
+SHA256
Re: Neovim update and new libluv port
On Wed, Oct 2, 2019, at 09:28, Travis Cole wrote: > On Wed, Oct 2, 2019, at 01:11, Stuart Henderson wrote: > > On 2019/10/01 22:01, Travis Cole wrote: > > > > > lua-compat-5.3 doesn't install any headers, and no other PLIST file in > > > ports has it either. > > > > > > I'm not sure if it's best to keep the deps dir? or are we talking about > > > modifying lua-compat53 to install > > > those headers? > > > > Yes that would need lua-compat53 to install the header (and it should also > > install the C file I think), but it will need to avoid adding a conflict > > between the packages for the two supported Lua versions (lua-compat53 and > > lua52-compat53). > > > > > Or is there a simpler option that I'm missing? > > > > The simpler option is to use the bundled one. > > > > I've CC'd lua-compat53 maintainer - fcambus, do you think it's worth > > complicating the lua-compat53 port to add this? > > > > Here's a diff on top of yours. I haven't touched the lua-compat53 parts > > yet but otherwise: > > > > - zap stray on PKGNAME line > > - put WANTLIB in the right place > > - don't BUILD_DEPENDS on cmake or set SEPARATE_BUILD, the cmake module > > already does this > > - standard case for NO_TEST is Yes not YES > > > > Thanks for this diff, I can send an updated tar after work today. In 8 or so > hours. > > Now I remember why I didn't have SEPARATE_BUILD in there in the first place... > But didn't realize I could also leave out cmake. > Attached is a tar of the luv port with Stuart's diff applied. luv.tar.gz Description: application/gzip
Re: Neovim update and new libluv port
On Wed, Oct 2, 2019, at 01:11, Stuart Henderson wrote:
> On 2019/10/01 22:01, Travis Cole wrote:
>
> > lua-compat-5.3 doesn't install any headers, and no other PLIST file in
> > ports has it either.
> >
> > I'm not sure if it's best to keep the deps dir? or are we talking about
> > modifying lua-compat53 to install
> > those headers?
>
> Yes that would need lua-compat53 to install the header (and it should also
> install the C file I think), but it will need to avoid adding a conflict
> between the packages for the two supported Lua versions (lua-compat53 and
> lua52-compat53).
>
> > Or is there a simpler option that I'm missing?
>
> The simpler option is to use the bundled one.
>
> I've CC'd lua-compat53 maintainer - fcambus, do you think it's worth
> complicating the lua-compat53 port to add this?
>
> Here's a diff on top of yours. I haven't touched the lua-compat53 parts
> yet but otherwise:
>
> - zap stray on PKGNAME line
> - put WANTLIB in the right place
> - don't BUILD_DEPENDS on cmake or set SEPARATE_BUILD, the cmake module
> already does this
> - standard case for NO_TEST is Yes not YES
>
Thanks for this diff, I can send an updated tar after work today. In 8 or so
hours.
Now I remember why I didn't have SEPARATE_BUILD in there in the first place...
But didn't realize I could also leave out cmake.
> diff -uNp -r luv-/Makefile luv/Makefile
> --- luv-/Makefile Wed Oct 2 04:39:41 2019
> +++ luv/Makefile Wed Oct 2 09:00:36 2019
> @@ -4,7 +4,7 @@ COMMENT = libuv bindings for LuaJIT and Lua
>
> VER = 1.30.1-1
> DISTNAME = luv-${VER}
> -PKGNAME = luv-${VER:S/-/./g}
> +PKGNAME = luv-${VER:S/-/./g}
>
> SHARED_LIBS += luv 0.0
>
> @@ -15,16 +15,15 @@ HOMEPAGE = https://github.com/luvit/luv
> # Apache 2.0
> PERMIT_PACKAGE = Yes
>
> +WANTLIB += uv
> +
> MASTER_SITES = ${HOMEPAGE}/releases/download/${VER}/
>
> MODULES += devel/cmake \
> lang/lua
>
> -WANTLIB += uv
> +BUILD_DEPENDS = devel/lua-compat53
>
> -BUILD_DEPENDS = devel/cmake \
> - devel/lua-compat53
> -
> LIB_DEPENDS = devel/libuv
>
> CONFIGURE_ARGS = -DWITH_SHARED_LIBUV=ON \
> @@ -33,7 +32,6 @@ CONFIGURE_ARGS = -DWITH_SHARED_LIBUV=ON \
> -DBUILD_MODULE=OFF \
> -DBUILD_SHARED_LIBS=ON \
>
> -NO_TEST = YES
> -SEPARATE_BUILD = YES
> +NO_TEST = Yes
>
> .include
>
>
Re: Neovim update and new libluv port
On 2019/10/01 22:01, Travis Cole wrote:
> > I notice that the source tarball bundles some dependencies in `deps/` and
> > uses them once during the build:
> > ---8<---
> > ===> Building for libluv-1.30.1.1
> > [1/3] /usr/local/pobj/libluv-1.30.1.1/bin/cc -DLUA_USE_DLOPEN -Dluv_EXPORTS
> > -I/usr/local/include -I/usr/local/include/lua-5.1
> > -I/usr/local/pobj/libluv-1.30.1.1/luv-1.30.1-1/deps/lua-compat-5.3 -O2
> > -pipe -g -DNDEBUG -fPIC -MD -MT CMakeFile
> > s/luv.dir/src/luv.c.o -MF CMakeFiles/luv.dir/src/luv.c.o.d -o
> > CMakeFiles/luv.dir/src/luv.c.o -c /usr/local/pobj/liblu
> > v-1.30.1.1/luv-1.30.1-1/src/luv.c
> > --->8---
> >
> > So it's using `deps/lua-compat-5.3`. I notice we have a port
> > devel/lua-compat53
> > already. It'd be best if you can make your port use it. Perhaps we should
> > `rm
> > -rf` the `deps/` directory in `pre-build:` so as to avoid accidental usage
> > of
> > bundled deps?
>
> This one I'm not totally sure what to do about. I tried your advice and it it
> breaks the build with:
>
> /usr/obj/ports/luv-1.30.1.1/luv-1.30.1-1/src/luv.c:20:10: fatal error:
> 'c-api/compat-5.3.h' file not found
> #include "c-api/compat-5.3.h"
> ^~~~
>
> lua-compat-5.3 doesn't install any headers, and no other PLIST file in ports
> has it either.
>
> I'm not sure if it's best to keep the deps dir? or are we talking about
> modifying lua-compat53 to install
> those headers?
Yes that would need lua-compat53 to install the header (and it should also
install the C file I think), but it will need to avoid adding a conflict
between the packages for the two supported Lua versions (lua-compat53 and
lua52-compat53).
> Or is there a simpler option that I'm missing?
The simpler option is to use the bundled one.
I've CC'd lua-compat53 maintainer - fcambus, do you think it's worth
complicating the lua-compat53 port to add this?
Here's a diff on top of yours. I haven't touched the lua-compat53 parts
yet but otherwise:
- zap stray on PKGNAME line
- put WANTLIB in the right place
- don't BUILD_DEPENDS on cmake or set SEPARATE_BUILD, the cmake module
already does this
- standard case for NO_TEST is Yes not YES
diff -uNp -r luv-/Makefile luv/Makefile
--- luv-/Makefile Wed Oct 2 04:39:41 2019
+++ luv/MakefileWed Oct 2 09:00:36 2019
@@ -4,7 +4,7 @@ COMMENT = libuv bindings for LuaJIT and Lua
VER = 1.30.1-1
DISTNAME = luv-${VER}
-PKGNAME = luv-${VER:S/-/./g}
+PKGNAME = luv-${VER:S/-/./g}
SHARED_LIBS += luv 0.0
@@ -15,16 +15,15 @@ HOMEPAGE = https://github.com/luvit/luv
# Apache 2.0
PERMIT_PACKAGE = Yes
+WANTLIB += uv
+
MASTER_SITES = ${HOMEPAGE}/releases/download/${VER}/
MODULES += devel/cmake \
lang/lua
-WANTLIB += uv
+BUILD_DEPENDS =devel/lua-compat53
-BUILD_DEPENDS =devel/cmake \
- devel/lua-compat53
-
LIB_DEPENDS = devel/libuv
CONFIGURE_ARGS = -DWITH_SHARED_LIBUV=ON \
@@ -33,7 +32,6 @@ CONFIGURE_ARGS = -DWITH_SHARED_LIBUV=ON \
-DBUILD_MODULE=OFF \
-DBUILD_SHARED_LIBS=ON \
-NO_TEST = YES
-SEPARATE_BUILD = YES
+NO_TEST = Yes
.include
Re: Neovim update and new libluv port
Hey there,
Thanks for the feedback.
On Tue, Oct 1, 2019, at 02:20, Edd Barrett wrote:
> Hi,
>
> Thanks for looking at this.
>
> On Sun, Sep 29, 2019 at 01:16:13PM -0700, Travis Cole wrote:
> > * A new port of libluv:
> > - Neovim now depends on libluv
> > - (See https://github.com/neovim/neovim/wiki/Following-HEAD) so I had to
> > create a new port which I've attached.
>
> Let's start with this ^
>
> Should the package name be "libluv" or "luv"? Upstream seems to call it "luv".
You're probably right. I've changed it to just "luv".
>
>
> > PKGVER = 1.30.1.1
>
> Since that's only used once, you might aswell inline it. Or even better,
> to the replacement using make's regex support:
>
> PKGNAME = libluv-${VER:S/-/./g}
Good idea. Fixed.
> > BUILD_DEPENDS = devel/cmake \
> > devel/libuv
> >
> > LIB_DEPENDS = devel/libuv
>
> If libuv is a LIB_DEPEND, I don't think you need it as a BUILD_DEPEND as
> well.
Makes sense. DRY. Fixed.
> > CONFIGURE_ARGS = -DWITH_SHARED_LIBUV=ON \
> > -DWITH_LUA_ENGINE=Lua \
> > -DLUA_BUILD_TYPE=System \
> > -DBUILD_MODULE=OFF \
> > -DBUILD_SHARED_LIBS=ON \
>
> Indent is odd here. I'd make all the `-D`s line up.
Yeah, sorry fixed.
> In Makefile and pkg/DESCR we need to use the right capitalisation for Lua and
> LuaJIT:
> - s/luajit/LuaJIT/g
> - s/lua/Lua/g
Those were a copy paste from the upstream README.md on github, but I agree
about making
it have the proper capitalization. Fixed.
> `make port-lib-depends-check` says:
> ---8<---
> Extra: pthread.26
> --->8---
>
> So you probably want to kill that from your WANTLIB.
A little surprised I didn't catch that. But fixed.
> I notice that the source tarball bundles some dependencies in `deps/` and
> uses them once during the build:
> ---8<---
> ===> Building for libluv-1.30.1.1
> [1/3] /usr/local/pobj/libluv-1.30.1.1/bin/cc -DLUA_USE_DLOPEN -Dluv_EXPORTS
> -I/usr/local/include -I/usr/local/include/lua-5.1
> -I/usr/local/pobj/libluv-1.30.1.1/luv-1.30.1-1/deps/lua-compat-5.3 -O2 -pipe
> -g -DNDEBUG -fPIC -MD -MT CMakeFile
> s/luv.dir/src/luv.c.o -MF CMakeFiles/luv.dir/src/luv.c.o.d -o
> CMakeFiles/luv.dir/src/luv.c.o -c /usr/local/pobj/liblu
> v-1.30.1.1/luv-1.30.1-1/src/luv.c
> --->8---
>
> So it's using `deps/lua-compat-5.3`. I notice we have a port
> devel/lua-compat53
> already. It'd be best if you can make your port use it. Perhaps we should `rm
> -rf` the `deps/` directory in `pre-build:` so as to avoid accidental usage of
> bundled deps?
This one I'm not totally sure what to do about. I tried your advice and it it
breaks the build with:
/usr/obj/ports/luv-1.30.1.1/luv-1.30.1-1/src/luv.c:20:10: fatal error:
'c-api/compat-5.3.h' file not found
#include "c-api/compat-5.3.h"
^~~~
lua-compat-5.3 doesn't install any headers, and no other PLIST file in ports
has it either.
I'm not sure if it's best to keep the deps dir? or are we talking about
modifying lua-compat53 to install
those headers?
Or is there a simpler option that I'm missing?
> And finally:
> ---8<---
> fremen$ /usr/ports/infrastructure/bin/portcheck
> trailing whitespace in Makefile
> --->8---
Ah, I should have caught this one to. Fixed.
>
> Other than these, this looks good. If you mail me a revised diff, I'll start
> looking for an OK.
I also added:
SEPARATE_BUILD =YES
New tar attached.
Thanks!
luv.tar.gz
Description: application/gzip
Re: Neovim update and new libluv port
Hi,
Thanks for looking at this.
On Sun, Sep 29, 2019 at 01:16:13PM -0700, Travis Cole wrote:
> * A new port of libluv:
> - Neovim now depends on libluv
> - (See https://github.com/neovim/neovim/wiki/Following-HEAD) so I had
> to
> create a new port which I've attached.
Let's start with this ^
Should the package name be "libluv" or "luv"? Upstream seems to call it "luv".
> PKGVER =1.30.1.1
Since that's only used once, you might aswell inline it. Or even better,
to the replacement using make's regex support:
PKGNAME = libluv-${VER:S/-/./g}
> BUILD_DEPENDS = devel/cmake \
> devel/libuv
>
> LIB_DEPENDS = devel/libuv
If libuv is a LIB_DEPEND, I don't think you need it as a BUILD_DEPEND as well.
> CONFIGURE_ARGS =-DWITH_SHARED_LIBUV=ON \
>-DWITH_LUA_ENGINE=Lua \
>-DLUA_BUILD_TYPE=System \
>-DBUILD_MODULE=OFF \
>-DBUILD_SHARED_LIBS=ON \
Indent is odd here. I'd make all the `-D`s line up.
In Makefile and pkg/DESCR we need to use the right capitalisation for Lua and
LuaJIT:
- s/luajit/LuaJIT/g
- s/lua/Lua/g
`make port-lib-depends-check` says:
---8<---
Extra: pthread.26
--->8---
So you probably want to kill that from your WANTLIB.
I notice that the source tarball bundles some dependencies in `deps/` and uses
them once during the build:
---8<---
===> Building for libluv-1.30.1.1
[1/3] /usr/local/pobj/libluv-1.30.1.1/bin/cc -DLUA_USE_DLOPEN -Dluv_EXPORTS
-I/usr/local/include -I/usr/local/include/lua-5.1
-I/usr/local/pobj/libluv-1.30.1.1/luv-1.30.1-1/deps/lua-compat-5.3 -O2 -pipe -g
-DNDEBUG -fPIC -MD -MT CMakeFile
s/luv.dir/src/luv.c.o -MF CMakeFiles/luv.dir/src/luv.c.o.d -o
CMakeFiles/luv.dir/src/luv.c.o -c /usr/local/pobj/liblu
v-1.30.1.1/luv-1.30.1-1/src/luv.c
--->8---
So it's using `deps/lua-compat-5.3`. I notice we have a port devel/lua-compat53
already. It'd be best if you can make your port use it. Perhaps we should `rm
-rf` the `deps/` directory in `pre-build:` so as to avoid accidental usage of
bundled deps?
And finally:
---8<---
fremen$ /usr/ports/infrastructure/bin/portcheck
trailing whitespace in Makefile
--->8---
Other than these, this looks good. If you mail me a revised diff, I'll start
looking for an OK.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Neovim update and new libluv port
Hi there,
I wanted Neovim 0.4.2 so I took the liberty of figuring out what it would take
to update the port.
I've included:
* A new port of libluv:
- Neovim now depends on libluv
- (See https://github.com/neovim/neovim/wiki/Following-HEAD) so I had
to
create a new port which I've attached.
* A patch to update unibilium to 2.0.0
- Unibilium has been forked and moved under the neovim github org so
I'm pointing at that.
* A patch to update libvterm to the latest git sha on the nvim branch.
- It seems that no other ports depend on libvterm, so it made sense to
use
the nvim branch.
- I updated the patch to bin/vterm-ctrl.c. Upstream hasn't integrated
the
previous patch and the code has drifted quite a lot.
* A patch to update neovim to v0.4.2
- Removed patch-src_nvim_os_process_c - I believe it was fixed upstream
here:
https://github.com/neovim/neovim/commit/6e01ed6a4c859ff915b42422622f1ba3cc80efd5
- make test completes with no failures
I've tested this on amd64 -CURRENT from yesterday and ran through the porting
and update checklists.
Happy to hear any feedback.
thanks!
Patches ahead.
unibilium.diff:
diff --git Makefile Makefile
index ddf0f1846db..1b0109fdb67 100644
--- Makefile
+++ Makefile
@@ -1,14 +1,14 @@
# $OpenBSD: Makefile,v 1.2 2019/07/12 20:46:03 sthen Exp $
COMMENT = very basic terminfo library
-VERSION = 1.2.0
+VERSION = 2.0.0
DISTNAME = unibilium-${VERSION}
-GH_ACCOUNT = mauke
+GH_ACCOUNT = neovim
GH_PROJECT = unibilium
GH_TAGNAME = v${VERSION}
-SHARED_LIBS += unibilium 0.0 # 3.0
+SHARED_LIBS += unibilium 1.0 # 3.0
CATEGORIES = devel
diff --git distinfo distinfo
index 61047b4ed65..b531af481ad 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (unibilium-1.2.0.tar.gz) = YjrxCZUV5nOr/TyuXy+oCKCcpV3aHGWntclCTrME6tg=
-SIZE (unibilium-1.2.0.tar.gz) = 88488
+SHA256 (unibilium-2.0.0.tar.gz) = eJl9ONTIF3xg09DBqoxT/QgG6yGCW3szWxdo1xFrwcE=
+SIZE (unibilium-2.0.0.tar.gz) = 112570
libvterm.diff
diff --git Makefile Makefile
index 006367688e9..e79baa11807 100644
--- Makefile
+++ Makefile
@@ -1,16 +1,17 @@
-# $OpenBSD:
+# $OpenBSD: $
COMMENT = VT220/xterm/ECMA-48 terminal emulator library
# No releases, so use date and a git hash.
# Note that the github repo is a mirror of a bzr repo.
-VERSION = 20170211
+VERSION = 20190910
DISTNAME = libvterm-${VERSION}
GH_ACCOUNT = neovim
GH_PROJECT = libvterm
-GH_COMMIT =224b8dcde1c9640c29a34aa60c0f0d56ad298449
+# commit sha from the nvim branch
+GH_COMMIT =4a5fa43e0dbc0db4fe67d40d788d60852864df9e
-SHARED_LIBS += vterm 0.0 # 0.0
+SHARED_LIBS += vterm 0.1 # 0.0
CATEGORIES = devel
diff --git distinfo distinfo
index 63c4d8e0322..9d064239eef 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libvterm-20170211-224b8dcd.tar.gz) =
W8Dol01zXaTVrjOGrEEiylL+gPHFMveyO3nGPsXYzs0=
-SIZE (libvterm-20170211-224b8dcd.tar.gz) = 67291
+SHA256 (libvterm-20190910-4a5fa43e.tar.gz) =
SbPPLcuYi4h2cbEBHP6smP+Bu1wj+0rDS5GllSSZKTU=
+SIZE (libvterm-20190910-4a5fa43e.tar.gz) = 72448
diff --git patches/patch-bin_vterm-ctrl_c patches/patch-bin_vterm-ctrl_c
index 529b571b9ff..aa951f474a8 100644
--- patches/patch-bin_vterm-ctrl_c
+++ patches/patch-bin_vterm-ctrl_c
@@ -1,16 +1,42 @@
-$OpenBSD: patch-bin_vterm-ctrl_c,v 1.1.1.1 2017/02/28 22:40:11 edd Exp $
+$OpenBSD: $
Fix signed versus unsigned comparison.
https://bugs.launchpad.net/libvterm/+bug/1668780
bin/vterm-ctrl.c.orig Sun Dec 18 21:03:40 2016
-+++ bin/vterm-ctrl.c Sat Feb 25 16:29:14 2017
-@@ -81,7 +81,7 @@ static char *read_csi()
+Patch updated to apply on:
+https://github.com/neovim/libvterm/tree/nvim
+
+diff --git bin/vterm-ctrl.c bin/vterm-ctrl.c
+index ba0d61e..92a365f 100644
+--- bin/vterm-ctrl.c
bin/vterm-ctrl.c
+@@ -79,9 +79,9 @@ static bool seticanon(bool icanon, bool echo)
+ return ret;
+ }
+
+-static void await_c1(unsigned char c1)
++static void await_c1(int c1)
{
- /* TODO: This really should be a more robust CSI parser
-*/
-- char c;
+- unsigned char c;
+ int c;
/* await CSI - 8bit or 2byte 7bit form */
bool in_esc = false;
+@@ -106,7 +106,7 @@ static char *read_csi()
+ char csi[32];
+ int i = 0;
+ for(; i < sizeof(csi)-1; i++) {
+-char c = csi[i] = getchar();
++int c = csi[i] = getchar();
+ if(c >= 0x40 && c <= 0x7e)
+ break;
+ }
+@@ -125,7 +125,7 @@ static char *read_dcs()
+ bool in_esc = false;
+ int i = 0;
+ for(; i < sizeof(dcs)-1; ) {
+-char c = getchar();
++int c = getchar();
+ if(c == 0x9c) // ST
+ break;
+ if(in_esc && c == 0x5c)
neovim.diff:
diff --git Makefile Makefile
index e9b174a4512..3680334ad7c 100644
--- Makefile
+++ Makefile
@@ -4,7 +4,7 @@ COMMENT = continuation and extension of Vim
GH_ACCOUNT = neovim
GH_PROJECT = neovim
