Re: Porting lua to a embeded platform

[Chunlin Zhang <zhangchunlin@...>]

Ico Doornekamp wrote:
> * 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.
Yes.It is not a open platform.Porting lua is my effort to improve its 
scalability.
> > 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.
Any code using the C runtime lib api can be compile in this platform.But
 i.e. the call of "malloc/free" make the mobile phone can not boot 
normally,and I don't know why exactly.So I get rid of all the code cause 
the linking of "malloc/free"(i.e. printf ...).There may be more api can 
not use other than "malloc/free",I even write a tool to analyze which 
exactly more functions are linking  then the version have not lua source.

I simply delete the code call those runtime api now().And replace some 
with my implement version(i.e. printf).So I am using your first method.

> 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 ?