I think the approach of disabling operate is not a good solution to this
problem because, for example (this is one I have actually encountered),
one might have multiple test systems that one wishes to test separately.
... and so on.
So I think it's better to handle this in a way that focuses on
Quicklisp, and indexing, rather than attempting to change the core
functions of ASDF. It's just as easy to create a system class that
simply says "I am a system that Quicklisp should not build."
Unfortunately, there has been enough bad blood between Xach and some
members of the ASDF-devel community that this discussion won't be
reaching him. Jim, Hugo, either of you want to try to be a conduit?
On 6 Feb 2019, at 10:52, Hugo Ishimaru wrote:
when I read your post, I instantly came up with the system that may
not be the target of OPERATE like
(:use :cl :asdf :uiop)
(eval-when (:compile-toplevel :load-toplevel :execute)
(defclass hideable-system (system)
((private :initform nil :initarg :private :reader private-p))
(:documentation "If PRIVATE is true, ASDF signals an error when
one tries to OPERATE this system."))
(defmethod operate :around (operation (component hideable-system)
(if (private-p component)
(error "Private system ~S cannot be directly operated."
:license "public domain"
:components ((:file "main")))
:components ((:file "package")))
Here FOO/PRIVATE cannot be OPERATEd (but can be PERFORMed and then
loaded, compiled, tested etc. via FOO). It seems to work at least
superficially, though ASDF Best Practices states:
You SHOULD NOT define methods on asdf:operate --- most of the time
it's totally the wrong thing
because users would not be "operating" on your system, but on their
system that depends on it.
Instead you SHOULD define methods on asdf:perform,
Anyway, I don't have a sufficient knowledge on ASDF's internal.
Robert P. Goldman
Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400
Minneapolis, MN 55401
Voice: (612) 326-3934