It would be great to put NuttX special build files to apps/interpreters folder after you finish the port, so other people can benefit from your work and improve it in the future. For the code change, I would suggest that: 1. If the api called by 3rd party is very common in other Unix variants but NuttX is not implemented or the implementation is wrong, it's better to improve NuttX instead of hacking the 3rd party code. 2. If the api is hard to implement in NuttX(e.g. fork), but there is a more portable way to write the same functionality(e.g. posix_spawn/pthread_create), it's better to make a common change not specific to NuttX.(e.g. https://gitlab.com/libssh/libssh-mirror/-/merge_requests/174). 3.The last resort is to add __NuttX__ around the broken code. Last, it's better to upstream your change to NuttX and 3rd party community, so both sides can maintain and improve your change in the long term.
On Thu, Jun 10, 2021 at 5:58 PM Flavio Castro Alves Filho < flavio.al...@gmail.com> wrote: > > > > We really ought to talk to the Lua team and see if we can upstream the > > changes. Unsupported ports in NuttX don't have good shelf life. > > > > I believe that one of the reasons is that Lua's major use case is to > be embedded inside applications, isn't it? > > I don't know if Lua is used so much as a replacement for bash, perl or > python .. > > In this case, maybe a document explaining how to add on a project > could be enough :-| > > Best regards, > > Flavio >
