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
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
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
>
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:
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
>
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
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,
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo