Nice! I wish creating Lua executables were this easy. With Lua you have to create a wrapper C file, use squishy to combine multiple lua files into one, and finally a script to turn the lua script into a C byte array. I have a boilerplate project that I use so that I just have to run `make`, that avoids the need to ever touch C for the most part. But it would be nicer if luac and luajit did this automatically.
No, I'm saying that you can't. You create a wrapper main.c file that loads and executes the lua. I use a script that tranlates the lua into a C byte array so that I can avoid loading the external lua scripts.
> Do you do this so that the users have a harder time modifying the code (just curious)? I'm supposing that this is the case otherwise it would work pretty well with by using the lua or luajit interpreter and some wrapper bash/cmd.exe script to run your lua file(s).
No, I do it to avoid having to worry about where the .lua scripts are located. Having a single binary is nicety, not required of course.
I think that's what he meant -- that ignoring the small wrapper part --which is boilerplate--, you can deliver a binary that's basically lua.
With a little search I found out UPX and it seems to be working with many unix binary formats too.. http://upx.sourceforge.net/
edit: If so I've been doing it wrong for years.
[−4] ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_24.html
1 - create the object files (with luajit?)
2 - create a main() in c.. use "extern" to reference the external symbol in the .o files and call it from main.
The symbols in the object files produced by luajit or whatever need to be exported/ visible.. (are they mangled?)
3 - create a object file for main.c
4 - link the .o created from luajit(or whatever, dart?) and main.o together
If the linker cant find the external symbol it wont link to a binary (so you need to know how, in what names they are exported.. use objdump to lookup for symbols)
This file is an amalgamation of many separate C source files from PH7 version 2.1.
By combining all the individual C code files into this single large file, the entire code
can be compiled as a single translation unit.This allows many compilers to do optimization's
that would not be possible if the files were compiled separately.Performance improvements
are commonly seen when PH7 is compiled as a single translation unit.
The "typical" solution to that very valid problem is to use the preprocessor, i.e. create a "ph7-master.c" file that simply includes all the real C files.
The comparative overhead of should be negligble, but then the modularization survives.