There were various ways I could have gone with this, in the end however I decided with the old KISS method of haivng the startup app get the enviroment into a sane state and call a specific script and have that take over the application from that point onwards.
I toyed with a couple of ways of doing things;
- via 'require' so that the startup script is loaded into a table and a specific funtion is called. This does have the nice side effect of allowing C libs to also be startup programs as well as a search path being applied to finding the script but in the end I decided no.
- using an XML file to indicate where the startup script should be found and have the application sweap subdirectories for XML files. While making mod-ing easier and a possible consideration for later I decided against it for now.
- loading a script and calling a specific funtion to start things once it's all done. This, combined with the XML, is probably a long term goal as it would allow me to pass things down to the Lua script from the C++ program (such as the program path for PhysFS when it's intergrated, as it's required on Linux), but right now I can do without
- load a script, run it and let it take over. Yeah, nice and simple.
To that end the whole program is only 45 lines long, including white space.
// Startup.cpp : Defines the entry point for the console application.
// Lua support functions
void registerLib(lua_State *L,const std::string &name, lua_CFunction f)
void openLuaLibs(lua_State *L)
int _tmain(int argc, _TCHAR* argv)
lua_State *L = luaL_newstate();
lua_pcall(L, 0, LUA_MULTRET, 0);
The idea being that 'startup.lua' includes the required files and functions in order to take on execution once called.
Untested, I'll get around to that at some point tomorrow probably.