Commit 3bc52526 authored by Christophe Rhodes's avatar Christophe Rhodes
Browse files

Be a little bit more defensive about looking up classes for component


It seems regrettably common for system authors, despite the
documentation, to place their system in CL-USER, where the user can
quite legitimately add symbols.  Adjust the lookup code in
CLASS-FOR-TYPE to ignore symbols not naming subclasses of
ASDF:COMPONENT, and also to try the symbol itself first if it's not
a keyword.  Also adjust the documentation slightly to make this slightly

Add test files, and make the clisp test-harness work for me.
parent d6c42afd
$Id: README,v 1.38 2004/07/19 21:18:07 crhodes Exp $ -*- Text -*-
$Id: README,v 1.39 2006/08/21 10:52:32 crhodes Exp $ -*- Text -*-
The canonical documentation for asdf is in the file asdf.texinfo.
The significant overlap between this file and that will one day be
......@@ -117,9 +117,10 @@ the grunt work.
asdf is extensible to new operations and to new component types. This
allows the addition of behaviours: for example, a new component could
be added for Java JAR archives, and methods specialised on
compile-op added for it that would accomplish the relevant
be added for Java JAR archives, and methods specialised on compile-op
added for it that would accomplish the relevant actions. Users
defining their own operations and component types should inherit from
the asdf base classes asdf:operation and asdf:component respectively.
* Inspiration
......@@ -478,7 +479,9 @@ package is created for them to load into, so that different systems do
not overwrite each others operations. The user may also wish to (and
is recommended to) include defpackage and in-package forms in his
system definition files, however, so that they can be loaded manually
if need be.
if need be. It is not recommended to use the CL-USER package for this
purpose, as definitions made in this package will affect the parsing
of asdf systems.
For convenience in the normal case, and for backward compatibility
with the spirit of mk-defsystem, the default contents of
;;; This is asdf: Another System Definition Facility. $Revision: 1.100 $
;;; This is asdf: Another System Definition Facility. $Revision: 1.101 $
;;; Feedback, bug reports, and patches are all welcome: please mail to
;;; <>. But note first that the canonical
......@@ -112,7 +112,7 @@
(in-package #:asdf)
(defvar *asdf-revision* (let* ((v "$Revision: 1.100 $")
(defvar *asdf-revision* (let* ((v "$Revision: 1.101 $")
(colon (or (position #\: v) -1))
(dot (position #\. v)))
(and v colon dot
......@@ -946,11 +946,16 @@ system."))
(defun class-for-type (parent type)
(let ((class
(or (find-symbol (symbol-name type) *package*)
(find-symbol (symbol-name type) #.(package-name *package*)))
(let* ((extra-symbols (list (find-symbol (symbol-name type) *package*)
(find-symbol (symbol-name type)
#.(package-name *package*))))
(class (dolist (symbol (if (keywordp type)
(cons type extra-symbols)))
(when (and symbol
(find-class symbol nil)
(subtypep symbol 'component))
(return (find-class symbol))))))
(or class
(and (eq type :file)
(or (module-default-component-class parent)
......@@ -35,5 +35,5 @@ fi
if [ -x /usr/bin/clisp ]
do_tests "/usr/bin/clisp -norc -ansi -I " fas
do_tests "/usr/bin/clisp -norc -ansi -I - " fas
;;; NB: This way of managing packages is explicitly NOT recommended.
;;; However, it is found in the wild, and debugging it is a pain, so
;;; we should probably not break. The thing that this is testing is
;;; that unrelated definitions of symbols naming ASDF keywords should
;;; not affect the parsing of a system.
(in-package :cl-user) ; BAD BAD BAD
(asdf:defsystem test-package
:components ((:module "foo" :components ((:file "bar") (:file "baz")))))
\ No newline at end of file
(in-package :cl-user)
(load "../asdf")
(defun module () 1)
(load "test-package.asd")
(defclass module () ())
(load "test-package.asd")
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment