4 ms·

From [0]: "Most Common Lisp implementations support creating native-format executable files. The typical route involves loading all of the program's code into

by mc3 7y ago

From [0]: "Most Common Lisp implementations support creating native-format executable files. The typical route involves loading all of the program's code into the Lisp environment, dumping the current state of the Lisp process into a disk image, and identifying a start function (ie main). Since the disk image contains the entire Common Lisp system (compiler, debugger, documentation strings, etc.), the executable will be typically larger than a compiled C program (even if you statically link the C code). Another form of disk image requires a copy of the particular Lisp implementation to be installed on the recipient's machine. This is no different in principle from a C application requiring platform-specific dynamic libraries to run. This complicates deployment - the disk image is tied to a particular implementation version, and you typically end up having to include the Lisp implementation executable anyway. Due to platform limitations, some Lisp implementations can't produce native executables (for example, ABCL can only make JAR files). Other implementations are only able to dump disk images that require a separate copy of the implementation executable. An alternative to executables is available on Unix platforms in the form of shell scripting." If it needs 4 wordy paragraphs and you still don't know how to do it, I am going to scribe that up as non-trivial. [0] https://www.cliki.net/Creating%20Executables https://www.cliki.net/Creating%20Executables

earenndil 7y ago
You don't need those 4 paragraphs. I have this alias in my .zshrc: clc() { sbcl --no-userinit --load $1 --eval "(sb-ext:save-lisp-and-die \"$(sansext $1)\" :toplevel 'main :executable t)" } Sansext is a custom function that strips the file extension from a filename, but you don't need that; you can read output filename from $2, or whatever else.
- mc3 7y ago
  Nice. I think it is important for proponents of languages to answer FAQs like this so you aren't left in a corner when you want do so something (i.e build & distribute) that is standard in most languages.
lispm 7y ago
That's because different implementations provide different ways to generate executables. Some are simple, some are complex. For SBCL one needs to call a function, which creates the executable image. http://www.sbcl.org/manual/index.html#Function-sb_002dext-save_002dlisp_002dand_002ddie http://www.sbcl.org/manual/index.html#Function-sb_002dext-sa... There are more complex machineries for application generation, though.

by mc3 7y ago

earenndil 7y ago

You don't need those 4 paragraphs. I have this alias in my .zshrc: clc() { sbcl --no-userinit --load $1 --eval "(sb-ext:save-lisp-and-die \"$(sansext $1)\" :toplevel 'main :executable t)" } Sansext is a custom function that strips the file extension from a filename, but you don't need that; you can read output filename from $2, or whatever else.

mc3 7y ago
Nice. I think it is important for proponents of languages to answer FAQs like this so you aren't left in a corner when you want do so something (i.e build & distribute) that is standard in most languages.

lispm 7y ago

That's because different implementations provide different ways to generate executables. Some are simple, some are complex. For SBCL one needs to call a function, which creates the executable image. http://www.sbcl.org/manual/index.html#Function-sb_002dext-save_002dlisp_002dand_002ddie http://www.sbcl.org/manual/index.html#Function-sb_002dext-sa... There are more complex machineries for application generation, though.