[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm:[55130] scummvm/trunk/configure

Max Horn max at quendi.de
Thu Jan 6 18:41:51 CET 2011


Am 06.01.2011 um 01:43 schrieb tdhs at users.sourceforge.net:

> Revision: 55130
>          http://scummvm.svn.sourceforge.net/scummvm/?rev=55130&view=rev
> Author:   tdhs
> Date:     2011-01-06 00:43:36 +0000 (Thu, 06 Jan 2011)
> 
> Log Message:
> -----------
> SWORD25: Update configure Script to set LUA platform configuration for linux*
> 
> This changes removes the tmpnam warning when building the Sword 2.5 engine.
> This fix sets the top level define which is used by engines/sword25/util/lua/luaconf.h to configure the LUA interpreter build, but only for linux* targets. 
> Other targets may need a similar fix.
> Note : LUA_USE_POSIX is used in preference to LUA_USE_LINUX as this causes another warning associated with the dlopen usage.

Actually, this only hides the tip of the iceberg that is called Lua :/. And in some sense makes things worse...

It shouldn't warn about dlopen -- it shouldn't even *try* to compile any dlopen code. Not portable, takes up extra space, etc. Likewise, the code should not compile in any usage of popen(), and countless other non-portable functions, as has been highlighted on -devel before.

I see two options: We could modify luaconf.h and insert at the top various #defines that disable as many features as possible.
E.g. we don't want LUA_USE_POPEN, no LUA_USE_DLOPEN, no LUA_WIN etc. etc.
In particular, we don't want LUA_USE_POSIX nor LUA_USE_LINUX which enable these and more.

We don't want to call tmpname, either. An alternative way to get the effect on tmpname you want is to set just LUA_USE_MKSTEMP. But we don't want that either!

So, maybe tweaking luaconf.h is not enough. Maybe we should strip away as much code as possible in our copy of lua. Drawback: Makes it difficult to update to a newer Lua later on. But is that a concern? I don't think so...

Except for a brief time after it was merged, I see no activity on the Sword 2.5 engine at all. None to address the various known issues with it, either. It makes me wonder whether it was a good idea to merge it ? *sigh*


Bye,
Max



More information about the Scummvm-devel mailing list