Re: portability lessons

[Reuben Thomas <rrt@...>]

> We would like to hear your comments and stories about compiling Lua in "strange"
> platforms and "strange" compilers, how much had to be changed in Lua, how much
> was a compiler's limitation, etc. Stories about not-so-strange platforms and
> compilers are ok too of course.

Here's the EPOC story: the best news is that it's very short. The only
significant problems were DLLizing the entry points (same as on
Windows, because I was compiling the libraries into DLLs), and getting
rid of static data (EPOC's fault for not allowing static data in
DLLs). There were one or two places where Lua had unnecessary static
data; after reporting these they were cured.

I had no compiler-related problems, which is unsurprising, since I was
cross-compiling with GCC.

The message is: Lua is pretty darned good in this respect, it's become
better as a result, and it has moved from the realm of the merely ANSI
to being "super-portable": perhaps you could write up some of these
lessons too, although also perhaps there aren't too many people
interested in that level of portability.

One system I do know of that is is bzip2, which was written to be as
purely ANSI as possible (and has indeed been ported to a zillion
platforms pretty easily). It, like Lua, doesn't use the usual tricks
of ./configure &c. which eases portability among Unices, but hampers
it elsewhere. www.bzip2.org, I think. I just asked him, and he seemed
not to have any portability problems over and above strict ANSI (other
than having to deal with file permissions, which is outside the scope
of ANSI).

-- 
http://sc3d.org/rrt/ | romantic, n.  one who puts ideas before people