lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi David,

Thanks for your input, but I do have some comments about them below.

David Given wrote:
On Tuesday 24 January 2006 21:51, Keith Wiles wrote:
I am having a problem compiling Lua 5.1-rc2 under vxWorks for an
embedded target (the type of target should not matter).

Ooh, VxWorks. I had to deal with that once. I'm sorry.

/* vxWorks does not use 'main' in kernel builds (RTPs is another issue),

The problem here is that lua.c isn't really part of the Lua core. The Lua core provides the Lua *library*. lua.c is merely an example front-end, which provides a simple command-line shell to the Lua language.

It's expected that users implement their own front-end in a way suitable for their particular task. For example, games won't use lua.c at all. What I'd do in your situation is to take your own copy of lua.c and hack it yourself.
The lua.c file is used a lot and to say it is not part of the Lua core is the wrong thing to say here. The lua.c file drops nicely into most designs with only one change, all I had to do was rename 'main' to provide a command line for an embedded product to be able to execute Lua scripts. I would guess a fair number of design use this file. If the lua.c was not updated or dropped from the tar ball I bet you would hear about it from a lot of people and because it is included we have to look at the issues with the file.

But the real point is I did have to edit one of the core files 'ldo.c' to get it to compile in one of the largest embedded RTOS in the world. I do not see the harm in moving the include of "lua.h" to above the standard includes, unless someone tells me it breaks everything in the world. You could argue that vxWorks is broken, but I believe other embedded systems will have a similar problem.

Lua was designed for embedded systems or embedding into another application not just for Linux, Windows or Unix OS systems as a standalone tool. Lua is a perfect fix for any size embedded device and many companies are looking for a better solution then Tcl or Python for these devices.
<<Sorry, I will get off the Soap box now.>>
In ldo.c and lua.c move the include of "lua.h" (which includes
luaconf.h) to before the standard includes to allow the vxWorks.h header
to be included before any standard headers.

Are you sure this is necessary? The Lua core is standard C, and should compile on pretty much everything. If VxWorks truly requires vxWorks.h to be included before things like stdlib.h will work, then VxWorks is majorly broken.
As I stated you can call vxWorks header requirement broken, but I believe it is not broken. The reason is vxWorks compiles and cross compiles to a large number of CPUs, which means some basic environments need to be setup before some standard header files get includes. When cross compiling you do not have the ability to always use the Host OS includes and must use headers files for the given target(s). These header files setup limits and some basic defines which need to be used by the rest of the header files.

I am not try to defend vxWorks header files, but it is what it is and we have to live with it until someone builds a better system.
BTW, I am not using the standard Lua makefiles
as the IDE (Wind River modified Eclipse IDE)

Hurrah! They finally threw away that... er, lovely proprietary IDE they wrote
I agree the old Tcl based IDE was worthless for most engineers.

Does this issue deserve any attention?

Thanks again for reading,