how to distinguish public vs private (entry-point vs internal) systems
Hugo Ishimaru
privet.kitty99 at gmail.com
Wed Feb 6 16:52:33 UTC 2019
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.
More information about the asdf-devel
mailing list