Re: NEW: libmpack (needs discussion)

2017-02-01 Thread Jeremie Courreges-Anglas
Edd Barrett writes: > Hi, > > On Mon, Jan 23, 2017 at 09:56:04AM +, Stuart Henderson wrote: >> > The port looks fine, but I find all this FULLPKG-fu confusing. >> > Splitting the port would make things more readable IMHO. >> >> hmm, and that would make things a bit

Re: NEW: libmpack (needs discussion)

2017-01-31 Thread Edd Barrett
Hi, On Mon, Jan 23, 2017 at 09:56:04AM +, Stuart Henderson wrote: > > The port looks fine, but I find all this FULLPKG-fu confusing. > > Splitting the port would make things more readable IMHO. > > hmm, and that would make things a bit more sensible for building to support > the multiple lua

Re: NEW: libmpack (needs discussion)

2017-01-23 Thread Stuart Henderson
On 2017/01/22 22:46, Jeremie Courreges-Anglas wrote: > Stuart Henderson writes: > > $ FLAVOR=lua53 make show=FULLPKGPATH-lua > > devel/libmpack,-lua,lua53 > > $ FLAVOR=lua53 make show=PKGNAMES > > libmpack-1.0.3 lua53-mpack-1.0.3-lua53 >

Re: NEW: libmpack (needs discussion)

2017-01-22 Thread Edd Barrett
On Fri, Jan 20, 2017 at 05:59:19PM +0100, Florian Stinglmayr wrote: > > There is a test suite but it needs a load of lua deps we don't yet have > > Which ones? Lua deps are my speciality. It uses a test framework called "busted". Here are the deps from upstream's Makefile:

Re: NEW: libmpack (needs discussion)

2017-01-22 Thread Edd Barrett
Hi Stuart, Jeremie, On Sun, Jan 22, 2017 at 10:46:33PM +0100, Jeremie Courreges-Anglas wrote: > Stuart Henderson writes: > >> I have a feeling that the FULLPKGPATH-lua needs a version suffix, but > >> couldn't find a satisfying way (although what I currently have doesn't >

Re: NEW: libmpack (needs discussion)

2017-01-22 Thread Jeremie Courreges-Anglas
Stuart Henderson writes: > On 2017/01/22 16:50, Edd Barrett wrote: >> Hi, >> >> On Thu, Jan 19, 2017 at 10:07:30PM +0100, Jeremie Courreges-Anglas wrote: >> > > It seems to build for all the lua versions we support, so good :) >> > >> > This is often not enough: pure lua

Re: NEW: libmpack (needs discussion)

2017-01-22 Thread Stuart Henderson
On 2017/01/22 16:50, Edd Barrett wrote: > Hi, > > On Thu, Jan 19, 2017 at 10:07:30PM +0100, Jeremie Courreges-Anglas wrote: > > > It seems to build for all the lua versions we support, so good :) > > > > This is often not enough: pure lua builds typically don't run the code > > at build time,

Re: NEW: libmpack (needs discussion)

2017-01-22 Thread Edd Barrett
Hi, On Thu, Jan 19, 2017 at 10:07:30PM +0100, Jeremie Courreges-Anglas wrote: > > It seems to build for all the lua versions we support, so good :) > > This is often not enough: pure lua builds typically don't run the code > at build time, and C lua extensions might use lua C API functions only

Re: NEW: libmpack (needs discussion)

2017-01-20 Thread Florian Stinglmayr
On Thu, Jan 19, 2017 at 09:21:42PM +, Edd Barrett wrote: > On Thu, Jan 19, 2017 at 10:07:30PM +0100, Jeremie Courreges-Anglas wrote: > > The best way to know if things are right is probably to have a test > > target for the lua module. ;) > > There is a test suite but it needs a load of lua

Re: NEW: libmpack (needs discussion)

2017-01-19 Thread Edd Barrett
On Thu, Jan 19, 2017 at 10:07:30PM +0100, Jeremie Courreges-Anglas wrote: > The best way to know if things are right is probably to have a test > target for the lua module. ;) There is a test suite but it needs a load of lua deps we don't yet have in tree. I think I'll do as you suggest and make

Re: NEW: libmpack (needs discussion)

2017-01-19 Thread Edd Barrett
On Thu, Jan 19, 2017 at 08:49:28PM +, Stuart Henderson wrote: > FULLPKGNAME-main= libmpack-$V > FULLPKGPATH-main= devel/libmpack,-main Nicley done! That's the ticket. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk

Re: NEW: libmpack (needs discussion)

2017-01-19 Thread Jeremie Courreges-Anglas
Edd Barrett writes: > Hi Jeremie, Stuart, > > Thanks for the info and suggestions. > > On Thu, Jan 19, 2017 at 06:03:10PM +0100, Jeremie Courreges-Anglas wrote: >> LuaJIT is not portable. >> >> ONLY_FOR_ARCHS = powerpc i386 amd64 >> >> IMHO this is the kind of fragile

Re: NEW: libmpack (needs discussion)

2017-01-19 Thread Stuart Henderson
On 2017/01/19 20:25, Edd Barrett wrote: > Hi Jeremie, Stuart, > > Thanks for the info and suggestions. > > On Thu, Jan 19, 2017 at 06:03:10PM +0100, Jeremie Courreges-Anglas wrote: > > LuaJIT is not portable. > > > > ONLY_FOR_ARCHS = powerpc i386 amd64 > > > > IMHO this is the kind of fragile

Re: NEW: libmpack (needs discussion)

2017-01-19 Thread Edd Barrett
Hi Jeremie, Stuart, Thanks for the info and suggestions. On Thu, Jan 19, 2017 at 06:03:10PM +0100, Jeremie Courreges-Anglas wrote: > LuaJIT is not portable. > > ONLY_FOR_ARCHS = powerpc i386 amd64 > > IMHO this is the kind of fragile software you'd better avoid if you can. Maybe we can try

Re: NEW: libmpack (needs discussion)

2017-01-19 Thread Jeremie Courreges-Anglas
Edd Barrett writes: > Hi, > > (CCing some people who have worked on lang/lua, hoping one of them knows > the answer to my question below). I don't consider I have much experience with lua, but I recently found myself untangling the versioning mess we had in the ports

Re: NEW: libmpack (needs discussion)

2017-01-18 Thread Stuart Henderson
We already have infrastructure for multiple flavours of lua ports, so I'd just use that. If the default lua version is changed we'll need a wider diff anyway because we'll need to switch from "unflavoured = 5.1" / "lua-XX prefix = 5.1" to something else, and that will need handling across the

NEW: libmpack (needs discussion)

2017-01-17 Thread Edd Barrett
Hi, (CCing some people who have worked on lang/lua, hoping one of them knows the answer to my question below). This is (yet another) neovim dependency. libmpack (not to be confused with libmsgpack): ---8<--- libmpack is a small binary serialization/RPC library that implements both the msgpack