(defmethod mark-operation-done :after ((o load-bundle-op) (c system)) (mark-operation-done (find-operation o 'load-op) c)))
Thanks for explaining that. That said, can you explain why we do this, instead of marking load-bundle-op as done? I guess because loading the bundle is intended to be equivalent to loading the system, so that if we load a bundle for a system, S, we want other systems that depend on S to know that it has been loaded.
It's in addition, not instead of, and considering how asdf 3 works as opposed to 1 & 2, it's probably not effective unless you recurse for all dependencies.
Related to this, the first parameter to FIND-OPERATION is described as a "context," but there's nowhere an explanation of what a context is meant to be and in what way another operation can be a context.
find-operation once made sense, back when I was trying to support the crazy and actually buggy ASDF 1 behavior (notably used by asdf-ecl) of carrying extra build information in operation objects. This was definitely deprecated last year in ASDF 3.2 or 3.3, although 3.3 also opened the way to doing it in a non-buggy way in the future if you want. I don't recommend that: it will be super complex to get right for little short-term benefit; but you may have to it or something just as hard, anyway, if you want to properly support cross-compilation, for instance.
What you do with find-operation depends on your long-term plans. You could get rid of the context and use make-operation everywhere instead — that's what the current implementation does, anyway (it used to try to preserve the operation initargs, even though component-operation-times used to drop them).
I read this as "find an operation by making it. Ignore the context argument." So I'm not entirely sure why it exists (presumably because it's idempotent, and MAKE-OPERATION is not), or why it has the context argument. I guess that you foresaw the need for a context at some point, but never ended up using it?
The context used to be (from ASDF 1, before refactoring into find-operation) another operation from which you extracted the initargs. In the future, it might be reborn, after some kind of canonicalization, for e.g. optimization settings, cross-compilation, etc.. Or that context could be moved to a different object — but that would mean a new API incompatible with the current one for ASDF extensions. Cross-compilation will require something somewhat backward-incompatible, anyway.
As I said above, I don't yet understand why that method exists, so I don't know what would be the implications of removing it.
I believe that before ASDF 3, this method was intended hat you could indeed load a bundle and the system would therefore assume that the system is loaded and not recurse into loading the individual files of the bundle. This is definitely not working anymore (if it ever did) — you'd have to recursively mark all objects as loaded with a suitable timestamp. Also, considering that ECL abandoned the idea of a *load-system-operation* (which that was supporting), the point of it is moot. I recommend either recursing or removing the method over hushing the warning. Note that, in the context of upgrade, removing the method requires conditionally defining an empty method (or using the MOP to remove it) in a suitable when-upgrading form.
Yes, we could make that dependency warning into a defined condition and muffle it in this context. I just need to understand a little better the implications of doing that.
My current recommendation would be to just remove the method: wrap it in when-upgrading with proper version spec, and empty out its body.
So, even after the last email, I'm inclined to hold up a release until I understand this bug and kill it.
Good luck.
A lot of ASDF is historically-motivated cruft. Just like CL itself.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a centralized society social status is a zero-sum game along a single hierarchy. That's why politics can never help the weak, only swap roles.