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
