What Lua dialiect is this?
This is OpenResty’s LuaJIT 2.1 fork, which means the base language is Lua 5.1 plus the following extensions:
What is included
LuaJIT binaries (frontend, static library, dynamic library).
Comes bundled with the
luajit command, which is a simple shell script that finds and loads the appropriate luajit executable for your platform/arch so that typing
luajit on Windows) always works.
LuaJIT was compiled using its original makefile.
Making portable apps
To make a portable app that can run from any directory out of the box, every subsystem of the app that needs to open a file must look for that file in a location relative to the app’s directory. This means at least three things:
- Lua’s require() must look in exe-relative dirs first,
- the OS’s shared library loader must look in exe-relative dirs first,
- the app itself must look for assets, config files, etc. in exe-relative dirs first.
The solutions for the first two problems are platform-specific and are described below. As for the third problem, you can use
To get the location of the running script, as opposed to that of the executable, use glue.bin. To add more paths to package.path and package.cpath at runtime, use glue.luapath and glue.cpath respectively.
If you choose to use a LuaJIT binary of your own that doesn’t have
package.exedir, you can extract the exe’s path from
arg[-n] or use the more reliable fs.exedir if you can have fs as a dependency.
Finding Lua modules
!\..\..\?.lua;!\..\..\?\init.lua was added to the default
luaconf.h. This allows luapower modules to be found regardless of what the current directory is, making the distribution portable.
package.cpath was also modified from
!\clib\?.dll. This is to distinguish between Lua/C modules and other binary dependencies and avoid name clashes on Windows where shared libraries are not prefixed with
! symbol was implemented for Linux and OSX too.
The current directory
Lua modules (including Lua/C modules) are searched for in the current directory first (on any platform), so the isolation from the host system is not absolute.
This is the Lua’s default setting and although it’s arguably a security risk, it’s convenient for when you want to have a single luapower tree, possibly added to the system PATH, to be shared between many apps. In this case, starting luajit in the directory of the app makes the app’s modules accessible automatically.
Finding shared libraries
Windows looks for dlls in the directory of the executable first by default, and that’s where the luapower dlls are, so isolation from system libraries is acheived automatically in this case.
Linux binaries are built with
rpath=$ORIGIN which makes ldd look for shared objects in the directory of the exe first.
-Wl,--disable-new-dtags was also used so that it’s
RUNPATH that is being set, which makes
dlopen() work the same from dynamically loaded code too (this enables eg.
terralib.linklibrary to link against luapower libraries by name alone). I’m biting my tongue so hard here…
OSX binaries are built with
rpath=@loader_path which makes the dynamic loader look for dylibs in the directory of the exe first.
The current directory
The current directory is not used for finding shared libraries on Linux and OSX. It’s only used on Windows, but has lower priority than the exe’s directory.
Finding terra modules
The luajit executable was modified to call
require'terra' before trying to run
.t files at the command line. Also, it loads
.t files by calling
_G.loadfile instead of the C function
_G.loadfile is overriden in
terralib_luapower.lua to load
.t files as Terra source code.
terralib.lua was changed to load
terralib_luapower.lua at the end of the file.
package.terrapath is set to match
13 months ago
Edit on GitHub