lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> 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)