Re: Issue compiling for vxWorks

[Keith Wiles <kwiles@...>]

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,
--Keith