
Creating a Lisp Executable - alrex021
http://stackoverflow.com/questions/25046/lisp-executable
======
zachbeane
I wrote Buildapp for SBCL to make this a little easier and command-liney. I
use it all the time.

<http://xach.com/lisp/buildapp/>

~~~
sdp
> By design, it does not handle the following tasks:

> ...

> Obtaining libraries (use clbuild, LibCL, cl-librarian, asdf-install, etc.
> for that)

I imagine one could also use QuickLisp for libraries? ;-)

~~~
zachbeane
I gotta update those docs...

------
JeanPierre
For CLisp on Windows, one should also put the DLL-files from Base/Full within
same directory. For base-users, this means libiconv-2.dll, libintl-8.dll and
readline5.dll. For Full, this means zlib1.dll (if you're using it), pcre.dll
and svm.dll. Windows usually complain about not finding these, so for
portability you should keep them there.

------
astine
Yes, this is the thing that probably most annoys people coming from languages
like C about Lisp. Producing a standalone executable is non-obvious, and
different from implementation to implementation. Commercial implementations
make this simple, but generally, folks learning the language aren't using
commercial implementations. It's funny though when you realize that it's not
any harder than Java or a scripting language.

~~~
jwr
I've always wondered why this problem only seems to be raised wrt Lisp. I
mean, do you get people wanting to create Python executables or Ruby
executables?

Also, what is an executable anyway? On my mac, applications are really
directories with lots of stuff inside. Why insist on stuffing everything into
a single file?

~~~
astine
Well, not all of us run a Mac. Python and Ruby are both advertised as
'interpreted' languages and most programmers realize that what you do with
them is write a script, which you then feed into a Python or Ruby interpreter.
Many Lisp implementations are advertised as compiled and when people think of
compiled languages, they think of C, C++, Paschal, or any one of dozens of
languages where you write a program, feed it to a compiler (either through a
build tool or straight) and you end up with an executable file that you can
double click on or type in at the command line. When I first started with Lisp
I expected something similar, and was surprised.

Lisp isn't really designed with either the standard interpreted language
workflow, or the standard compiled language workflow, in mind. It's workflow
is actually superior in a low of ways, but it's non-obvious to non-lispers how
to make a deliverable.

Actually, it's a huge problem in some ways, as there is no standard way of
delivering OSS Lisp software on Linux, or Unix systems. The few OSS Lisp
projects there are usually really on the presence of a specific Lisp
implementation and bundle any Lisp dependencies in themselves, which when you
are familiar with how the rest of the Linux/Unix OSS community is usually
packaged and delivered, feels really inefficient. One case in point is
StumpWM, a Lisp based Linux window manager that gained some interest a while
back. It was actually pretty neat, but there were at least three or four ways
to install it and none meshed completely with whatever packaging system your
distro was using. I can tell you with some certainty that that hurt its
adoption compared to tiled window managers written in C.

I could go on, And deal with everything you said, but I'll stop here. It think
it's suffice to say, Lisp is different and people haven't figured out how to
reconcile Lisp with their expectations (right or wrong) or the rest of the
world.

------
jmatt
In clojure/lein[1][2] it's simple enough though not really equivalent to a
real executable:

    
    
      lein uberjar
    

That'll create a standalone jar. But, of course, the computer will need some
sort of JRE.

This definitely reminds me of creating executables in python. Even though
python really isn't a lisp it has seemingly crazy, difficult and under-
developed and underutilized ways to create executables.. somewhat surprising
considering how popular it is today[3].

[1] See <http://clojure.org/>

[2] See <https://github.com/technomancy/leiningen>

[3] Long list ... all have pluses and minuses <http://www.py2exe.org/>
<http://pypi.python.org/pypi/py2app/> <http://www.pyinstaller.org/>
<http://pypi.python.org/pypi/bbfreeze/0.97.2> <http://cx-
freeze.sourceforge.net/>

~~~
aristus
I've published a couple of multiplatform Python executables (dowser.sf.net,
archivd) and setting those up (+ installers) sucked weeks of my time. It's
pretty terrible.

------
jcw
The one thing that's made me apprehensive of using CL for a project.

~~~
aerique
Depends on the project. For most of them you wouldn't need to build an
executable.

~~~
jcw
I understand that. If you're making software for yourself, for a business, for
deployment on a web server, or for fellow hackers, it's not an issue. However,
if you want to make end-user software (games, for example), you don't want to
require the user to have a CL installed, or have an executable with a 20mb
overhead (see XONG and other games written in CL). Is that more reasonable
than what I said earlier?

~~~
jules
Is 20mb overhead really that bad these days? I'm on a 5 year old computer and
currently have more than a gigabyte of free memory.

------
aberkowitz
Interpreted programming languages (especially ones with a REPL) are great for
their low barrier of entry. However, once someone wants to make an easily
distributable executable, they have to jump through numerous hoops.

The only exception to this problem are VMs which are often clunky and
restricted to code precompiled for a specific version of a VM. I would like to
see more solutions to this dilema, examples of which can be seen in py2exe and
pyinstaller, for Python.

Edit: This is a general thought, and not a dig against Lisp. It is made clear
by Stack Overflow answers that many implementations of Lisp have easy ways to
make executables which are well documented.

~~~
Xurinos
> they have to jump through numerous hoops

In clisp and sbcl (I do not have a lot of experience with other
implementations), the "make this an executable binary" command is a one-liner,
so the hoops are at least comparable to other languages.

It occurs to me that every language that has a binary deploy has extra hoops,
depending upon what you want. For example, you have to make sure that you use
the right flags on gcc to debug your code with debugging symbols (not the
default) or use "tail call optimization". No, actually it is worse: serious C
projects have large, ugly Makefiles with optimization parameters, dependent
library libs specified, dependent library include paths, etc etc. It is so
ugly that several systems have been written for the singular purpose of
creating a Makefile just so that your little Gtk App can compile. And C is a
language people consider to be a real language that compiles stuff. :)

The hoops are not limited to languages with a REPL.

