It was thus said that the Great Jim once stated:
> On 4/12/19, Sean Conner <[hidden email]> wrote:
> > At work, I have a custom Lua interpreter that embeds
> > all the Lua modules we need into a single Lua executable.
> we did similar and wrote a new interpreter that already
> provides our C functions in a global table.
For the modules written in C, I registered the luaopen() function in
the package.preload array.
> > This includes modules written in C and Lua.
> how do you handle the pure Lua code ?
> is it directly included as C strings in the binary
> (as "premake" does) or is it loaded from files ?
We use GNUMake as the build system, so I created this implicit rule to
compile Lua code into object files:
$(LUAC) is the Lua compiler, but the one checked into the repo (not all our
systems have Lua installed). $(BIN2C) is a program that takes the given
file (text or binary, doesn't matter), and generates a C file with an
external symbol given by '-t', which is then compiled into a .o file and the
.c file removed.
> > Then I played around with an idea to load Lua modules directly from a zip
> > file . What's the path for these? That of the zip file? It doesn't
> > make sense.
> why not ? Tcl has something like this built in and can handle
> "file systems" on zip files (and elsewhere).
> > It kind of worked, in that I could load and run Lua modules written
> > in Lua directly from the zip file, but not those written in C.
It's a limitation of dlopen()---it will *only* load shared objects from a
file, not from memory.