[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [Xavante] Installing without LuaRocks?
- From: steve donovan <steve.j.donovan@...>
- Date: Thu, 20 May 2010 14:41:48 +0200
On Thu, May 20, 2010 at 2:25 PM, Gilles Ganault <gilles.ganault@free.fr> wrote:
> By "binary extensions", do you mean a DLL (like lfs.dll or
> socket\core.dll) that I can just copy into the LuaBinaries directory
> and expect wsapi.exe to run happily, as opposed to downloading their
> source code (in C?) and compiling them myself?
That's exactly right. The Lua for Windows executable looks up the DLL
extensions in the clibs subdirectory (in general, Lua uses the
LUA_CPATH environment variable)
> BTW, does eg. "luarocks install luafilesystem", downloads the source
> code + compiles it + installs the binary output to the right place, or
> does it just fetch a pre-compiled binary from the web?
It depends - for some common rocks, Windows binaries already exist.
If a binary rock exists, Lua Rocks will download that rather than the
source rock.
> Do you mean that by using the MinGW compiler, it'd be possible to
> compile the C runtime (upon which Lua depends) directly in the Lua
> interpreter/compiler/libraries, so the MS C runtime would not longer
> be needed when shipping Lua?
That's totally the point - so that's an awkward 3 megs or so not needed.
> 1. "Executables" are the Lua stand-alone compiler/interpreter, while
> "Windows Libraries" are for C developpers who wish to include Lua as a
> scripting engine within their application?
Yes - usually for Windows, Lua itself is packaged as a DLL and the
interpreter lua.exe calls it. Any binary extensions have to be linked
against the DLL. As for the diffferent version issue, it's not so
much about compiler version as runtime. For instance, you can
persuade GCC to link against mscvr80.dll, which is the runtime used
for Lua for Windows. But it is important that all extensions are
linked against the same runtime, otherwise odd and usually nasty
things will happen at random, even if the OS allows the library to
load.
You have noticed that there is both lua5.1.dll and lua51.dll. This
was a disagreement about what the DLL should be called, so lua51.dll
is a 'proxy' DLL referencing lua5.1.dll. Some extensions link
against lua5.1.dll, some against lua51.dll ;)
steve d.