Add a cosmopolitan build

[MulverineX]

https://github.com/jart/cosmopolitan

The cosmo version of qjsc would build to .com cosmopolitan binaries

[saghul]

I think it should be easy to add to the CI and to the release job. Would you be willing to send a PR?

The cosmo version of qjsc would build to .com cosmopolitan binaries

What do you mean by this?

[MulverineX]

I'm not really all that experienced with this, I just suggested this because upstream has a cosmo build.

What do you mean by this?

Meaning, instead of qjsc building a standalone executable from a script for a given platform, it would build for cosmo

[saghul]

Got it, it was on my mental list too.

Our qjsc doesn't build binaries, it just generates C files that the user can compile however they see fit.

[MulverineX]

Ah okay, so a user would just take that c file and compile it with Cosmo, great!

[chqrlie]

Our qjsc doesn't build binaries, it just generates C files that the user can compile however they see fit.

qjsc does build binaries in the bellard/quickjs project. Removing this possibility on the targets where it is easy is a regression. Compiling the generated C file manually is not so straightforward. We should reactivate this feature. qjsc would still generate the C file with the -c command line option.

[saghul]

It's not portable at all (perhaps except with cosmo) since it assumes a given compiler and platform, and it calls exec and other Unix-only functions.

The way Deno does it would be nice perhaps: take the qjs executable and add the compiled bytecode as trailing data. Then when qjs is run, it scans itself for some magic value and if found it executes that bytecode and skips the normal CLI run.

[chqrlie]

The resulting executable is not portable across architectures or portable only to a limited set of targets (with cosmo), but on many architectures (linux, BSD, macOS) it can be run on a variety of versions of said targets, which is still useful.

[saghul]

I respectfully disagree :-) My proposal above would accomplish the same, I reckon, without even having to call the compiler. Deno has been using it succesfully roo, FWIW.

[chqrlie]

One does not preclude the other. There are multiple options to create standalone executable files:

• prepending a #! line on unix targets (this requires installing the qjs executable and make the implementation obvious)
• appending the source code to the qjs interpreter is a possibility and could be a simple option (this does not hide the implementation)
• compiling to bytecode and appending that to qjs is simple and does hide the implementation (albeit reverse engineering can still be performed, but not easily)
• compiling to bytecode and embedding in a custom built executable, as is done in qjsc directly or via separate compilation creates smaller executables that may load faster. This is somewhat of a technical prowess and not so useful anymore in a time of global resource wastage and extravagant software bloat.

Creating an executable from the qjs runtime and the bytecode file with a simple tail signature as in .zip files is indeed a good idea. In fact, it could be implemented inside qjs itself at a minimal cost.

[saghul]

I think 1 and 2 would be similar unless we strip the source when byte-compiling, right? Assuming we don't, they'd be equivalent, from the prespective of stack traces and such.

I'll give that idea a try when I find some time. Still have some pending reviews 😅

[saghul]

An additional benefit from appending the data to the qjs binary would also be that one could realistically take some binary from another platform and make it standalone, no need to cross-compile!

[chqrlie]

Implementing this inside qjs itself seems feasible at minimal cost and trivially simplifies access to the qjs runtime :)

Loading the bytecode from an external source such as an executable for a different platform solves the portability issue (for a given byte code version).