Re: New: textproc/tree-sitter

On Fri, Apr 30, 2021 at 09:37:53AM +0200, Paco Esteban wrote:
> On Thu, 29 Apr 2021, Tracey Emery wrote:
>
> > On Thu, Apr 29, 2021 at 03:45:47PM +0200, Paco Esteban wrote:
> > > On Wed, 28 Apr 2021, Tracey Emery wrote:
> > >
> > > > On Wed, Apr 28, 2021 at 01:34:25PM -0600, Tracey Emery wrote:
> > > > > On Wed, Apr 28, 2021 at 08:41:15PM +0200, Paco Esteban wrote:
> > > > > > On Wed, 28 Apr 2021, Tracey Emery wrote:
> > > > > >
> > > > > > > On Tue, Apr 27, 2021 at 06:59:40PM +0200, Paco Esteban wrote:
> > > > > > > > Hi ports@
> > > > > > > >
> > > > > > > > This is a new port of tree-sitter (https://tree-sitter.github.io/tree-sitter/).
> > > > > > > > From their site:
> > > > > > > >
> > > > > > > > Tree-sitter is a parser generator tool and an incremental parsing
> > > > > > > > library. It can build a concrete syntax tree for a source file and
> > > > > > > > efficiently update the syntax tree as the source file is edited.
> > > > > > > >
> > > > > > > > This port will be needed when neovim 0.5 goes out (I'm testing nightly
> > > > > > > > builds at the moment).
> > > > > > > >
> > > > > > > > It's a bit odd because it has a C library and a Rust binary.
> > > > > > > > Some tests fail, but it builds and neovim nightly takes it and builds
> > > > > > > > and runs too (I have a problem with port-lib-depends-check, but that's
> > > > > > > > a topic for another thread).
> > > > > > > >
> > > > > > > > Any suggestions on my "franken-port" are very welcome.
> > > > > > > >
> > > > > > > > ok to import ?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Paco Esteban.
> > > > > > > > 0x5818130B8A6DBC03
> > > > > > >
> > > > > > > I must have missed a ulimit bump somewhere along the lines? Hmmm.
> > > > > > >
> > > > > > > ===> Compiler link: clang -> /usr/bin/clang
> > > > > > > ===> Compiler link: clang++ -> /usr/bin/clang++
> > > > > > > ===> Compiler link: cc -> /usr/bin/cc
> > > > > > > ===> Compiler link: c++ -> /usr/bin/c++
> > > > > > > ===> Generating configure for rust-1.50.0
> > > > > > > ===> Configuring for rust-1.50.0
> > > > > > > Using /usr/ports/pobj/rust-1.50.0/config.site (generated)
> > > > > > > datasize limit is too low - amd64 build takes approx 4GB
> > > > > >
> > > > > > Added WANTLIB as per tracey's suggestion.
> > > > > > Port attached for convenience.
> > > > > >
> > > > > > Any flying oks ?
> > > > > >
> > > > > > Cheers,
> > > > > > Paco.
> > > > > >
> > > > > > --
> > > > > > Paco Esteban.
> > > > > > 0x5818130B8A6DBC03
> > > > >
> > > > > Not building on sparc64.
> > > > >
> > > > > --
> > > > >
> > > > > Tracey Emery
> > > >
> > > > Paco, here is a newer version fixed for sparc64. It rearranges to get
> > > > closer to Makefile.template ordering and gets rid of your patch. I'll
> > > > give you a flying ok with this one as long as a go/rust person agrees
> > > > that it's "ok." ;)
> > > >
> > > > Then again, no documentation on where the hell MODCARGO_CRATES goes
> > > > makes me sad. But, just trying to be a bit pedantic, since lack thereof
> > > > in the past has bitten me. :)
> > > >
> > > > I've tested this on sparc64 and amd64. Both build and appear to run.
> > > >
> > > > What do you think about this version?
> > >
> > > Looks good to me with a comment. Why remove the @comment on PLIST ?
> > > I've been told that only this line is correct:
> > > @lib lib/libtree-sitter.so.${LIBtree-sitter_VERSION}
> > >
> > > And they are symlinks anyway so ...
> > >
> >
> > Sorry, I forgot to put those back. I was looking at possible reasons for
> > neovim wantlib problems, and left those out for when you send me a copy
> > of your neovim port :D
> >
> > In my ports, I've never commented that stuff out, so I don't
> > know what's right and what isn't. Perhaps, someone can enlighten us. I
> > personally don't see a problem not commenting them and haven't
> > encountered any problems to date.
>
> Hopefully final version with all the suggestions from tracey@ and sthen@
>
> ok to go in ?
>

Fine on sparc64 and any other needed changes can be made in tree.

ok with the patch explanation, as discussed tracey@

> --
> Paco Esteban.
> 0x5818130B8A6DBC03



--

Tracey Emery