[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] lua-ConciseSerialization : another pure Lua implementation of CBOR / RFC7049
- From: "Vadim A. Misbakh-Soloviov" <lua-l@...>
- Date: Sat, 03 Dec 2016 16:49:05 +0700
> 1) What about environment variables? Would doing the following help?
>
> LUA ?= lua
> LUA_VERSION = $(shell $(LUA) -e "io.stdout:write(_VERSION:match '^Lua
> (.*)','\n')") LIBDIR ?= $(LUA_DIR)/lib/lua/$(LUA_VERSION)
> LUADIR ?= $(LUA_DIR)/share/lua/$(LUA_VERSION)
>
> Then you could set $LUA (and $LIBDIR and $LUADIR) since that seems to be all
> you change in the Makefile (and these are the ones LuaRocks define for use
> in Makefiles).
Yeah, it will help a bit (excluding missed `LUA_DIR` variable naming in
`LIBDIR`/`LUADIR` values), so I'll be able to just place variable definitions
to configure stage, instead of patching :)
And, by the way, luadir/libdir definition could be "old", with lua calls
(because it will return right paths for current lua implementation, which can
be not in $prefix/lib/, but in $prefix/lib64 or $prefix/libx32 or even libo32/
libn32 on some arches.
>
> 2) Maintainer of my package? Who (or for what) are you maintaining it? It
> must be working for you since I haven't heard of any issues yet ... (well,
> except for this one).
There are kind of people, called distro package maintainers. I'm one of them.
Actually, I maintain many lua packages (that still not added to main repo) in
distro's semi-official lua repo.
// it is anyway a bad practice to install system-wide packages not through
system package manager, so many lua packages needs to be maintained as distro
packages (at least, until luarocks itself, without 3party kludges, become
someting like Ruby's bundler or python's virtualenv, and new Lua releases will
return old package.{c,}path order)