I have been making my first experiments with the bundle operations, to try to get a better understanding of this corner of ASDF.
One thing I see in the new documentation is the following:
(defclass bundle-op (basic-compile-op) + ;; NB: use of instance-allocated slots for operations is DEPRECATED + ;; and only supported in a temporary fashion for backward compatibility. + ;; Supported replacement: Define slots on program-system instead. ((build-args :initarg :args :initform nil :accessor extra-build-args) (name-suffix :initarg :name-suffix :initform nil) (bundle-type :initform :no-output-file :reader bundle-type) - #+(or clasp ecl) (lisp-files :initform nil :accessor extra-object-files))) + #+(or clasp ecl) (lisp-files :initform nil :accessor extra-object-files)) + (:documentation "base class for operations that bundle outputs from multiple components"))
I think this is worth a discussion, before we get it set in stone. I can see two reasons why putting this in the system definition ("slots on program-system)" instead of in the operation might not be desirable:
1. It violates "the Faré principle" of the person who knows getting to specify. The programmer of the system doesn't know where the user wants the bundle delivered, but by putting this information in the system definition, it's the programmer, not the user, who gets to choose. Compare this with the way output translations work, where it's the user who chooses, not the developer. Another analogy: it's like "make install" without PREFIX.
2. This makes things cumbersome when you have a system that has the same codebase, but multiple different entry points. Consider a compression program that uses the same codebase, but wants to deliver 2 different executables, "squish" (compress) and "unsquish" (decompress). If we have the build destination hard-coded into the system definition, this is impossible. I was just experimenting with such a case myself, and ended up with a main system and 4 "slashy" systems, one for each entry point. Not a disaster, but not obviously a Good Thing, either.
OTOH, putting slots on operations is a nuisance, because then we need to propagate those slot-values from operations to derived operations.
I think it would be good to ponder this issue a bit.
Cheers, r