On 11:43 Sun 16 Oct , Faré wrote:
So BUNDLE-SYSTEM has been restored, but the comment about its deprecation suggests that we should revisit its arglist to make it useful, if we are not going to remove it.
My "no-operation-initargs" branch, that you (Robert) agreed to merge after the next release, does away with bundle-system.
The function is not documented, and reading the code doesn't help me (as someone who doesn't routinely use bundle ops): it defers to DELIVER-ASD-OP, but that operation is documented as:
"produce an asd file for delivering the system as a single fasl"
which suggests that it makes a .asd file, and doesn't bundle anything at all.
It uses compile-bundle-op (née fasl-op) to create a single .fasl for the entire system, then also creates a .asd file that will load that .fasl file. But there is no good place to store that .asd file least it overwrites the source .asd file, and no good place to store the .fasl file besides the per-implementation fasl cache. The whole interface is lacking, and is not directly usable as is, though it isn't too hard for users to write a wrapper that copy or redirect the output where they want it to be, using deliver-asd-op directly and querying asdf:output-files. Thus, the function has no purpose and should be removed.
I currently use compile-bundle-op and deliver-asd-op (in fact expect a bugfix soon) for creating read-only loadable systems for Nix (I previously tried just managing the output translations but found it to get too hairy; with the bundles no changes to the output translations are necessary).
Are these two operations here to stay?
-Jason