[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: PATCH: Lua5.1-work3 loadlib cleanups
- From: Asko Kauppi <asko.kauppi@...>
- Date: Tue, 7 Dec 2004 11:26:47 +0200
Myself and Adrian Perez (I think) should have already fixed this OS X
Anyhow, I do have a working loadlib.c for LuaX, that _could_ be used as
such with original Lua. I'll need to see what are the real differences
with w3 there.
And yes, you're right: OS X 'bundles' is what you want to have. Dylibs
are only for 'true' libraries s.a. libm and wouldn't make any sense in
this regard. It's the same as loading dll's at compile time or at
runtime (in Win32), only here the difference is more enforced by Apple.
For some reason..
[ To make it more confusing.. bundle libraries normally have a ".dylib"
extention just as regular libraries do, although they could have any
other s.a. ".lux". Internally they differ. And still.. :) There's a
thing called "application bundles" which reuses the same name but has
otherwise nothing to do with this. Apple's fine, but their use of
terminology could be worth some brushing. ]
7.12.2004 kello 09:50, Mike Pall kirjoitti:
the #ifdef logic in luaconf.h for loadlib support does not work
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
systems that do *not* have it. You'll probably need to modify the
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:
- Clean up the comments.
- Avoid the MYLDFLAGS redefinition pitfall.
- Create the C library and Lua library directories when installing.
- Stop echoing unused Makefile variables.
- Add simplified dependencies. Certainly better than no dependencies.
- 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
version they are destined for ("5.1.0" -> 0x050100L).
NB: It needs to be a long constant to account for 16 bit systems.
- 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?).
- 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().
(*) One open issue left is the loadlib support for Mac OS X:
AFAIK Mac OS X has two different mechanisms for dynamic libraries:
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
garbage collecting loaded C modules.
I am not a Mac OS X expert but the docs I've read more or less say
are supposed to use bundles whenever you need some kind of pluggable
Since Lua modules are only useful when loaded by Lua there is no
to make them dylibs. They are more like plugins, anyway.
Can any Mac OS X experts please confirm this? Should Lua C modules
from dylibs to bundles? If yes, can anyone provide the required