On 3 June 2015 at 08:26, Dimitris Papavasiliou <dpapa...@gmail.com> wrote:
> On 05/25/2015 12:34 PM, Dimitris Papavasiliou wrote:
>> Another possibility, would be to depend on exisiting tools like
>> pkg-config, for building auxiliary executables or libraries which depend
>> on Lua. I'd consider this worse, as then there would be two sources of
>> information on how to configure the compiler to build the various
>> components of the rock.
>>
>> Even in this case though, one would need to somehow have access to the
>> currently configured Lua version (5.1, 5.2, 5.3 or jit). Does such a
>> variable exist in LuaRocks? It seems useful as well, in case someone
>> would want to make a multi-version Makefile, handling each version a
>> little differently.
>
> One, somewhat roundabout but nevertheless dependable, way to get the
> version, would be to use the Lua interpreter LuaRocks provides, with the
> -v switch and parse its output.

The current version on git provides a `luarocks config --lua-ver`
command (though LuaJIT responds as "5.1").

> Still, finding a matching pkg-config
> package name is not trivial, as there seems to be quite some variation
> in the way these package are called among the various distros.

Yes, and LR hasn't touched anything on pkg-config (so far, at least).
The mess that is Lua naming is very sad, but it's the responsibility
of the Lua upstream authors. LuaRocks only tries to work around this
to the minimum extent that it needs to.

> Does anyone have any better ideas?  Is this simply something that is not
> in the scope of LuaRocks?

Building binaries that link liblua is certainly beyond the originally
designed scope of LuaRocks. Support for bin/ was adding with Lua
scripts in mind. The feature you're asking for is something we can
consider, but that we don't currently have.

A wild suggestion: you say you're providing a REPL as a Lua module and
as a standalone binary — if you already have it as a module, isn't it
simpler to provide it also as a Lua script that requires the module?
For the end user, experience would be the same, since they would
simply end up with a script in their $PATH and wouldn't care if it
internally launches lua or if it's a binary.

-- Hisham

------------------------------------------------------------------------------
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers

Reply via email to