Add qjsc -r flag to output raw bytecode

[TooTallNate]

I want to allow users to ship a raw .jsc bytecode file for faster bootup times.

[saghul]

How will you handle handle bytecode incompatibility?

Edit, hit enter too fast. Bytecode generated by a given version of QJSC need not be compatible with previous or further versions of the engine. There is a BC version we bump when we make changes to the way bytecode is (de)serialized.

I support the approach, but I worry people are going to run into problems because this incompatibility is not obvious...

[TooTallNate]

How will you handle handle bytecode incompatibility?

QuickJS already throws a syntax error, so on the technical level I'm not sure what else would need to be done: https://github.com/quickjs-ng/quickjs/blob/07fa1cbc4a8938085a716051c0f14a3453a885fb/quickjs.c#L35116-L35120

Socially, I plan on shipping an emscripten-compiled version of qjsc with my runtime, so the user code would always be compiled against the same quickjs version as the runtime itself. I suppose implementors might want to come up with their own approaches.

[saghul]

Sounds reasonable. We can also look into the syntax error message and make it more helpful if need be as well.

[saghul]

Why don't you make the output type a static variable at the top of the file and simplify this? There is already precedent with things like outfile and strip and then you don't need to shove it in there

[TooTallNate]

02dfbac

[chqrlie]

There is a problem: the output file must be open in binary mode to output the raw bytecode:

    if (output_type == OUTPUT_RAW)
        fo = fopen(cfilename, "wb");
    else
        fo = fopen(cfilename, "w");

This is necessary for legacy architectures with end-of-line translation and other obscure text mode conversion schemes.
I would have also preferred -b (--bytecode) over -r for this option.