[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: custom interpreters and modules in zip files
- From: Sean Conner <sean@...>
- Date: Sun, 14 Apr 2019 16:11:39 -0400
It was thus said that the Great Jim once stated:
> On 4/12/19, Sean Conner <email@example.com> 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:
%.o : %.lua
$(LUAC) -o $(*D)/$(*F).out $<
$(BIN2C) -9 -o $(*D)/$(*F).l.c -t $(NS)$(*F) $(*D)/$(*F).out
$(CC) $(CFLAGS) -c -o $@ $(*D)/$(*F).l.c
$(RM) $(*D)/$(*F).out $(*D)/$(*F).l.c
$(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.