[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Porting lua to a embeded platform
- From: Ico Doornekamp <lua@...>
- Date: Tue, 20 May 2008 09:26:12 +0200
* 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