lua-users home
lua-l archive

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

2013/7/11 Hisham <>:
> On 10 July 2013 07:43, John Hind <> wrote:
>> I'd like to suggest two very minor changes to the Lua source code to make
>> life easier for people making compile-time customizations:
>> 1. In 'luaconf.h': At the end of the file instead of / as well as the 'Local
>> configuration' comment, add:
>> #if defined(LUA_USERCONFIG_H)
>> #include LUA_USERCONFIG_H
>> #endif
>> This will allow customisations to be made here without editing the
>> distribution file, making maintenance easier. This is the same technique
>> already used in 'lua.h'.
>> 2. In 'lua.h': Modify the LUA_VERSION macro definition as follows:
>> #if defined(LUA_VARIANT)
>> #else
>> #endif
>> This allows prefixing of the _VERSION string to indicate a variation from
>> 'standard' lua. There may be a more elegant way to do this, but you get the
>> idea.
> I oppose this. There's code out there that assumes that
> _VERSION:sub(5) outputs the API version number of Lua. Any "variant"
> shouldn't pollute _VERSION for the same reason that
> LUA_VERSION_RELEASE does not figure in _VERSION: code shouldn't need
> to know about the Lua patch version or "variant" they're running
> under, and promoting the definition of "Lua variants" as a core
> feature will further dillute the API. (Variant-specific code can
> always expose their own detection methods, such as "jit and
> jit.version" for LuaJIT).

That's valid for variants that add stuff and remain mostly compatible
with plain Lua, but some variants may want to remove features for
example. And they may want to have code checking for _VERSION=="Lua
5.2" to fail.

That being said, I'm neutral regarding the original proposal. If you
change Lua enough to justify breaking the _VERSION checks that Hisham
mentioned, you can probably afford to modify lua.h. But on the other
hand the more stuff is configurable the better.