Translate luac.c into as a seperate consolec.c application
Closed this issue · 8 comments
Compiling lua isn't part of LuaConsole, but sure as heck could be.
Although, I have NO IDEA how breaking it would be to compile a lua51 application in a lua53 compiler for a lua51 dll. I haven't gone through any of the files for comparison.
Here are relevant files
lua535 compiler.zip
lua524 compiler.zip
lua515 compiler.zip
License https://github.com/tilkinsc/LuaConsole/blob/master/Lua%20LICENSE
I think I rather have it as a part of LuaConsole and enforce a naming standard. Therefore on files loaded, it would select the correct lua version due to the input files based on extension, which can be disabled or overid by -w.
The sources are complex enough for me to not really understand what they are doing and I think adding in the sources and using preprocessor to determine which to use with a function that would glue the appropriate functions into the system would be the best, most compatible way to go. Much like jitsupport.c/h
So I converted them into easy to read files at https://github.com/tilkinsc/LuaCButActuallyLegible
What I learned that is I can take the executable luac, and link it with one of the generated lua libraries that LuaConsole compiles. This way, I can just make the luac a dll and call functions from it, while also removing unneeded content from it if desired. I can keep the original code, use it just like any user, bypassing the pmain and main (by removing them due to multi def errors) and implement my own function which interfaces with each of them cross binary-ly. Genius.
Admittedly, I haven't studied the luajit luac, so I might have to modify jitsupport, which is not a big deal.
So the prime target is the pmain.
So each main function is called to order the args and pass an array of files, which index 0 in argv would be the switch -c (aka exclude the file name) and argc modified to account for this exclusion. Basically (char*) argv++ and (int) argc--. Lua then invokes pmain using lua_pcall with arguments of the modified argc and argv.
So all we really care about is the pmain which does all the processing of args. So I don't really want to modify luac.c as that wouldn't be portable. I had to take an alternative step by using an extern int pmain(lua_State*) and objcopy -N main --globalize-symbol pmain luac.o due to multidef on the main and the fact pmain was defined static.
Now I can send pmain a -c and a list of arguments. This is compatible with all the major versions of lua in use currently.
So I looked at luajit. It appears that it indeed doesn't have an external C util, but uses the -b switch. This will prove useful as I can just coin a luajit hack to submit an arg properly on -c switch when using luajit.
One problem I have run into is compiling luac as -O2 optimizes out doargs, which I can't call thereof. So I can't use the hack I've been using unless I compile specifically all but luac.c. This is a real bummer, but I guess I can fall back to actually renaming and calling the main function, which invokes pmain. Since it's self contained, it really isn't much of a problem, as it would be always targeting the correct version loaded. This also avoids the problems I would have in creating the main myself.
What I am actually concerned about now is the ability to do it in MSVS using CL. I don't know if its possible, I will have to dig up answers.
Ok so I did just that. Turns out it now can be called like this,
luaw -c [luac args] [lua files]
Which may look like
luaw -c - # for stdin
luaw -c res\testing.lua # for file
luaw -c -v # for version
luaw -v -c -v # text spam
msvs is proving difficult.
msvs problem was resolved. So when you use /EXPORT: option for CL you can do /EXPORT:luac_main=main to swap the symbol name. The gcc code was retained.
All done