Re: runlua: Portable Lua Invocation for POSIX

[William Ahern <william@...>]

On Fri, Jan 23, 2015 at 09:13:06AM +0100, Valerio Schiavoni wrote:
> This looks cool.
> Is this going in the direction of being the 'RVM for Lua" (http://rvm.io) ?

That would be pretty ambitious. One step would be to add integration with
LuaRocks, but LuaRocks still has problems with portability, dealing with
multiple interpreters, and dealing with different installation layouts. I
haven't had time to dive into the LuaRocks code to untangle things because
I'm focused on making sure my stuff compiles everywhere.

The problem isn't the porting, per se. As long as you stick to standards,
don't unwittingly use non-portable Linux constructs, and minimize your
dependencies, it's not that difficult to write portable code.

The real issue is that initial testing and regression testing is really
tedious when juggling many different platforms, and it's compounded by
trying to support multiple different Lua versions with ad hoc installations.
I regularly test my projects on 7 different operating systems, and over 10
different hosts. That includes multiple different Linux distributions and
embedded firmwares. There are nearly as many different Lua installation
layouts[1]. Then multiply all that by the different Lua implementations: PUC
Lua 5.1, LuaJIT 2.0, PUC Lua 5.2, PUC Lua 5.3... it's insane!

The solution to the tedium is automation. I've dealt with most of the
compile-time problems with my luapath script. Among other things, luapath
can locate Lua headers, automatically reorder CPPFLAGS, and determine
install paths.[1] I can build my modules against all the Lua API 5.x APIs
simultaneously, in the same make invocation. IOW, I don't have to specify
different flags for different invocations. That's a feature I've found to be
quite useful to help me catch API issues earlier.

runlua was what I needed to help with runtime execution and specifically
automated regression testing. With luapath and runlua, I can finally begin
automating the task of pushing code changes, re-compiling, and running
regression tests across all the different platforms I support, without
having to rememeber the peculiarities of each platform's Lua installation or
have ad hoc support scripts on each host.

Once I actually have an automated testing work flow with my own projects,
then I might have some time to figure out why LuaRocks has been so difficult
for me to use.

[1] A few of the platforms I test on have pkg-config, either the
freedesktop.org implementation or an independent implementation (e.g.
OpenBSD). I don't think any of them have identical and correct variables
other than prefix and includedir, and that's even across Linux
distributions, not Linux vs BSD. libdir is wrong sometimes, as are some
other variables, and variables like INSTALL_CMOD, INSTALL_LMOD, version, etc
are not universal. In fact, on the same Ubuntu 14.04 box the set of
pkg-config variables for PUC Lua and LuaJIT are different, and the values
for libdir and INSTALL_LMOD are wrong for the LuaJIT package! So pkg-config
alone solves much less in practice than one might think, and of course it's
only useful where pkg-config exists _and_ the Lua intallation is recorded by
pkg-config.