It looks like it invokes the compiler every time the script is run? That's nice if you've changed the file, but takes extra time if you haven't. It seems neat at first, but I guess I don't see the advantage over just compiling to an executable and then running that.
I don't want to spam the link, but I actually just posted a top-level comment to a version of this I published back in 2020 that does caching and cache invalidation, using the hash of the script as the key for the compiled output path.
EDIT:
Actually, that was how the original version worked, but it had the limitation that once the script changed you could no longer determine the path to the previous executable output to delete, so you could end up accumulating a lot of defunct binaries. Now the hash is stored alongside the target.
Comments
It looks like it invokes the compiler every time the script is run? That's nice if you've changed the file, but takes extra time if you haven't. It seems neat at first, but I guess I don't see the advantage over just compiling to an executable and then running that.
I don't want to spam the link, but I actually just posted a top-level comment to a version of this I published back in 2020 that does caching and cache invalidation, using the hash of the script as the key for the compiled output path.
EDIT:
Actually, that was how the original version worked, but it had the limitation that once the script changed you could no longer determine the path to the previous executable output to delete, so you could end up accumulating a lot of defunct binaries. Now the hash is stored alongside the target.
There was some mention in the wiki about caching the result and rebuilding it on change, so it seems well thought out from that perspective.
it does some dependency checking, so no compiler invocation if the source isn't changed, the binary is cached