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
(that’s 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 package.exedir
.
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 package.path
in luaconf.h
. This allows luapower modules to be found regardless of what the current directory is, making the distribution portable.
The default package.cpath
was also modified from !\?.dll
to !\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 lib
.
The !
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
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
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 RPATH
not 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
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 lua_loadfile
.
_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 package.path
in terralib_luapower.lua
.
Last updated:
17 months ago
|
Edit on GitHub