Creating a Lisp Executable

http://stackoverflow.com/questions/25046/lisp-executable

by alrex021 • 16 years ago

73 20 16 years ago

JeanPierre• 16 years ago

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.

zachbeane3• 16 years ago

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• 16 years ago

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

zachbeane3• 16 years ago

I gotta update those docs...

jcw2• 16 years ago

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

aerique2• 16 years ago

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

jcw2• 16 years ago

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?

aberkowitz• 16 years ago

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.

zachbeane3• 16 years ago

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.

thecombjelly• 16 years ago

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.

Xurinos• 16 years ago

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

dchest• 16 years ago

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

astine2• 16 years ago

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• 16 years ago

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?

astine2• 16 years ago

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.

xorglorb• 16 years ago

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

jmatt• 16 years ago

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• 16 years ago

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.

Creating a Lisp Executable

Related Stories