lua.c is the source to build the stand-alone Lua interpreter. luac.c is the source to build the standalone Lua compiler, to pre-compile scripts to bytecode. They don't include any error checking that would be important for any kind of game engine, although it might be useful to study so that you can see what kind of error checking they do perform and see if it might be useful to include such in your own project. But a lot of what they perform mostly has to do with parsing command-line arguments on startup, so if you are not planning on interacting much with your game via command-line args then you don't need that.

Lua is a simple enough library to work with. It doesn't include any outside dependencies, it's small and lightweight enough that you don't necessarily have to build it as a library if you don't want, etc... You can just include any .c file that doesn't include it's own main() directly into your project.

However, I highly recommend building Lua as a .DLL. Why? Because LuaJIT, that's why. If Lua is built as a DLL, the LuaJIT DLL can be swapped in without any troubles whatsoever. Just copy and paste the DLL to your executable folder. And LuaJIT is a pretty neat thing to have access to, if performance is important. (Which, in a game, it is.) Including the Lua source into the engine itself means that developers who use your engine can't just simply drop LuaJIT in if they so desire.

Yeah, you can treat Lua.c as basically being an example application that makes use of the Lua library in order to create a command line interpreter.

Regarding LuaJIT, I've just included the LuaJIT source directly into my engine project (so I've the opposite situation - end users can't choose to swap over to the official Lua version).

Regarding LuaJIT, I've just included the LuaJIT source directly into my engine project (so I've the opposite situation - end users can't choose to swap over to the official Lua version).

I see nothing wrong with this...

LuaJIT is great, as it is just another implementation of Lua that obeys their specifications exactly, but it has much better performance. Even if you disable the "JIT" part (where it compiles your Lua scripts into native CPU instructions), it's still faster than Lua due to large parts of it having been hand-optimized.

However, the down-side is that because it's so optimized, it's source code is barely readable, unless you're also an optimization expert. This isn't a problem in normal usage, but if you use any API illegally (e.g. pass it bad pointers, etc), then you can make that API crash internally. If you make LuaJIT crash internally, it will be hard to debug, whereas with regular Lua, you might get a bit more useful debugging info, like call-stacks etc...

Once you've got Lua working fine, you can pretty much just replace your Lua source files with the LuaJIT source files and everything will still work the same.