Rework --compile and add a seperate --build option

[dvdvgt]

This issue addresses #254 (and #273).

Changes

In the Runner we now have two methods, build just for building an executable and eval for then evaluating (running) said executable. Furthermore, we now have one new flag in addition to the --compile flag, which also has been reworked.

• The --build flag builds executables when selecting certain backends (LLVM and MLton) instead of only outputting the transpiled code. This option overwrites the --compile option, as the transpiled code is needed for building.
• The --compile flag only outputs (saves) the transpiled code.

Discussion

I am not quite sure how to handle the ChezScheme and JS backend in terms of "building" an executable. Prepending a shebang (#!/usr/bin/env node ...) only works on UNIX systems. Furthermore, this would require more drastic changes to the current implementation, as I would need to edit the pretty-printed output of Compiler.compile in the respective runner, which is currently not available in the Runner.

[b-studios]

Thanks, as for the discussion: I am not sure whether you would need to edit the pretty printed output. It should suffice to prefix it.

However, I think for the JS backend, it would be enough to output a script next to the compiled result (maybe called like a binary would) that contains a shebang and the require(...).main().run() boilerplate.

For Chez, there is an option to create a binary that does WPO and bundles the interpreter. Maybe this one helps: https://github.com/gwatt/chez-exe/blob/master/compile-chez-program.ss

[dvdvgt]

However, I think for the JS backend, it would be enough to output a script next to the compiled result (maybe called like a binary would) that contains a shebang and the require(...).main().run() boilerplate.

Good idea! I will do just that.

For Chez, there is an option to create a binary that does WPO and bundles the interpreter. Maybe this one helps: https://github.com/gwatt/chez-exe/blob/master/compile-chez-program.ss

It seems to be using the compile-whole-program function which does not output a binary but some object file which can be executed by the scheme interpreter just like an .ss file. The actual process of turning that into a standalone executable is a bit more elaborate and goes beyond just executing a reasonable amount of commands in the build function but rather embedding in it custom C code.

[b-studios]

I thought there was a way to automatically generate a binary that also bundles petit, see https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:h8

[dvdvgt]

I thought there was a way to automatically generate a binary that also bundles petit, see https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:h8

Unless I am missing something, it is not possible to create a single standalone binary. See this part of the link you posted:

Here is how we might create and run a simple "echo" application from a Linux shell:
echo '(suppress-greeting #t)' > myecho.ss
echo '(scheme-start (lambda fns (printf "~{a^ ~}\n" fns)))' >> myecho.ss
echo '(compile-file "myecho.ss")
(make-boot-file "myecho.boot" (quote ("petite")) "myecho.so")'
| scheme -q
scheme -b myecho.boot hello world
If we take the extra step of installing a copy of the Petite Chez Scheme executable as myecho and copying myecho.boot into the same directory as petite.boot (or set SCHEMEHEAPDIRS to include the directory containing myecho.boot), we can simply invoke myecho to run our echo application

Tldr: Using this approach, you can only compile a .boot file from a .ss file and then have a copy of the petite executable named like the .boot file beside it. This copy you can then use to execute your program "directly".

Therefore, it is only up to discussion if

1. We simply want to output a simple bash script (with a shebang) calling the scheme interpreter with the transpiled .ss file.
2. Use the aforementioned chez-exe project to create a real standalone binary. With this approach, however, the user has to have yet another program installed in their environment.

[b-studios]

I think it would also suffice to do something similar to the JS solution: compile the ss scheme as much as possible using the documented process. Then put a bash script next to it that just starts it.

[b-studios]

Looks good to me! Feel free to merge (if you have the permission, otherwise I'll do it).

Ideally, we would have some CI to check whether a binary can be created for each backend using build. However, running the backend specific tests probably already covers this?

[dvdvgt]

Ideally, we would have some CI to check whether a binary can be created for each backend using build. However, running the backend specific tests probably already covers this?

Yes, it does. However, only for the platform we run the CI on. So only Linux (Ubuntu) if I am not mistaken. It also "runs on my system" (OSX). Windows will probably be problematic, though.

Looks good to me! Feel free to merge (if you have the permission, otherwise I'll do it).

Hm looks like I do not have permission. I'll just message you when I have implemented your proposed changes and it's ready.

[b-studios]

Windows will probably be problematic, though

Yeah, that's annoying to setup and maintain.

[b-studios]

Thanks @dvdvgt!