Hello Hisham, Thanks for taking the time to respond!
On 06/03/2015 10:27 PM, Hisham wrote: > The current version on git provides a `luarocks config --lua-ver` > command (though LuaJIT responds as "5.1"). Perhaps a --lua-flavour, or something similar might be useful then? Anyway, parsing the version string is pretty simple and foolproof. It doesn't change for existing releases, and you can even double-check you're getting a sensible result and complain if you don't, just in case upcoming releases change the pattern. >> 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. I understand your point, but, given that LR already provides most of the building flags to a Makefile, one is then left with no "correct" choice on how to supply the rest. I could use pkg-config for instance, but then, I feel like I should check to make sure that the -I and -L switches given by LR and pkg-config match and do something if they don't, although I'm not sure what. Incidentally, since LR does not provide me with a library name, why does it provide me with a LUA_LIBDIR? I tried making the module without it and it seems to work just fine, as I suppose it should. >> 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. Yes, I've though of that, or rather, a user suggested it, by creating a pull request on Github with such an implementation, with the express purpose of adding it to LuaRocks. I agree that it's an alternative and, furthermore, that it works just as well as a native C implementation. I don't like it though, design-wise and it would mean scrapping my already working C code. I know these are not very strong arguments and I'd probably consider it as an alternative if you wouldn't consider allowing the modifications to make LuaRocks handle binary compilation. If you would though, I'd prefer keeping the stand-alone REPL in C and figuring out a work-around hack for the meantime, until the changes are implemented. I'd gladly offer my help, but I don't think much is involved for LuaRocks itself. Only the packagers for each distro would have to be advised to provide the correct LUALIB value, based on the configured Lua version, which should be simple enough. Another change that would be required, or at least nice, would be to move the -fPIC flag over to the LIBFLAG variable, since it's technically only necessary to build libraries and right now I'm forced to either skip any other switches in CFLAGS, or provide it when building the binary too. I doubt the resulting overhead would be of any significance, but it'd be nice to avoid it. If you'd be interested in adding a mechanism to build programs with the "builtin" build type, a "programs" table to complement "modules", I'd also offer to look into that and provide you with a with an implementation, if you want (and if I can of course :) ). D. ------------------------------------------------------------------------------ _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
