Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Keith Irwin <keith.irwin@gm...> - 2006-03-03 00:24:08
I'm just a sometime Lisp developer and SBCL user, mainly working on
short lived protoypes, etc, etc, so this is just user feedback. I
don't intend to comment on implementation issues.
On 3/2/06, Christophe Rhodes <csr21@...> wrote:
> It has been observed that having little C stubs for the contributed
> modules is actually a barrier to distributing applications based on
> SBCL, because for those applications which depend on contribs with
> alien.so files sbcl will save away the absolute path to those files
> and try to reload them on startup, which won't work terribly well if
> the binary is on a different machine.
Exactly. To get around this I had to, as part of a Makefile
build.lisp strategy, move the alien.so files to my distributable
package hierarchy, push the location onto some sb specific special
variable (I forget which), and then save the image. This worked
nicely, but it took #lisp / sbcl-help to figure this out, and seems a
bit of a hack. Then again, it works and is at the very least
> The attached patch brings the stubs for the contribs into the runtime.
> I'm not desperately happy about this (even disregarding the fact that
> I've just cut-and-pasted the stubs in bodily without thinking about
> it), because it couples the contribs more tightly to the runtime; on
> the other hand, it doesn't couple them too tightly, in that the extra
> stubs in the runtime do no particular harm if they're not used.
No complaints here.
> Of course, this does not solve the general problem of distributing
> binaries which depend on external resources; with this patch, while I
> can distributed a working climacs binary, a gsharp binary fails as it
> tries to open #P"/home/crhodes/lisp/cvs/clnet/gsharp/Fonts/sdl10.gf",
> while anything using mcclim-freetype is similarly likely to fail
> unless the Bitstream Vera fonts are installed in the same place in the
> filesystem. (This is essentially an insoluble problem, right?
My thought was that as long as the saved SBCL image works as far as
SBCL distributed libraries and code are concerned, any extra
dependencies become my problem, not SBCL's. In other words, your
patch solves a problem I have in addition to the basic packaging
problem all software has. If you save the runtime and the core all in
one blob, then you've solved yet another problem as far as packaging
is concerned (imho).
So, for me, since I use Ubuntu, I'd make a deb package which required
the dependencies I have and call that good enough until it's clear
it's not good enough. Since most packages I might depend on place
their files in known locations, and security/fix updates don't change
those locations, then I think things work well.
Same with RPM.
Tarball releases, well, I don't know how people solve that problem
except to just make a huge tarball with all the dependencies included,
as you've mentioned below. (I've done this with an oracle.so.)
> Options include making the users put fonts in the standard locations,
> or else requiring installation of some stuff in the binary package
> into known locations? Is there anything elegant that can turn into a
Not having to worry about, say, sb-bsd-sockets/alien.so, even if it
isn't a total solution, is at least appropriate, at least makes things
one step simpler and cuts out an FAQ.
> Anyway. Comments? Is even this workaround too horrible?
IMHO, I'd think that an IDE with some notion of "Project Management"
should take care of this depending on the deployment platform. No?