 |
lua-l archive |
|
|
||
|
On 27/08/2011 19.51, Dimiter "malkia" Stanev wrote: [...]
well, in fact the search path when Windows loads a dll is as following (in order)(see MSDN): 1. The directory where the executable module for the current process is located. 2. The current directory. 3. The Windows system directory. The *GetSystemDirectory* function retrieves the path of this directory. 4. The Windows directory. The *GetWindowsDirectory *function retrieves the path of this directory. 5. The directories listed in the PATH environment variable. when the dependenies are not so many, I would prefer to put them into one single directory, and add this directory to the PATH envirenment variable(on Linux, the LD_LIBRARY_PATH variable)
Unfortunataly I don't know much about *NIX platforms, besides basic shell commands and little more.
On Windows there's another problem hidden in that search strategy you cite above. The current dir is searched BEFORE the path variable. This means that if your app happens to be called with a current dir in which there is a DLL with the same name of one of those it is linked to, you are busted! (There are also security implications to this).
The only sure way to avoid it is to place all the stuff in the exe dir (or the LOAD_WITH_ALTERED_SEARCH_PATH, if you can)!
Moreover using PATH has its problems. It is a "shared" resource, somewhat. Every app you install tries to fiddle with that. Not always doing the right thing. Of course you can set the PATH for every process you start, but this is boring and requires ubiquitous shell scripts (And Windows command processor is a PITA - I often use Lua scripts just to do things I used to do with batch files!).
Moreover this doesn't play well with other tools you may want to start from your lua script. If you clear the PATH for the lua.exe process and then you want to do os.execute"cool-tool.exe", but "cool-tool" assumes something is on the path, again you are busted (or you enter a path-setting nightmare!).
Usually I use OS PATH only for things I must have available on the command line, and forget about it otherwise.
How can you *set* an env var in Lua? You can only use os.getenv to retrieve their value. There is no os.setenv. Are you using a patched version or a C add-on to do it?I can set the env in user login/startup script, or in lua script.
I don't like to scatter dlls in many directories. at all, they are SHARED libraries, and there should not be so many of them.
The problem, at least on Windows, is versioning and naming conflicts. There is no way AFAIK to tell the dynamic linker you want to link against a specific version of a DLL. It only cares about its name. So usually versioning is done by putting numbers in the name itself. But this is usual practice only for major versions, if ever. I've run several times into equally named DLLs (bundled with different apps) but which have different minor version number. It is supposed that the DLL author *should* have preserved backward compatibility when fixing a bug, but you never know...
But I suppose this is more about personal taste. since you would only run it on Windows, you could just do it in platform (Windows) specific way as package.loadlib or so.
Ah! Good point! I did not consider that my approach is platform specific. Not a problem for me now, but good to know. Thanks!
as long as you don't move to different platform, the package.loadlib works just fine. nothing to worry. My opinion. Hopefully useful.
Thanks for the feedback!