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.

E.g.,
"Foo/input-test"
"Foo/processing-test"
... 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?


Best,
R

On 6 Feb 2019, at 10:52, Hugo Ishimaru wrote:

Hi,

when I read your post, I instantly came up with the system that may
not be the target of OPERATE like
;; foo.asd
;; https://gist.github.com/privet-kitty/84350b73d528533ac8e19e5bba6aa333
(defpackage :foo.asdf
  (:use :cl :asdf :uiop)
  (:export #:hideable-system))
(in-package :foo.asdf)

(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)
&key &allow-other-keys)
    (if (private-p component)
        (error "Private system ~S cannot be directly operated."
(component-name component))
        (call-next-method))))

(defsystem "foo"
  :license "public domain"
  :depends-on ("foo/private")
  :components ((:file "main")))

(defsystem "foo/private"
  :pathname "private"
  :class "FOO.ASDF:HIDEABLE-SYSTEM"
  :private t
  :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, asdf:component-depends-on, etc.
https://gitlab.common-lisp.net/asdf/asdf/blob/master/doc/best_practices.md

Anyway, I don't have a sufficient knowledge on ASDF's internal.


Robert P. Goldman
Research Fellow
Smart Information Flow Technologies (d/b/a SIFT, LLC)

319 N. First Ave., Suite 400
Minneapolis, MN 55401

Voice:  (612) 326-3934
Email:    rpgold...@sift.net

Reply via email to