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 ehuels@gmail.com wrote:
Resending in order to get the message on asdf-devel@
On Thu, Apr 4, 2013 at 11:33 PM, Erik Huelsmann ehuels@gmail.com 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?