lua-users home
lua-l archive

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

On Wed, Dec 21, 2011 at 1:57 PM, Antonio Scuri <> 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 [2].  loadall.dll/so may warrant a suffix as well.

The use of the "lib" prefix below seems odd to me since, as discussed
in [2], 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.

  		LUA_CDIR"?.so;" LUA_CDIR";" "./?.so" \
      LUA_CDIR"lib?;" "./lib?"

One thing that probably should be mentioned in the specification [1]
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."
> --

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) [5].