Reviewing bundle.lisp

[Robert Goldman]

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