Problems porting Lua 5 to Symbian/EPOC

[Reuben Thomas <rrt@...>]

I'll start by saying that actually, it was a doddle, especially having
ported Lua 4.

In particular, the feedback I gave about code changes I had to make before
meant that all I had to do was define LUA_API suitably, and add some
casts (these were not added to the Lua code in 5.0 because they're needed
by a broken GCC runtime library on EPOC; I've compiled Lua 4.0 for EPOC
with the excellent epocemx, and not had to change a single line of code).

So once again, I had Lua built as DLLs. Lovely.

Next, the OPX (OPL<->Lua interworking module). This was mostly a matter of
changing the lines which used APIs that are now different, then realising
that upvalue numbering has changed, and sorting that out too. Also easy,
if a little more work than the port itself.

Finally, luac. I couldn't ship luac with Lua 5, for two reasons:

1. It calls functions in liblua which aren't exported. This would be a
problem on Windows too. In Lua 4 I got around it by simply exporting the
necessary functions, but in Lua 5 I was stumped by:

2. It tries to use global variables from lopcodes.c. As I pointed out last
time, you can't export static data from DLLs on EPOC (this used to be a
problem inside liblua) and so this fails.

I don't consider the lack of luac a major problem (in particular, users
desperate for a bytecode compiler can use luac.lua). But it would be nice
to have its decompilation functionality. Can I suggest that at least
point 2 above should be addressed by wrapping up the relevant arrays with
accessor functions. Really, it would be nice to address 1, so that if
LUA_API is correctly defined, luac will build as is.

-- 
http://www.mupsych.org/~rrt/ | maximiste, n.  pessimiste (Roux)