[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Problems porting Lua 5 to Symbian/EPOC
- From: Reuben Thomas <rrt@...>
- Date: Tue, 3 Jun 2003 00:08:13 +0100 (BST)
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)