[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaBinaries 5.2 Released
- From: David Manura <dm.lua@...>
- Date: Wed, 21 Dec 2011 23:52:44 -0500
On Wed, Dec 21, 2011 at 1:57 PM, Antonio Scuri <email@example.com> wrote:
> The only change we do in the Lua source files is in the "luaconf.h" file
> at the LUA_CPATH_DEFAULT definition to add support for the "52" suffix in
> modules. Other files are only added to the standard distribution to compose
> the LuaBinaries packages.
There might be some concerns if a C module happened to have a 51 or 52
suffix in its module name (e.g. I had been thinking of a `_ENV =
require '_G51'` to load a 5.1 compatible environment into 5.2, and Lua
itself has its "bit32" module distinct from "bit"). It's good that
the 51/52 suffix is searched after the blank suffix in the C loader,
but the all-in-one loader is called after the C loader. So, in the
case (however remote) you'd want require "foo52" to load from
foo52.dll and require "foo" to load from the all-in-one loader, that
won't work here *unless* you rename the foo52.dll to foo5252.dll
(ugly). A suffix "-lua52" would not only be more clear (and avoid
ambiguities once Lua 25.2 comes around :)), and I don't think it would
interfere with Lua's "a.v1-b.c" style module naming feature, but it
also more directly addresses the system DLL naming conflict problem
discussed in . loadall.dll/so may warrant a suffix as well.
The use of the "lib" prefix below seems odd to me since, as discussed
in , the "lib" is usually what distinguishes system libraries
(libtiff) from loadable modules (tiff), both of which would be
expected to be loaded into the same process.
#define LUA_CPATH_DEFAULT \
LUA_CDIR"?.so;" LUA_CDIR"loadall.so;" "./?.so" \
One thing that probably should be mentioned in the specification 
is that lua5.1.def exports private functions (luaU_dump, luaM_toobig,
luaM_realloc_, luaS_newlstr, luaD_growstack, luaF_newproto), but
lua52.def does not.
> "For Lua 5.2 We choose the MingW gcc 4 compiler to build the LuaBinaries executables.[...]
> The Visual C++ 8 MSVCR80.DLL was hard to be used because of two factors: its installation
> and the need of a manifest file to build the user modules."
> -- http://luabinaries.sourceforge.net/manual.html
That's a valid choice, but it's worth noting that the manifest thing
is backpedaled in MSVCR100.DLL [3,4]. Another factor to be weighed is
64-bit file I/O support (_fseeki64) .