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

Reply via email to