how to distinguish public vs private (entry-point vs internal) systems
rpgoldman at sift.info
Thu Feb 7 17:40:20 UTC 2019
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
> ;; foo.asd
> (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))
> (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.
> 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
Email: rpgoldman at SIFT.net
More information about the asdf-devel