Re: howto run 5.3 alongside 5.2?

[William Ahern <william@...>]

On Fri, Jan 01, 2016 at 03:09:57PM +0000, Meer, Hans van der wrote:
> I would like to switch from 5.2 to 5.3.
> 
> However, if incompatibilities arise then a switch back to 5.2 should be
> easy. Something like LUA_VERSION=5.3 instead of LUA_VERSION=5.2 in the
> .bashrc file.

My luapath project contains two portable shell scripts you might find
useful, luapath and runlua.

luapath - locates interpreter, include, module, and library paths for help
building and installing Lua modules. It's intended function is similar to
pkg-config, except it doesn't require pkg-config, any other dependency, or
even any cooperation. It will use (after verifying) pkg-config variables,
but does much more, and is especially useful when dealing with ad hoc Lua
installations (e.g. not distribution packages). NB: the various search
heuristics must be specifically requested--I usually always specify -krm5.
Example output:

  $ ./luapath -v5.3 -krm5 cppflags
  -I/usr/local/lua53/include (OS X, non-packaged Lua install)
  -I/usr/local/include/lua-5.3 (OpenBSD 5.8, lua-5.3.1 package)
  -I/opt/lua53/include (Solaris 11.2, non-packaged Lua install)

runlua - locates and executes interpreter by API or release version. It can
be called similar to the PUC Lua binary. (But see below.) It supports both
command-line arguments and environment variables for choosing the Lua
version. Command-line arguments override environment variables, but you can
reverse that by prepending "!" to the environment value.

  $ ./runlua -r5.2 -v
  Lua 5.2.3  Copyright (C) 1994-2013 Lua.org, PUC-Rio
  $ RUNLUA_R='!5.3' ./runlua -r5.2 -v
  Lua 5.3.2  Copyright (C) 1994-2015 Lua.org, PUC-Rio

The additional -t switch solves some pthread issues. FreeBSD, NetBSD, and
OpenBSD do not support loading libpthread at runtime (e.g. as a dependency
of a module). glibc nominally supports loading libpthread dynamically, but
there are several very old, very critical open bugs related to their
support. As an alternative to recompiling the Lua VM (which AFAIK
distributions don't yet do for Lua like they do for Perl, Python, and Ruby),
the -t switch will attempt to use special linker environment variables to
load libpthread at invocation time.

Because runlua is a shell script which uses shebang, you cannot portably
call runlua from the shebang. In my tests only the Linux and OS X kernels
support shebang chaining. Instead, I usually use this construct:

  #!/bin/sh
  _=[[
    # You can do useful stuff here, like using getopts(1) or setting up
    # the environment. Nice if you don't want to create a dependency
    # on luaposix or similar modules.

    exec runlua -t -r5.2 "$0" "$@"
  ]]
  -- begin Lua code

If I want to force the script to use a different version, I can just set
RUNLUA_R.

> My question: if I do "make install" in the 5.3 codebase is this still doable? Or will there be confusion between the two versions, making a simple switch in this manner undoable?

The default Makefile flags will install the interpreter to
/usr/local/bin/lua, overwriting whatever was there. I usually install Lua
into separate /usr/local/luaNN or /opt/luaNN directories. Package managers
will usually install the interpreters into the same bin/ directory, but
suffixed with NN, -NN, or -N.N; they may make lua a symlink to one of them.

> By the way, in the .bashrc-file I have configured lua as follows:
> LUA_VERSION=5.2
> export LUA_VERSION
> LUA_DIR=/usr/local
> export LUA_DIR
> LUA_INCL=$LUA_DIR/include
> export LUA_INCL
> LUA_SHAREDIR=$LUA_DIR/share/lua/$LUA_VERSION
> export LUA_SHAREDIR
> LUA_LIBDIR=$LUA_DIR/lib/lua/$LUA_VERSION
> export LUA_LIBDIR
> LUA_PATH="./?.lua;./?/?.lua;$LUA_SHAREDIR/?.lua;$LUA_SHAREDIR/?/?.lua"
> export LUA_PATH
> LUA_CPATH="./?.so;./?/?.so;$LUA_LIBDIR/?.so;$LUA_LIBDIR/?/?.so"
> export LUA_CPATH

What I usually do is set all of these unconditionally:

LUA_PATH
LUA_CPATH
LUA_PATH_5_2
LUA_CPATH_5_2
LUA_PATH_5_3
LUA_CPATH_5_3

Lua 5.1 will only read LUA_PATH and LUA_CPATH. Lua 5.2 and Lua 5.3 will try
their respectively versioned variables first. So it all works out. All you
have to care about is running the correct binary.