<div dir="ltr">Hi all,<div><br></div><div><br></div><div style>Some years ago, Mark wrote ASDF-JAR; a solution to package ASDF systems and their dependencies in JARs.</div><div style><br></div><div style>As it turns out, the solution chosen has some problems with correctly packaging ASDs for systems which use the #. reader macro. As an example: bordeaux-threads uses a version.lisp-sexp file to canonically define the version number and the system definition reads that file in a #. form. However, this file isn't packaged because it's not part of the file listing in the system definition. This means asdf can't load the definition after deployment.</div>
<div style><br></div><div style>With the advent of ASDF3, its developers have created infrastructure to combine fasls of a single system and even fasls of a  system and all its dependencies into a single large combined FASL. Among others, this new infrastructure does not run into the issue ASDF-JAR is running into. While not completely equivalent to the JAR solution, using this infrastructure would help us a huge step along that way of getting better deployment. My current thinking is that if the single-packed-FASL needs to end up as a jar, we can work on that as a next step.</div>
<div style><br></div><div style>The first step to take would be to create "concatenate fasls" functionality, which would do the following:</div><div style><br></div><div style> * Detect all the file entries in all the passed-in fasls</div>
<div style> * Create a new output zip file with directories for each fasl being packed, populated with the files and directories of that fasl</div><div style> * create a toplevel ._ file which loads the sub-fasls' ._ files</div>
<div style><br></div><div style><br></div><div style>Comments?</div><div style><br></div><div style>Bye,</div><div style><br></div><div style><br></div><div style>Erik.</div></div>