Modding, Mission Design, and Coding > Cross-Platform Development

LUA 5.2

(1/4) > >>

Steel01:
Has it really been six years since I posted around here? Wow...

Anyways, I upgraded my gaming desktop and buildbot to Fedora 20 and noticed my rpm build failed for fs2_open current svn trunk. Seems Fedora is now shipping LUA 5.2, which isn't supported by fs2_open yet. I don't know how much changed between 5.1 and 5.2, but it seems fairly small. After removing the configure.ac version cap, I got one warning and three errors, but I know how those can spiderweb. I can post logs later if that would help. If Fedora is shipping it now, other distros will likely follow suit soon.

In other news, I've got a lot to catch up on around here now that I'm out of college and have somewhat more time. A lot of good changes have happened in that time. Good job, devs.

Steel01

niffiwan:
I threw the lua < 5.2 check into configure.ac because there were reports of it not working properly in FSO. And unfortunately Fedora20 doesn't seem to provide lua5.1 as a separate package. IIRC, there has been some discussion about adding 5.2 support, or moving to luajit.  I can't remember exactly what the status of that is though.

Anyway - posting the logs would be good anyway - were they build errors or FSO errors?

chief1983:
I think my Ubuntu VM has both 5.1 and 5.2 available so I think I can experiment a bit with 5.2.

Steel01:
Build errors. They're at the end of the post. And yeah, not surprised F20 doesn't ship the last version. Bleeding edge distro and all. I've come to expect this, and it's half the fun. If y'all get a patch that needs testing, let me know. I've got a 64-bit F20 install to run on and a 32-bit F20 build bot with a 64-bit compiler grafted in available for testing.

Steel01


--- Code: ---parse/lua.cpp: In function ‘int l_Object___tostring_f(lua_State*)’:
parse/lua.cpp:4786:68: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘int’ [-Wformat=]
    sprintf(buf, "Object %ld [%d]", OBJ_INDEX(objh->objp), objh->sig);
                                                                    ^
parse/lua.cpp: In member function ‘int script_state::CreateLuaState()’:
parse/lua.cpp:14615:26: error: ‘lua_open’ was not declared in this scope
  lua_State *L = lua_open();
                          ^
parse/lua.cpp:14629:16: error: ‘LUA_GLOBALSINDEX’ was not declared in this scope
  lua_rawget(L, LUA_GLOBALSINDEX);
                ^
parse/lua.cpp: In member function ‘int ade_table_entry::SetTable(lua_State*, int, int)’:
parse/lua.cpp:15454:20: error: ‘LUA_GLOBALSINDEX’ was not declared in this scope
    if(p_amt_ldx != LUA_GLOBALSINDEX)
                    ^
make[1]: *** [lua.o] Error 1
--- End code ---

Edit: Just for kicks, I fired off the executable from my last F19 rpm build. Runs like a charm. Guess the vanilla fs2 campaign doesn't use lua. That or fs2_open gracefully handles the failure to open the lua interpreter and doesn't output any errors to stdout about it.

Edit to my edit: Or it's statically linked. Brain cramp moment... *scurries back off*

m!m:
LuaJIT works fine (see my cmake branch) but it exposes the Lua 5.1 API so if we want to switch to luajit at some point we will have to keep using Lua 5.1.

Navigation

[0] Message Index

[#] Next page