lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi Wim,

Wim Couwenberg wrote:
> > The problem with storing load paths is that they need to be absolute.
> > THis can be done on Windows and on *nix.
> > If you place your Lua  code in a directory relative to the DLL, knowing
> > where your Lua source is present no problem (in w6).
> 
> Do you mean without the GetModuleXXX calls above?  How so?
> 
If you are using loadlib()/require() you are already using platform 
specific code.
GetModuleFileName() will return you the full path of a Lua loaded DLL,
our solution as to where to put the Lua source was twofold: 
1) we often package the Lua code as Windows resources. We found
this to be simple and convenient. A Lua script that creates the resource
file does most of the work. When the script is in an associated DLL it is
rather simple (and quick) to write a loader that loads the code from a resource.
This approach requires some small mods to loadlib.c in both 5.0.2 and 5.1w6.

2) Lets say we have myapp.dll and myappstuff.lua, also assume the the dll is
the component that gets loaded by require(). The first option is to install the
executable, DLLs and scripts in the one directory in this case the Lua script
is in the executable directory, very simple.
A variation on this occurs when the executable and DLL directories
differ, in this
case GetModuleFileName() can be used to establish the fullpath of the Lua
script based on a convention that places the script in child directory of the
DLL directory.

Finally, for 5.1 the executable directory (methinks) will be available
as a substitution
character in LUA_PATH/LUA_CPATH (I have forgotten what Roberto said he
would use for a substitution character, but it is discussed in an
earlier thread).
So for an app that contains a Lua VM we can have directory structures
(in Windows)
that look like
/myapp
/myapp/myapp.exe
/myapp/myluapackage.dll
/myapp/script/xxxx.lua

You can always find the script because it is located relative to the
DLL and the DLL
tells you where itself is.

It also my understanding that in 5.1 that require() and loadfile()
will use a common
search strategy when looking for a script. This further simplifies
locating non-package
scripts.

David B