the #ifdef logic in luaconf.h for loadlib support does not work
properly
on a variety of systems. I think it's easier to reorder the tests and
just assume the availability of POSIX dlfcn unless we know otherwise
(i.e. only for Windows and Mac OS X (* see below for more)).
Now you need to explicitly disable loadlib support in the config file
for
systems that do *not* have it. You'll probably need to modify the
config file
for these kind of systems, anyway.
The intention is to reduce the number of modifications required for a
standard installation on the majority of systems to zero.
The other changes included in this patch are:
config:
- Clean up the comments.
- Avoid the MYLDFLAGS redefinition pitfall.
Makefile:
- Create the C library and Lua library directories when installing.
- Stop echoing unused Makefile variables.
src/Makefile:
src/lib/Makefile:
- Add simplified dependencies. Certainly better than no dependencies.
include/lua.h:
- Add a version define that allows for stuff like:
#if defined(LUA_VERSION_NUM) && LUA_VERSION_NUM >= 0x050100L
Note that prerelease ("work") versions need to be tagged with the
release
version they are destined for ("5.1.0" -> 0x050100L).
NB: It needs to be a long constant to account for 16 bit systems.
include/luaconf.h:
- Correct the version number in the library paths.
- Add standard library paths for Windows.
- Set the proper directory separator for Windows.
- Got rid of the double TMPNAME define (who is using it anyway?).
src/lib/loadlib.c:
- Modify the translation of module names to C function names. A module
"foo.bar.baz" previously had to provide luaopen_foobarbaz() and now
should use luaopen_foo_bar_baz().
Comments welcome!
(*) One open issue left is the loadlib support for Mac OS X:
AFAIK Mac OS X has two different mechanisms for dynamic libraries:
dylibs
and bundles. The former is used for basic libraries while the latter is
used for framework components aka plugins.
One unpleasant fact is that dylibs cannot be unloaded (as noted in the
comments in loadlib.c) because they are not intended for this use.
However this is generally very desirable for Lua modules (e.g. level
loading/unloading in games). And (BTW) Lua-5.1-work3 includes support
for
garbage collecting loaded C modules.
I am not a Mac OS X expert but the docs I've read more or less say
that you
are supposed to use bundles whenever you need some kind of pluggable
modules.
Since Lua modules are only useful when loaded by Lua there is no
necessity
to make them dylibs. They are more like plugins, anyway.
Can any Mac OS X experts please confirm this? Should Lua C modules
switch
from dylibs to bundles? If yes, can anyone provide the required
modifications
for loadlib.c?
Bye,
Mike
<lua-5.1-work3-loadlib.patch>
