[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: how to statically link to luasocket, http.socket is not found
- From: Sean Conner <sean@...>
- Date: Fri, 3 May 2013 19:04:01 -0400
It was thus said that the Great Black, James A. once stated:
> Hello,
> OK, so I am statically linking to luasocket, but the .lua scripts are not in my lib file.
>
> Should I copy all of them to my application directory?
>
> Or is there a better approach?
It depends on if you want to make it easier for you, or your users. For
you, just make sure the Lua files are copied along with your executable and
can be found via "require()".
But if you want to make it easier on your users (just copy this
executable, run it, don't have to think about installing anything else) it's
a bit more work, but doable. I've done two approaches, both equally valid
but with a tradeoff (simplicity vs. initial memory use). The first,
simplicity, I have outlined in
http://boston.conman.org/2013/03/22.1
where I compile in the Lua source code into the executable, and populate
the Lua written modules, along with the C written modules, into the
package.preloaded[] array. This is easy, but since all the modules are
loaded, they take data memory regardless of actual use (and in my case that
was unacceptable, but only because one of the modules was something like 3M
of data and wasn't always used).
The next approach was similar:
http://boston.conman.org/2013/03/23.1
I compiled in the Lua source code, but instead of initializing each module
and populating package.preloaded[], I inserted two loaders into
package.loaders[]; one just called luaopen_module() (a C written module) if
found; the other one would call luaL_loadbuffer() on the source code [1] if
found. Technically yes, unused modules still used memory just sitting
there, but the actual data usage (in the lua_State structure) was better (an
unused module would just sit in read-only memory [2]).
The compilation step is only mildly more complex---I didn't use the
existing modules makefiles (in the case of LPeg or LuaXML) but included my
own compilation steps in the makefile I use for the project [4].
-spc (Hope this is of some help)
[1] In my case, I would uncompress the data first, using zlib [3], then
call luaL_loadbuffer().
[2] In Unix, data declared "const" will reside in a read-only segment.
If paged out, the data does not need to be written to the swap file;
instead if required to be paged back in, it can be read directly
from the executable residing on the disk. Furthermore, each
instance of the program will share read-only pages, so again, unused
modules won't bloat the process size.
[3] Easy enough to use.
[4] Over 1,200 lines, but it also compiles Lua, in addition to the Lua
modules, plus the application code, in one non-recursive [5]
makefile.
[5] Recursive Make considered harmful:
http://miller.emu.id.au/pmiller/books/rmch/