On Wed, Aug 27, 2008 at 12:43 AM, David Manura
<dm.lua@math2.org> wrote:
In comparison...
- In LuaRocks[1], the source (.lua) libs are found in directories named "lua",
and the binary (.so/.dll) libs are found in directories named "lib".
- In luaconf.h of Lua 5.1.4 (and LuaBinaries), the source libs are found in an
absolute path containing the name "lua" (under Windows) or containing the name
"share/lua" (under non-Windows). The binary libs are found in the absolute path
of the Lua executable (under Windows) or containing the name "lib/lua" (under
non-Windows).
So the current convention (not to say it's ideal) seems mostly for LUA_PATH and
LUA_CPATH to correspond to "lua" and "lib" directories respectively. There is
no "clib" as might suggest "clib" contains binary libs and "lib" contains non-C
(Lua only) libs.
This is not consistent with the typical development layout. LfW ships the headers and Lua libraries and uses the 'lib' directory already to hold the Lua developer libraries. So I don't think that name is good.
But I agree that the fact that Windows binary libs are searched for in the same
directory as the Lua interpreter does seem inconsistent and messy.
There is a complication though that might explain it: say lua.exe loads a Lua
module named myluamodule.dll (via LUA_CPATH) that in turn loads a regular
(non-Lua) DLL named zlib1.dll (via PATH and the Windows DLL search order [2]).
Windows ignores LUA_CPATH when loading zlib1.dll. So, typically, you would
place zlib1.dll in either a system directory (undesirable) or the same directory
as lua.exe. The latter leads to the same problem of DLLs littering your lua.exe
directory. One solution (which LfW does but which I don't think LuaRocks
supports) is to modify PATH to correspond to LUA_CPATH. There is alternately a
SetDllDirectory[3], but that is not available in older versions of Windows. So,
if you add "!\clib" to LUA_PATH, it may be best to also patch Lua to append that
directory to PATH via _putenv[4] so as to avoid (as LfW currently does) globally
modifying the PATH environment variable. You might not want to go so far as to
dynamically update PATH whenever package.cpath is dynamically changed though.
Yes I think this is a bit of a heavy approach, plus we still need to be able to run 'lua' on the command line so the PATH will still need to be updated.
--
Regards,
Ryan
RJP Computing
