lua 5.2.3

[adamv]

Taken from Homebrew-versions.

[asparagui]

😉

[adamv]

Need to modernize patch syntax.

[adamv]

Is there no .pc file? Need to add one.

[adamv]

• highlight 3.18 builds against 5.2 (and not 5.1)

[adamv]

• fceux testing blocked by fceux does not build (to non-/usr/local) #29257.

[adamv]

• imapfilter works

[adamv]

• kyoto-tycoon fixed in kyoto-tycoon: find non-/usr/local lua #29258.

[adamv]

• tokyo-tyrant uses "lua_objlen" which has changed in 5.2.

[adamv]

• lighttpd uses "LUA_GLOBALSINDEX"

[adamv]

• pdns works

[adamv]

• pdnsrec uses lua_objlen and lua_open

[asparagui]

@adamv Is there anything I can help with?

[adamv]

• lsyncd works

[adamv]

@asparagui researching patches for things that use 5.1-only features I suppose

[adamv]

• tracebox works, will need to be rebottled

[adamv]

• monotone works now

[adamv]

• mysql-proxy fails:

lua-load-factory.c:122:59: error: too few arguments to function call, expected 5, have 4
        return lua_load(L, loadstring_factory_reader, &factory, s);
               ~~~~~~~~                                          ^

[adamv]

• weechat works. Somehow I'm surprised by this.

[adamv]

• wireshark works

[adamv]

• gnuplot works

[adamv]

• vim compiles

[adamv]

• metalua "succeeded", but: https://gist.github.com/adamv/4b9261d33817e2062d40

[adamv]

Metalua issue from 2 years ago: fab13n/metalua#12

Suggest metaula be moved out of core when Lua 5.2.3 is merged.

[adamv]

• luabind works (when pointed explicitly to lua)

[DomT4]

No, I wasn't suggesting depreciating it entirely, just either having them side by side as Lua1 and Lua2 like Python, or making Lua1 keg-only and having lua2 be the one that links into /usr/local/bin.

[sdegutis]

Having lua2 live in the main repo also makes sense and works fine. Then the luarocks package could require either lua or lua2. That solves my problem just fine and is probably very easy.

[daurnimator]

btw @DomT4 it is Lua 5.1, 5.2 and 5.3 we're talking about here. Lua 2 came out long ago in 1995 :)

In regards to naming, most linux distros went with calling the executables lua50 lua5.1 lua5.2.
(lua50 was seen as a bad choice)
In some distros, they also ship both a luarocks-5.1 and a luarocks-5.2

It's pretty much a case of doing brew uses lua

Here is the list FWIW: https://gist.github.com/anonymous/99326de36e55d1b25257

[DomT4]

@daurnimator Yeah I know, I'm just simplifying really. I'm not sure how Homebrew would want to handle the naming, since lua51 and lua52 is kinda clunky, but if that's the precedent and what people expect perhaps it'll work.

@sdegutis Eh. Easy = Probably a few hundred lines of code that need to be changed and pushed, and then merge conflicts resolved, and then everything rebottled as applicable 😉.

[sdegutis]

@DomT4 If all we're talking about is adding a new package lua52 to mainly Homebrew, and leaving lua as it is verbatim, then I don't see how it's that difficult, since most packages rely on lua and won't have any idea about this new lua52. Am I misunderstanding?

[MikeMcQuaid]

We'd probably want to add a new lua51 package and move as much as possible to depend on lua (which would be 5.2).

[sdegutis]

@MikeMcQuaid 👍 Let me know if I can help with this in any way, it's a high priority for me.

[DomT4]

@sdegutis Ah I see, I slightly misunderstood you. There remains the issue that one of the luas would either need to be keg_only or the executables would need to be renamed as we do with the Pythons, because right now you can't install lua and lua52 side by side without overriding the symlinks created by one another.

[DomT4]

Like this:

Target /usr/local/bin/lua
is a symlink belonging to lua. You can unlink it:
  brew unlink lua

To force the link and overwrite all conflicting files:
  brew link --overwrite lua52

To list all files that would be deleted:
  brew link --overwrite --dry-run lua52

