<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Well, systems should declare the resources they want packaged into their<br>
> applications in their system files. That's a requirement both ECL and<br>
> ABCL now put forward, but I think other implementations which are able<br>
> to deliver more or less stand alone programs would want the same.<br>
<br>
</div>Updating the ASDF documentation on how to use the new ops as well as<br>
recommendations for ASDF definitions would be good steps in this<br>
direction. When time and resources are available, of course…<br></blockquote><div><br></div><div style>Completely agreed. I'm going to write a blog item about my own use case, but true, there's a lot more to it than just that. </div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> But because "universal distribution" (i.e. for the majority of users of<br>
> a given system) has more-or-less subsumed by Quicklisp, there is no real<br>
> constraint on the developers of system definitions to ensure that all<br>
> components are so enumerated: loading the system from Quicklisp works<br>
> so nothing is broken, right?<br>
><br>> Surely we can add tests for that in cl-test-grid as well?<br>
<br>
</div>Maybe we could implement an ASDF/LINT that checks the "well-formedness"<br>
of a given .asd file, reporting potential problems? Conceptually such<br>
checking needs to be maintained "closer" to ASDF than CL-TEST-GRID.<br>
Implementation is the sincerest form of flattery, of course<br></blockquote><div><br></div><div style>That's not really what I meant, if I understand you correctly. What I meant is: if we can use cl-test-grid to test if libraries load, then we surely can use cl-test-grid to test if a "compiled-and-loaded-from-monolithic-fals" version works. If it doesn't, I'd take that as an indication the ASDF system is broken (that is, if the loader would work for the non-monolithic case).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> And even if one discarded this possiblity, often<br>
> directory hierarchies share multiple ASDF definitions, so one would<br>
> package "source" components that aren't really source components.<br>
><br>
><br>
> I'm sorry, I don't understand this bit. Could you try to explain your<br>
> concern with different words?<br>
<br>
</div>Think of the ABCL-TEST-LISP definition in abcl.asd: it only references<br>
files in the test/lisp/abcl sub-directory.</blockquote><div><br></div><div style>That's fine. In this case, the current ASDF system builder includes only the lisp files it knows about.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, if one one were to treat<br>
the pathname of the .asd file it is defined in, one would include the<br>
abcl Java source, possibly the build artifacts, etc. which is probably<br>
not what one wants.</blockquote><div><br></div><div style>Right, so I'm not arguing we should include "everything below the system file". I'm saying that system definitions can use #. macros to include files dynamically into the system definition and once that definition is compiled and packed, there's no need to evaluate the #. macro anymore so, loading off a monolithic fasl is still a viable option.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Or consider CFFI with the cffi-ffi.asd definition,<br>
which needs one specific subdirectory.</blockquote><div><br></div><div style>True. Isn't it the case that those subdirectories are currently included using reader conditionals? I'm assuming we're not cross-compiling systems for ABCL on SBCL here. I have a feeling I'm not understanding you on this point. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> So, assuming that "deployment outside of Quicklisp from an ASDF<br>
> definition" would be a greater good for the community, we seem to be<br>
> stuck at a bootstrap problem. I can't think of a way to force ASDF<br>
> authors to enumerate their static components, but until such enumeration<br>
> is widespread, I can't demonstrate its utility by developing an<br>
> ASDF/BUNDLE operation.<br>
><br>
> Well, there is no need to develop the ASDF/BUNDLE operation: Fare did.<br>
> Buth other than that, the fact that I can now succesfully package<br>
> bordeaux-threads which we couldn't with ASDF-JAR, I think this is really<br>
> a step ahead?<br>
<br>
</div>Conceptually, it sounds like a step ahead but how do I use it. Could<br>
you write up a quick document on how to use it? I'm still not sure how<br>
things like ASDF:SYSTEM-RELATIVE-PATHNAME would work in the monolithic<br>
fasl scenario, so I would like to get my hands dirty a bit here.<br></blockquote><div><br></div><div style>I'm not certain with respect to this point. Lets ask Fare about that :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> [I actually started writing this mail bottom to top, so what's below may<br>
> be a reiteration...]<br>
><br>
> Well, the great thing about the solution that Fare has now rolled out is<br>
> that I was able to package and load Bordeax-threads even though it is<br>
> problematic because it uses the #. reader macro and does not include the<br>
> version.lisp-sexp in the ASDF definition...<br>
><br>
> The infrastructure I've added to ABCL has been hooked up into ASDF with<br>
> his new release. Much more doesn't seem to be required to get it all<br>
> correctly packaged. Package providers can simply use #. reader macros to<br>
> inject the list of :static-files they need to be distributed with their<br>
> code and asdf will pick it up. We'll need to work and test ASDF + ABCL<br>
> to see if everything works as intened though.<br>
<br>
</div>And then deprecate ASDF-JAR?</blockquote><div><br></div><div style>Only if that's the right thing to do in the sense that ASDF-JAR's functionality has been subsumed into ASDF3's build facility. However, I don't think we need to: it's a contrib in its own right until it's broken and nobody can be motivated to unbreak it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In some ways, I thought that being able to<br>
present ABCL components as jar files (abcl.jar, abcl-contrib.jar,<br>
hunchentoot-all-1.2.14.jar) would be a more natural fit to typical Java<br>
server deployment scenarios.</blockquote><div><br></div><div style>Well, the only difference betweer a FASL and a JAR is the MANIFEST file... I'm sure we can come up with a way to make the .abcls look like jars or even turn them into real ones. However, if there's a file called "my-application--systems.jar", why </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Other than this more natural fit to JVM<br>
deployments (whereby the pointy-headed boss would be none-the-wiser as<br>
"everything just looks like jar dependencies") the only advantage of<br>
using a jar format that still might exist would be to leverage the ["One<br>
Jar" approach][one-jar] to actually use a custom classloader to make JVM<br>
artifacts (libraries, resources, etc.) packaged in the deployment as<br>
well. With this sort of approach we could include the jna.jar needed<br>
for CFFI in the deployment artifact, as opposed to needing to override<br>
going for the resolving the Maven dependency at deployment runtime.<br>
<br>
[one-jar]: <a href="http://one-jar.sourceforge.net/" target="_blank">http://one-jar.sourceforge.net/</a><br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div></div></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>Bye,</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
Erik.</div><div class="gmail_extra"><br></div></div>