lua-users home
lua-l archive

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

On Wed, Mar 26, 2014 at 08:46:38AM +0200, Dirk Laurie wrote:
> There seems to be no way of making Lua code say politely:
> "This program requires Lua 5.3" when running under Lua 5.2.
> Instead, one gets a nasty message like
> ./myprog.lua:28: unexpected symbol near '&'
> as soon as it hits a bitwise operator.
> But maybe it is not late for next time round.  We are already
> ignoring one leading `#` line. We could equally well ignore
> all leading `#` lines and tag some of them as expressions to be
> asserted _before_ proceeding to lexical analysis of the file.
> This would allow elegant version control and more.
> E.g.
> #! /usr/bin/env lua
> #@ _VERSION >= 6.0
> #@ bit32
> When Lua 5.3 runs this program, or Lua 6.0 runs it without
> having preloaded a bit32 library, the rest of the file would not
> even be looked at.

Not the kind of solution you were looking for, but FWIW I use my luapath
script to search $PATH for the proper interpreter. For example

	$ ./luapath lua
	$ ./luapath -v5.2 lua
	$ ./luapath -j- lua

I'll add something like this to my Makefile

	$(DESTDIR)$(bindir)/foo: ./foo
		sed -e "1s@.*@\#\!$$(./luapath -v5.3- lua)@" < $< > $@

which will fixup the first line to the proper path to the Lua interpreter.
The argument "-v5.3-" means 5.3 or later. (I would normally also allow the
user to optionally specify the desired path. So, for example, my Debian
package rules would specify the well known path on Debian. And of course you
want code in there to detect when a path couldn't be found.)

I do something similar _before_ installing by locating the correct luac
interpreter (or /bin/true if not found) and using the -p argument to test
that the file compiles properly before installing, to help catch bugs from
minor edits that I was just sure couldn't cause any problems.

The luapath project page is here:

And the luapath script is _rigorously_ POSIX. Although I've only been able
to test it on Linux, OS X, Solaris, FreeBSD, NetBSD, and OpenBSD.

It can also rearrange -I paths in CPPFLAGS so the proper header files load
when compiling a particular version, without requiring the user to specify a
different CPPFLAGS value.