Possible conflicting files are:
/usr/local/bin/lua -> /usr/local/Cellar/lua/5.1.5/bin/lua
/usr/local/bin/luac -> /usr/local/Cellar/lua/5.1.5/bin/luac
/usr/local/include/lauxlib.h -> /usr/local/Cellar/lua/5.1.5/include/lauxlib.h
/usr/local/include/lua.h -> /usr/local/Cellar/lua/5.1.5/include/lua.h
/usr/local/include/lua.hpp -> /usr/local/Cellar/lua/5.1.5/include/lua.hpp
/usr/local/include/luaconf.h -> /usr/local/Cellar/lua/5.1.5/include/luaconf.h
/usr/local/include/lualib.h -> /usr/local/Cellar/lua/5.1.5/include/lualib.h
/usr/local/share/man/man1/lua.1 -> /usr/local/Cellar/lua/5.1.5/share/man/man1/lua.1
/usr/local/share/man/man1/luac.1 -> /usr/local/Cellar/lua/5.1.5/share/man/man1/luac.1
/usr/local/lib/liblua.dylib -> /usr/local/Cellar/lua/5.1.5/lib/liblua.dylib

[sdegutis]

@DomT4 Fortunately that should be pretty easy, as Lua is extremely small and has very few file and very sanely written configuration scripts.

[DomT4]

Okay. Well, what if we go about this in 3 stages. Someone can tell me if I'm over-complicating this or being downright stupid or causing build problems elsewhere.

1. Rename the current Lua formula to Lua51 and make it append 51 onto the end of its executables. Update & revision everything Lua is a dependency of to force rebuild to expect Lua51 instead of Lua.

2. Bring Lua52 into the main Homebrew, and allow it to symlink itself as Lua, so that would become the default Lua. At this point every other formula would still be pointing towards Lua51 as a dependency.

3. Test everything that brew uses lua51 to compile with lua52, and then pass as many formulas over to the new lua as possible, and force another recompile to get everything back onto the now new, updated lua symlink.

[MikeMcQuaid]

@DomT4 Pretty much, yep.

[DomT4]

Alright. Well, I can probably take care of number 1 this evening if we want to press ahead on this. Chronic insomnia has its upsides 👍.

[sdegutis]

@DomT4 I like that plan, as each step can be done as three different pull requests. And step 1 seems pretty easy, mostly just a find/replace!

[daurnimator]

Okay. Well, what if we go about this in 3 stages. Someone can tell me if I'm over-complicating this or being downright stupid or causing build problems elsewhere.

1. Rename the current Lua formula to Lua51 and make it append 51 onto the end of its executables. Update & revision everything Lua is a dependency of to force rebuild to expect Lua51 instead of Lua.

Sounds good, though we should call it lua5.1 for consistency with other operating systems.

2. Bring Lua52 into the main Homebrew, and allow it to symlink itself as Lua, so that would become the default Lua. At this point every other formula would still be pointing towards Lua51 as a dependency.

3. Test everything that brew uses lua51 to compile with lua52, and then pass as many formulas over to the new lua as possible, and force another recompile to get everything back onto the now new, updated lua symlink.

Sounds good :)

There will no doubt be a couple of stragglers, I suppose we keep 5.1 around until they upgrade?

[DomT4]

I don't know if Homebrew uses . in formula for versioning. We tend to prefer solid numbers, taking a look at Homebrew/Versions. Is there a rule on this @MikeMcQuaid?

[MikeMcQuaid]

Yeh, our format is lua51.

[sdegutis]

Alternatively we can look into other punctuation such as - and _, but honestly Lua is never going to get to version 52, so there's no real ambiguity here. I vote for simplicity in calling them lua51 and lua52 since in context these are completely clear.

[daurnimator]

The reason I point this out, is that people regularly write and distribute lua scripts starting with:

#!/usr/bin/env lua5.1

It'd be a pain in the arse if they worked everywhere except homebrew.

[DomT4]

Could we create an Alias for Lua51 so that it works when people type in Lua5.1 and such? That'd get around that problem.

[MikeMcQuaid]

The binaries can be called that, it's just the filenames for the formula will be lua52.rb.

[sdegutis]

Plus, the names lua51 and lua52 follow the Lua philosophy of not overcomplicating things with black-and-white rules, such as how many of Lua's built-in functions don't use spaces.

[MikeMcQuaid]

Don't worry about these type of things though, we'll catch them in review.

[DomT4]

Alright. I'll go make myself a large jug of tea and start work on this. I'm pretty familiar with the way we handle Python, and Lua is nice and small so testing should be near instant.

[jacknagel]

Closed by 1fed492