* On 2008-05-20 chunlin zhang <zhangchunlin@gmail.com> wrote :
Many of the C runtime lib api could not be used in this platform
especially "stdio.h",i.e.: malloc/free/realloc printf/fprintf
fopen/fread/fwrite/fclose remove/rename/tmpfile(the platform have its
own file system api with UTF16 string parameter)
That's a nasty platform you've got there.
I spent 1 night to compile lua into the platform. And spent 2 day to
run "hello world"(using luaL_dostring) in the PC emulator. Spent 3
day to run "hello world" in mobile phone,because found that I should
get rid of the C runtime api not support in the platform.
And now I want to run lua script from file(using luaL_dofile),and
found that I should rewrite luaL_loadfile and so on with platform
utf16 string file system api.I think I will spend more days...
Have anyone else ever done this kind of porting?Or any advice to me...
I think there are generally two ways of porting Lua to a platform like
yours: one is to just start compiling, find where the build breaks, and
modify the Lua code to use your platform-specific API instead of the
standard C library functions. This is a lot of work, and in the end
leaves you with a severely modified Lua implementation, which will not
make future updates any easier.
The other (and IMHO preferred way) would be to leave the Lua source
(mostly) unmodified, and implement the missing C library functions
needed to get Lua up and running on a glue layer on top of your
platform's API. Most of these C library functions aren't too hard to
build on top of another filesystem (fopen/fread/fwrite, etc), and for
the harder functions like [vs]printf() you might get away with
implementing only a stub or part of the functionality.
What method did you use for your Lua port ?
--
:wq
^X^Cy^K^X^C^C^C^C
