This is a very nice tool which packs a whole Lisp project (for SBCL) with SBCL in a single executable file.
http://www.xach.com/lisp/buildapp/
Ok... some considerations: first, I rather hate the idea of needing to package things that way. The world is not Windows, luckily enough. However, it has its uses. Like giving the program to someone who does not have common lisp installed. Second, the whole thing becomes well above 40 MB. It appears that this is a well known problem with SBCL.
Now, I should absolutely try ECL. Here a short of a tutorial.
And an example from my sources; it looks like we are starting to reason:
% ecl
ECL (Embeddable Common-Lisp) 10.4.1
;; snip
> (compile-file "life.lisp" :system-p t)
;; output
> (c:build-program "life" :lisp-files '("life.o"))
;; output
#P"life"
% ls -lh life
-rwxr-xr-x 1 enrico staff 16K Jan 13 00:07 life
This looks reasonable. Perhaps some Lisp commercial compiler can do better. And I have just forced myself to stop translating the thing in Scheme to see how Gambit fares. Maybe one of these days some benchmarks. Maybe not.
However, I keep asking myself: when we will stop asking ourselves to build standalone executables? I am not even sure it makes deployment easier. For sure it is not the way Java undertook: as far as I know jars are distributed, but the bulk of the JVM is not bundled with the application. When we are dealing with desktop applications, a .app or .exe or 755 is nice to have, but it does not to be a standalone executable, IMO.
I don't even want to know how many years it is since someone invented shared libraries. The single executable route seems so wrong. Right now the only times I had to do that was to give a program to my girlfriend (with Lisp, Python she has installed) or to some non-geek friends. I think that happened like 3 times in the last 7 years. I am even more in the who cares position. However, it is nice to have. Sure I'm missing something, though.
http://www.xach.com/lisp/buildapp/
Ok... some considerations: first, I rather hate the idea of needing to package things that way. The world is not Windows, luckily enough. However, it has its uses. Like giving the program to someone who does not have common lisp installed. Second, the whole thing becomes well above 40 MB. It appears that this is a well known problem with SBCL.
Now, I should absolutely try ECL. Here a short of a tutorial.
And an example from my sources; it looks like we are starting to reason:
% ecl
ECL (Embeddable Common-Lisp) 10.4.1
;; snip
> (compile-file "life.lisp" :system-p t)
;; output
> (c:build-program "life" :lisp-files '("life.o"))
;; output
#P"life"
% ls -lh life
-rwxr-xr-x 1 enrico staff 16K Jan 13 00:07 life
This looks reasonable. Perhaps some Lisp commercial compiler can do better. And I have just forced myself to stop translating the thing in Scheme to see how Gambit fares. Maybe one of these days some benchmarks. Maybe not.
However, I keep asking myself: when we will stop asking ourselves to build standalone executables? I am not even sure it makes deployment easier. For sure it is not the way Java undertook: as far as I know jars are distributed, but the bulk of the JVM is not bundled with the application. When we are dealing with desktop applications, a .app or .exe or 755 is nice to have, but it does not to be a standalone executable, IMO.
I don't even want to know how many years it is since someone invented shared libraries. The single executable route seems so wrong. Right now the only times I had to do that was to give a program to my girlfriend (with Lisp, Python she has installed) or to some non-geek friends. I think that happened like 3 times in the last 7 years. I am even more in the who cares position. However, it is nice to have. Sure I'm missing something, though.
2 comments:
Interesting post and nice tool, Rik0. May I suggest to have a look to Lispbuilder? It seems a nice tool too!
Bye!
Alfredo
Interesting, indeed. Seems a different bunch of software, doesn't it?
Post a Comment