asdf:fasl-op is more reliable than the current abcl-jar at collating fasls, but doesn't even try to get other files. I'd like to see a future where abcl-jar relies on fasl-op for the fasl part, maybe even binary-op for producing an according .asd for precompiled stuff, and otherwise collects whatever other files need to be included (a tricky question).
In other words, I think that both abcl-jar and asdf:fasl-op are useful, and they should be evolved to complement each other rather than try to subsume each other. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reality must take precedence over public relations, for Mother Nature cannot be fooled. — R.P. Feynman On Thu, Apr 4, 2013 at 6:05 PM, Erik Huelsmann <[email protected]> wrote: > Resending in order to get the message on asdf-devel@ > > On Thu, Apr 4, 2013 at 11:33 PM, Erik Huelsmann <[email protected]> wrote: >> >> Hi, >> >> >> Today Mark and I were discussing the new ASDF3 capabilities which should >> help with deployment: the monolithic-fasl-op, binary-op and others. >> >> While I do see lots of potential for the monolithic fasl op for code-only >> deployment situations, Mark and Anton brought up scenarios where a system >> may consist of code and resources. The code may choose to access such >> resources at run time through the use of the SYSTEM-RELATIVE-PATHNAME >> facility. >> >> Because I don't have an immediate answer myself yet (I'm just now learning >> about this facility), I'm directing our discussion to asdf-devel@. How do >> see this scenario? _______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
