Creating a Lisp Executable | Hacker News Reader

Creating a Lisp Executable

stackoverflow.com

73 pointsalrex02120 comments

Open articleView on HN

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/

> 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? ;-)

I gotta update those docs...

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.

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.

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?

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.

> On my mac, applications are really directories with lots of stuff inside. Why insist on stuffing everything into a single file?

Actually, the executable is still a single file. The directory just contains things that would be shoved into /usr/share on Linux or into a DLL on Windows, such as the icon, metadata, any other assets (game levels, images, etc.) and runtime libraries.

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/

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.

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

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

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?

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.

That's a lot more reasonable, thanks.

I've been trying various approaches to this problem myself but haven't converged on the best cross platform solution yet:

* http://www.aerique.net/software/etotp/ (needs a nice index page)

* http://github.com/aerique/okra (see examples)

The Lispbuilder-SDL people have been working on this as well:

* http://code.google.com/p/lispbuilder/wiki/StandAloneExecutab...

If I could spare the money I'd try out LispWorks (you'd have to pay for each seperate platform IIRC).

I partly agree with the size considerations but only for mobile platforms. What's 20mb for a normal machine?

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.

> 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.

My Common Lisp (SBCL) isn't interpreted; everything you type in the REPL is compiled before running it. And there aren't many hoops to jump through to make an easily distributed executable with buildapp for SBCL.

Chicken Scheme:

csc app.scm ./app

Not really a problem with interpreted languages, it's just that it may not be as common in some worlds.

In DrRacket: Racket > Create Executable... > Distribution. Done.

Reply on news.ycombinator.com