[asdf-devel] Question about defsystem

Robert Goldman rpgoldman at sift.info
Mon Jun 7 02:18:30 UTC 2010


I was just looking over Scott's bugreports and I am wondering a bit
about a snippet in defsystem:

(defmacro defsystem (name &body options)
  (destructuring-bind (&key (pathname nil pathname-arg-p) (class 'system)
                            defsystem-depends-on &allow-other-keys)
      options
    (let ((component-options (remove-keys '(:defsystem-depends-on
:class) options)))
      `(progn
         ;; system must be registered before we parse the body, otherwise
         ;; we recur when trying to find an existing system of the same name
         ;; to reuse options (e.g. pathname) from
         ,@(loop :for system :in defsystem-depends-on
             :collect `(load-system ,system))
         (let ((s (system-registered-p ',name)))
***        (cond ((and s (eq (type-of (cdr s)) ',class))
                  (setf (car s) (get-universal-time)))
                 (s
                  (change-class (cdr s) ',class))
                 (t
                  (register-system (quote ,name)
                                   (make-instance ',class :name ',name))))
           (%set-system-source-file (load-pathname)
                                    (cdr (system-registered-p ',name))))
         (parse-component-form
          nil (list*
               :module (coerce-name ',name)
               :pathname
               ,(determine-system-pathname pathname pathname-arg-p)
               ',component-options))))))

Look at the cond that's starred -- the first and third branches both
cause the DEFINED-SYSTEMS entry for NAME to be updated to the current
value of GET-UNIVERSAL-TIME.  But the *second* branch does not seem to
(unless it happens by some complex chain as a side-effect of CHANGE-CLASS).

Can anyone explain why we shouldn't update the DEFINED-SYSTEMS entry in
the case where S already exists but of a different type?  Or does this
happen as a side-effect of CHANGE-CLASS?

Perhaps this is worthy of a comment....

best,
r




More information about the asdf-devel mailing list