Hi,
Some time ago, I created infrastructure to be used by ASDF to compile an ASD definition file's resulting FASLs into a single artifact. Things like #.(read-some-file) in the ASD definition will work as well. If there are load-time or runtime forms referring to the original source tree, they won't, because the link to the source tree gets severed.
Unfortunately, I can't remember the name of the ASDF transform I implemented this for. What I do remember is that the resulting fasl can be loaded with a simple LOAD command, so ASDF won't be needed in the resulting image.
Regards,
Erik.
On Wed, Nov 19, 2014 at 9:28 AM, Mark Evenson evenson@panix.com wrote:
On 17 Nov 2014, at 21:46, Robert Dodier robert.dodier@gmail.com wrote:
On 2014-11-17, Mark Evenson evenson@panix.com wrote:
- ASDF systems which do not declare all their source code necessary
to run
within the ASDF grammar don’t package according to this method.
How would I know if this is the case? Can I inspect the .asd file and see if something is present or absent?
Essentially, you know if it doesn’t work upon testing. Ensuring that you can inspect the output of a non-nil CL:*LOAD-VERBOSE* can help in determining what exactly is happening. Manual inspection of ASDF definitions for use of [SHARPSIGN-DOT macros with open files such as in BORDEAUX_THREADS][1] gets most of the common errors. Whether such a process could ever be automated is open to debate, but I tend to believe not.
- Using the jar for the pre-compiled fasls does not work with the
current
incarnation of ASDF. Instead, upon first use of the source packaged in
the
jar, ASDF will compile the fasls according to its output translations
logic.
Hmm, are the fasls then written into the jar? or they are just sitting in $HOME/.asdf-cache-something/something/something?
The FASLs are under control of the [ASDF output translation mechanism][2], which in its default configuration places compiled files under file:~/.cache/common-lisp/IMPLEMENTATION/** where ‘IMPLEMENTATION’ is a directory name derived from the implementation that ASDF is running under.
Do you have an absolute need to load the pre-compiled FASLs from the
jar, or
can you take the hit of compilation on first use coupled with the
requirement
that the user have a writable home directory for your deployment
scenario?
Well, my goal is load Maxima into a webapp (as managed by Jetty or Tomcat). (By the way, if you have seen such a thing, I'd be interested to hear about it.) So I don't know if it's crucial to load fasls from the jar -- I had assumed that the webapp could only load stuff from jars available to the webapp container, but maybe that's not so.
Surprisingly, for both Tomcat and Jetty, there are actually no restrictions on where the webapp can load/save files other than those that result from the user they are running under. The Java Servlet documentation would have you believe otherwise, the APIs to get such access are not immediately apparent, and other servlet containers may have tighter restrictions, but [abcl-servlet][3]--my putative framework for making ABCL Java Servlet instances--serves as the bare scaffolding for such usage. abcl-servlet is not currently exhaustively documented, but if you clone the basic app, get it to build the abcl-servlet.war, you should be able to make a barebones ABCL webapp that you can connect to via SLIME for further experimentation. Feedback on improvements to the process is solicited.
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel