<html lang='en'>
<head>
<meta content='text/html; charset=utf-8' http-equiv='Content-Type'>
<title>
GitLab
</title>
</meta>
</head>
<style>
img {
max-width: 100%;
height: auto;
}
p.details {
font-style:italic;
color:#777
}
.footer p {
font-size:small;
color:#777
}
pre.commit-message {
white-space: pre-wrap;
}
.file-stats a {
text-decoration: none;
}
.file-stats .new-file {
color: #090;
}
.file-stats .deleted-file {
color: #B00;
}
</style>
<body>
<div class='content'>
<h3>Raymond Toy pushed to branch master at <a href="https://gitlab.common-lisp.net/cmucl/cmucl">cmucl / cmucl</a></h3>
<h4>
Commits:
</h4>
<ul>
<li>
<strong><a href="https://gitlab.common-lisp.net/cmucl/cmucl/commit/d1032f697247e13d2c6d91a66b98c6b347cadd57">d1032f69</a></strong>
<div>
<span>by Raymond Toy</span>
<i>at 2015-10-17T23:38:04Z</i>
</div>
<pre class='commit-message'>Update to ASDF 3.1.6.</pre>
</li>
<li>
<strong><a href="https://gitlab.common-lisp.net/cmucl/cmucl/commit/1d034d24f6c87575de73422e32cdca5501d37ef5">1d034d24</a></strong>
<div>
<span>by Raymond Toy</span>
<i>at 2015-10-17T23:39:14Z</i>
</div>
<pre class='commit-message'>Update documentation for asdf 3.1.6.</pre>
</li>
</ul>
<h4>4 changed files:</h4>
<ul>
<li class='file-stats'>
<a href='#diff-0'>
src/contrib/asdf/asdf.lisp
</a>
</li>
<li class='file-stats'>
<a href='#diff-1'>
src/contrib/asdf/doc/asdf.html
</a>
</li>
<li class='file-stats'>
<a href='#diff-2'>
src/contrib/asdf/doc/asdf.info
</a>
</li>
<li class='file-stats'>
<a href='#diff-3'>
src/contrib/asdf/doc/asdf.pdf
</a>
</li>
</ul>
<h4>Changes:</h4>
<li id='diff-0'>
<a href='https://gitlab.common-lisp.net/cmucl/cmucl/compare/b239ce3f44b62821701e3447437705d3d914a5b4...1d034d24f6c87575de73422e32cdca5501d37ef5#diff-0'>
<strong>
src/contrib/asdf/asdf.lisp
</strong>
</a>
<hr>
<pre class="highlight"><code><span style="color: #000000;background-color: #ffdddd">--- a/src/contrib/asdf/asdf.lisp
</span><span style="color: #000000;background-color: #ddffdd">+++ b/src/contrib/asdf/asdf.lisp
</span><span style="color: #aaaaaa">@@ -1,5 +1,5 @@
</span> ;;; -*- mode: Common-Lisp; Base: 10 ; Syntax: ANSI-Common-Lisp ; buffer-read-only: t; -*-
<span style="color: #000000;background-color: #ffdddd">-;;; This is ASDF 3.1.5: Another System Definition Facility.
</span><span style="color: #000000;background-color: #ddffdd">+;;; This is ASDF 3.1.6: Another System Definition Facility.
</span> ;;;
;;; Feedback, bug reports, and patches are all welcome:
;;; please mail to <asdf-devel@common-lisp.net>.
<span style="color: #aaaaaa">@@ -3327,15 +3327,19 @@ NILs."
</span> (defun lisp-implementation-directory (&key truename)
"Where are the system files of the current installation of the CL implementation?"
(declare (ignorable truename))
<span style="color: #000000;background-color: #ffdddd">- #+(or clasp clozure ecl gcl mkcl sbcl)
</span> (let ((dir
<span style="color: #000000;background-color: #ffdddd">- (ignore-errors
- #+clozure #p"ccl:"
- #+(or clasp ecl mkcl) #p"SYS:"
- #+gcl system::*system-directory*
- #+sbcl (if-let (it (find-symbol* :sbcl-homedir-pathname :sb-int nil))
- (funcall it)
- (getenv-pathname "SBCL_HOME" :ensure-directory t)))))
</span><span style="color: #000000;background-color: #ddffdd">+ #+abcl extensions:*lisp-home*
+ #+(or allegro clasp ecl mkcl) #p"SYS:"
+ ;;#+clisp custom:*lib-directory* ; causes failure in asdf-pathname-test(!)
+ #+clozure #p"ccl:"
+ #+cmu (ignore-errors (pathname-parent-directory-pathname (truename #p"modules:")))
+ #+gcl system::*system-directory*
+ #+lispworks lispworks:*lispworks-directory*
+ #+sbcl (if-let (it (find-symbol* :sbcl-homedir-pathname :sb-int nil))
+ (funcall it)
+ (getenv-pathname "SBCL_HOME" :ensure-directory t))
+ #+scl (ignore-errors (pathname-parent-directory-pathname (truename #p"file://modules/")))
+ #+xcl ext:*xcl-home*))
</span> (if (and dir truename)
(truename* dir)
dir)))
<span style="color: #aaaaaa">@@ -4033,15 +4037,17 @@ Finally, the file will be deleted, unless the KEEP argument when CALL-FUNCTION'e
</span> (check-type direction (member :output :io))
(assert (or want-stream-p want-pathname-p))
(loop
<span style="color: #000000;background-color: #ffdddd">- :with prefix = (native-namestring
- (ensure-absolute-pathname
- (or prefix "tmp")
- (or (ensure-pathname directory :namestring :native :ensure-directory t)
- #'temporary-directory)))
- :with results = ()
</span><span style="color: #000000;background-color: #ddffdd">+ :with prefix-pn = (ensure-absolute-pathname
+ (or prefix "tmp")
+ (or (ensure-pathname directory :namestring :native :ensure-directory t)
+ #'temporary-directory))
+ :with prefix-nns = (native-namestring prefix-pn)
+ :with results = (progn (ensure-directories-exist prefix-pn)
+ ())
</span> :for counter :from (random (expt 36 #-gcl 8 #+gcl 5))
:for pathname = (parse-native-namestring
<span style="color: #000000;background-color: #ffdddd">- (format nil "~A~36R~@[~A~]~@[.~A~]" prefix counter suffix type))
</span><span style="color: #000000;background-color: #ddffdd">+ (format nil "~A~36R~@[~A~]~@[.~A~]"
+ prefix-nns counter suffix (unless (eq type :unspecific) type)))
</span> :for okp = nil :do
;; TODO: on Unix, do something about umask
;; TODO: on Unix, audit the code so we make sure it uses O_CREAT|O_EXCL
<span style="color: #aaaaaa">@@ -4050,6 +4056,7 @@ Finally, the file will be deleted, unless the KEEP argument when CALL-FUNCTION'e
</span> ;; Can we at least design some hook?
(unwind-protect
(progn
<span style="color: #000000;background-color: #ddffdd">+ (ensure-directories-exist pathname)
</span> (with-open-file (stream pathname
:direction direction
:element-type element-type
<span style="color: #aaaaaa">@@ -4129,8 +4136,13 @@ Further KEYS can be passed to MAKE-PATHNAME."
</span> :defaults pathname keys))
(defun tmpize-pathname (x)
<span style="color: #000000;background-color: #ffdddd">- "Return a new pathname modified from X by adding a trivial deterministic suffix"
- (add-pathname-suffix x "-TMP"))
</span><span style="color: #000000;background-color: #ddffdd">+ "Return a new pathname modified from X by adding a trivial random suffix.
+A new empty file with said temporary pathname is created, to ensure there is no
+clash with any concurrent process attempting the same thing."
+ (let* ((px (ensure-pathname x))
+ (prefix (if-let (n (pathname-name px)) (strcat n "-tmp") "tmp"))
+ (directory (translate-logical-pathname (pathname-directory-pathname px))))
+ (get-temporary-file :directory directory :prefix prefix :type (pathname-type px))))
</span>
(defun call-with-staging-pathname (pathname fun)
"Calls FUN with a staging pathname, and atomically
<span style="color: #aaaaaa">@@ -4148,7 +4160,6 @@ For the latter case, we ought pick a random suffix and atomically open it."
</span> (defmacro with-staging-pathname ((pathname-var &optional (pathname-value pathname-var)) &body body)
"Trivial syntax wrapper for CALL-WITH-STAGING-PATHNAME"
`(call-with-staging-pathname ,pathname-value #'(lambda (,pathname-var) ,@body))))
<span style="color: #000000;background-color: #ffdddd">-
</span> ;;;; -------------------------------------------------------------------------
;;;; Starting, Stopping, Dumping a Lisp image
<span style="color: #aaaaaa">@@ -4293,9 +4304,7 @@ This is designed to abstract away the implementation specific quit forms."
</span> (dbg:*debug-print-length* *print-length*))
(dbg:bug-backtrace nil))
#+sbcl
<span style="color: #000000;background-color: #ffdddd">- (sb-debug:backtrace
- #.(if (find-symbol* "*VERBOSITY*" "SB-DEBUG" nil) :stream '(or count most-positive-fixnum))
- stream)
</span><span style="color: #000000;background-color: #ddffdd">+ (sb-debug:print-backtrace :stream stream :count (or count most-positive-fixnum))
</span> #+xcl
(loop :for i :from 0 :below (or count most-positive-fixnum)
:for frame :in (extensions:backtrace-as-list) :do
<span style="color: #aaaaaa">@@ -5048,73 +5057,62 @@ INPUT, OUTPUT and ERROR-OUTPUT specify a portable IO specifer,
</span> to be normalized by %NORMALIZE-IO-SPECIFIER.
It returns a process-info plist with possible keys:
PROCESS, EXIT-CODE, INPUT-STREAM, OUTPUT-STREAM, BIDIR-STREAM, ERROR-STREAM."
<span style="color: #000000;background-color: #ffdddd">- ;; NB: these implementations have unix vs windows set at compile-time.
</span><span style="color: #000000;background-color: #ddffdd">+ ;; NB: these implementations have Unix vs Windows set at compile-time.
</span> (declare (ignorable directory if-input-does-not-exist if-output-exists if-error-output-exists))
(assert (not (and wait (member :stream (list input output error-output)))))
<span style="color: #000000;background-color: #ffdddd">- #-(or allegro clisp clozure cmu (and lispworks os-unix) mkcl sbcl scl)
</span><span style="color: #000000;background-color: #ddffdd">+ #-(or allegro clasp clisp clozure cmu ecl (and lispworks os-unix) mkcl sbcl scl)
</span> (progn command keys directory
(error "run-program not available"))
<span style="color: #000000;background-color: #ffdddd">- #+(or allegro clisp clozure cmu (and lispworks os-unix) mkcl sbcl scl)
</span><span style="color: #000000;background-color: #ddffdd">+ #+(or allegro clasp clisp clozure cmu ecl (and lispworks os-unix) mkcl sbcl scl)
</span> (let* ((%command (%normalize-command command))
(%input (%normalize-io-specifier input :input))
(%output (%normalize-io-specifier output :output))
(%error-output (%normalize-io-specifier error-output :error-output))
<span style="color: #000000;background-color: #ffdddd">- #+(and allegro os-windows) (interactive (%interactivep input output error-output))
</span><span style="color: #000000;background-color: #ddffdd">+ #+(and allegro os-windows)
+ (interactive (%interactivep input output error-output))
</span> (process*
<span style="color: #000000;background-color: #ffdddd">- #+allegro
- (multiple-value-list
</span><span style="color: #000000;background-color: #ddffdd">+ (nest
+ #+clisp (progn
+ ;; clisp cannot redirect stderr, so check we don't.
+ ;; Also, since we now always return a code, we cannot use this code path
+ ;; if any of the input, output or error-output is :stream.
+ (assert (eq %error-output :terminal)))
+ #-(or allegro mkcl sbcl) (with-current-directory (directory))
+ #+(or allegro clasp clisp ecl lispworks mkcl) (multiple-value-list)
</span> (apply
<span style="color: #000000;background-color: #ffdddd">- 'excl:run-shell-command
- #+os-unix (coerce (cons (first %command) %command) 'vector)
- #+os-windows %command
- :input %input
- :output %output
- :error-output %error-output
- :directory directory :wait wait
- #+os-windows :show-window #+os-windows (if interactive nil :hide)
- :allow-other-keys t keys))
- #-allegro
- (with-current-directory (#-(or sbcl mkcl) directory)
</span><span style="color: #000000;background-color: #ddffdd">+ #+allegro 'excl:run-shell-command
+ #+(and allegro os-unix) (coerce (cons (first %command) %command) 'vector)
+ #+(and allegro os-windows) %command
</span> #+clisp
<span style="color: #000000;background-color: #ffdddd">- (flet ((run (f x &rest args)
- (multiple-value-list
- (apply f x :input %input :output %output
- :allow-other-keys t `(,@args ,@keys)))))
- (assert (eq %error-output :terminal))
- ;;; since we now always return a code, we can't use this code path, anyway!
- (etypecase %command
- #+os-windows (string (run 'ext:run-shell-command %command))
- (list (run 'ext:run-program (car %command)
- :arguments (cdr %command)))))
- #+(or clasp clozure cmu ecl mkcl sbcl scl)
- (#-(or clasp ecl mkcl) progn #+(or clasp ecl mkcl) multiple-value-list
- (apply
- '#+(or cmu ecl scl) ext:run-program
- #+clozure ccl:run-program #+sbcl sb-ext:run-program #+mkcl mk-ext:run-program
- (car %command) (cdr %command)
- :input %input
- :output %output
- :error %error-output
- :wait wait
- :allow-other-keys t
- (append
- #+(or clozure cmu mkcl sbcl scl)
- `(:if-input-does-not-exist ,if-input-does-not-exist
- :if-output-exists ,if-output-exists
- :if-error-exists ,if-error-output-exists)
- #+sbcl `(:search t
- :if-output-does-not-exist :create
- :if-error-does-not-exist :create)
- #-sbcl keys #+sbcl (if directory keys (remove-plist-key :directory keys)))))
- #+(and lispworks os-unix) ;; note: only used on Unix in non-interactive case
- (multiple-value-list
- (apply
- 'system:run-shell-command
- (cons "/usr/bin/env" %command) ; lispworks wants a full path.
- :input %input :if-input-does-not-exist if-input-does-not-exist
- :output %output :if-output-exists if-output-exists
- :error-output %error-output :if-error-output-exists if-error-output-exists
- :wait wait :save-exit-status t :allow-other-keys t keys))))
</span><span style="color: #000000;background-color: #ddffdd">+ (etypecase %command
+ #+os-windows
+ (string (lambda (&rest keys) (apply 'ext:run-shell-command %command keys)))
+ (list (lambda (&rest keys)
+ (apply 'ext:run-program (car %command) :arguments (cdr %command) keys))))
+ #+clozure 'ccl:run-program
+ #+(or cmu ecl scl) 'ext:run-program
+ #+lispworks 'system:run-shell-command
+ #+lispworks (cons "/usr/bin/env" %command) ; LW wants a full path
+ #+mkcl 'mk-ext:run-program
+ #+sbcl 'sb-ext:run-program
+ (append
+ #+(or clozure cmu ecl mkcl sbcl scl) `(,(car %command) ,(cdr %command))
+ `(:input ,%input :output ,%output :wait ,wait :allow-other-keys t)
+ #-clisp `(#+(or allegro lispworks) :error-output #-(or allegro lispworks) :error
+ ,%error-output)
+ #+(and allegro os-windows) `(:show-window ,(if interactive nil :hide))
+ #+(or clozure cmu ecl lispworks mkcl sbcl scl)
+ `(:if-input-does-not-exist ,if-input-does-not-exist
+ :if-output-exists ,if-output-exists
+ #-lispworks :if-error-exists #+lispworks :if-error-output-exists
+ ,if-error-output-exists)
+ #+lispworks `(:save-exit-status t)
+ #+sbcl `(:search t
+ :if-output-does-not-exist :create
+ :if-error-does-not-exist :create)
+ #+mkcl `(:directory ,(native-namestring directory))
+ #-sbcl keys
+ #+sbcl (if directory keys (remove-plist-key :directory keys))))))
</span> (process-info-r ()))
(flet ((prop (key value) (push key process-info-r) (push value process-info-r)))
#+allegro
<span style="color: #aaaaaa">@@ -5145,8 +5143,8 @@ It returns a process-info plist with possible keys:
</span> (1 (prop :input-stream (first process*)))
(2 (prop :output-stream (first process*)))
(3 (prop :bidir-stream (pop process*))
<span style="color: #000000;background-color: #ffdddd">- (prop :input-stream (pop process*))
- (prop :output-stream (pop process*))))))
</span><span style="color: #000000;background-color: #ddffdd">+ (prop :input-stream (pop process*))
+ (prop :output-stream (pop process*))))))
</span> #+(or clozure cmu sbcl scl)
(progn
(prop :process process*)
<span style="color: #aaaaaa">@@ -5204,13 +5202,12 @@ It returns a process-info plist with possible keys:
</span> ;; 1- wait
#+clozure (ccl::external-process-wait process)
#+(or cmu scl) (ext:process-wait process)
<span style="color: #000000;background-color: #ffdddd">- #+(and (or clasp ecl) os-unix) (ext:external-process-wait process)
</span> #+sbcl (sb-ext:process-wait process)
;; 2- extract result
#+allegro (sys:reap-os-subprocess :pid process :wait t)
#+clozure (nth-value 1 (ccl:external-process-status process))
#+(or cmu scl) (ext:process-exit-code process)
<span style="color: #000000;background-color: #ffdddd">- #+(or clasp ecl) (nth-value 1 (ext:external-process-status process))
</span><span style="color: #000000;background-color: #ddffdd">+ #+(or clasp ecl) (nth-value 1 (ext:external-process-wait process t))
</span> #+lispworks
(if-let ((stream (or (getf process-info :input-stream)
(getf process-info :output-stream)
<span style="color: #aaaaaa">@@ -5475,7 +5472,9 @@ It returns a process-info plist with possible keys:
</span> &allow-other-keys)
"Run program specified by COMMAND,
either a list of strings specifying a program and list of arguments,
<span style="color: #000000;background-color: #ffdddd">-or a string specifying a shell command (/bin/sh on Unix, CMD.EXE on Windows).
</span><span style="color: #000000;background-color: #ddffdd">+or a string specifying a shell command (/bin/sh on Unix, CMD.EXE on Windows);
+_synchronously_ process its output as specified and return the processing results
+when the program and its output processing are complete.
</span>
Always call a shell (rather than directly execute the command when possible)
if FORCE-SHELL is specified. Similarly, never call a shell if FORCE-SHELL is
<span style="color: #aaaaaa">@@ -5531,11 +5530,15 @@ or an indication of failure via the EXIT-CODE of the process"
</span> ;; don't override user's specified preference. [2015/06/29:rpg]
(when (stringp command)
(unless force-shell-suppliedp
<span style="color: #000000;background-color: #ddffdd">+ #-(and sbcl os-windows) ;; force-shell t isn't working properly on windows as of sbcl 1.2.16
</span> (setf force-shell t)))
(flet ((default (x xp output) (cond (xp x) ((eq output :interactive) :interactive))))
(apply (if (or force-shell
<span style="color: #000000;background-color: #ffdddd">- #+(or clasp clisp ecl) (or (not ignore-error-status) t)
</span><span style="color: #000000;background-color: #ddffdd">+ #+(or clasp clisp) (or (not ignore-error-status) t)
</span> #+clisp (member error-output '(:interactive :output))
<span style="color: #000000;background-color: #ddffdd">+ ;; A race condition in ECL <= 16.0.0 prevents using ext:run-program
+ #+ecl #.(if-let (ver (parse-version (lisp-implementation-version)))
+ (lexicographic<= '< ver '(16 0 1)))
</span> #+(and lispworks os-unix) (%interactivep input output error-output)
#+(or abcl cormanlisp gcl (and lispworks os-windows) mcl xcl) t)
'%use-system '%use-run-program)
<span style="color: #aaaaaa">@@ -5546,7 +5549,7 @@ or an indication of failure via the EXIT-CODE of the process"
</span> :if-output-exists if-output-exists
:if-error-output-exists if-error-output-exists
:element-type element-type :external-format external-format
<span style="color: #000000;background-color: #ffdddd">- keys))))
</span><span style="color: #000000;background-color: #ddffdd">+ keys))))
</span> ;;;; -------------------------------------------------------------------------
;;;; Support to build (compile and load) Lisp files
<span style="color: #aaaaaa">@@ -6221,8 +6224,7 @@ it will filter them appropriately."
</span> (unless (use-ecl-byte-compiler-p)
(or object-file
#+ecl(compile-file-pathname output-file :type :object)
<span style="color: #000000;background-color: #ffdddd">- #+clasp (compile-file-pathname output-file :output-type :object)
- )))
</span><span style="color: #000000;background-color: #ddffdd">+ #+clasp (compile-file-pathname output-file :output-type :object))))
</span> #+mkcl
(object-file
(or object-file
<span style="color: #aaaaaa">@@ -6335,7 +6337,7 @@ it will filter them appropriately."
</span> :members
,(loop :for f :in (reverse fasls)
:collect `(,(namestring f) :load-only t))))
<span style="color: #000000;background-color: #ffdddd">- (scm:concatenate-system output :fasls-to-concatenate))
</span><span style="color: #000000;background-color: #ddffdd">+ (scm:concatenate-system output :fasls-to-concatenate :force t))
</span> (loop :for f :in fasls :do (ignore-errors (delete-file f)))
(ignore-errors (lispworks:delete-system :fasls-to-concatenate))))))
;;;; ---------------------------------------------------------------------------
<span style="color: #aaaaaa">@@ -6685,7 +6687,7 @@ also \"Configuration DSL\"\) in the ASDF manual."
</span> (resolve-absolute-location
`(,(or (getenv-absolute-directory "XDG_CACHE_HOME")
(os-cond
<span style="color: #000000;background-color: #ffdddd">- ((os-windows-p) (xdg-data-home "cache"))
</span><span style="color: #000000;background-color: #ddffdd">+ ((os-windows-p) (xdg-data-home "cache/"))
</span> (t (subpathname* (user-homedir-pathname) ".cache/"))))
,more)))
<span style="color: #aaaaaa">@@ -6910,7 +6912,7 @@ previously-loaded version of ASDF."
</span> ;; "3.4.5.67" would be a development version in the official branch, on top of 3.4.5.
;; "3.4.5.0.8" would be your eighth local modification of official release 3.4.5
;; "3.4.5.67.8" would be your eighth local modification of development version 3.4.5.67
<span style="color: #000000;background-color: #ffdddd">- (asdf-version "3.1.5")
</span><span style="color: #000000;background-color: #ddffdd">+ (asdf-version "3.1.6")
</span> (existing-version (asdf-version)))
(setf *asdf-version* asdf-version)
(when (and existing-version (not (equal asdf-version existing-version)))
<span style="color: #aaaaaa">@@ -8617,7 +8619,13 @@ in some previous image, or T if it needs to be done.")
</span> &optional
#+(or clasp ecl mkcl) object-file
#+clisp lib-file
<span style="color: #000000;background-color: #ffdddd">- warnings-file) outputs
</span><span style="color: #000000;background-color: #ddffdd">+ warnings-file &rest rest) outputs
+ ;; Allow for extra outputs that are not of type warnings-file
+ ;; The way we do it is kludgy. In ASDF4, output-files shall not be positional.
+ (declare (ignore rest))
+ (when warnings-file
+ (unless (equal (pathname-type warnings-file) (warnings-file-type))
+ (setf warnings-file nil)))
</span> (call-with-around-compile-hook
c #'(lambda (&rest flags)
(apply 'compile-file* input-file
<span style="color: #aaaaaa">@@ -8974,7 +8982,7 @@ the action of OPERATION on COMPONENT in the PLAN"))
</span> (latest-in (stamps-latest (cons dep-stamp in-stamps))))
(when (and missing-in (not just-done)) (return (values t nil))))
;; collect timestamps from outputs, and exit early if any is missing
<span style="color: #000000;background-color: #ffdddd">- (let* ((out-files (output-files o c))
</span><span style="color: #000000;background-color: #ddffdd">+ (let* ((out-files (remove-if 'null (output-files o c)))
</span> (out-stamps (mapcar (if just-done 'register-file-stamp 'get-file-stamp) out-files))
(missing-out (loop :for f :in out-files :for s :in out-stamps :unless s :collect f))
(earliest-out (stamps-earliest out-stamps)))
<span style="color: #aaaaaa">@@ -9810,7 +9818,7 @@ effectively disabling the output translation facility."
</span> #:default-user-source-registry #:default-system-source-registry
#:user-source-registry #:system-source-registry
#:user-source-registry-directory #:system-source-registry-directory
<span style="color: #000000;background-color: #ffdddd">- #:environment-source-registry #:process-source-registry
</span><span style="color: #000000;background-color: #ddffdd">+ #:environment-source-registry #:process-source-registry #:inherit-source-registry
</span> #:compute-source-registry #:flatten-source-registry
#:sysdef-source-registry-search))
(in-package :asdf/source-registry)
<span style="color: #aaaaaa">@@ -9833,6 +9841,8 @@ effectively disabling the output translation facility."
</span> "Either NIL (for uninitialized), or an equal hash-table, mapping
system names to pathnames of .asd files")
<span style="color: #000000;background-color: #ddffdd">+ (defvar *source-registry-parameter* nil)
+
</span> (defun source-registry-initialized-p ()
(typep *source-registry* 'hash-table))
<span style="color: #aaaaaa">@@ -10054,7 +10064,7 @@ after having found a .asd file? True by default.")
</span> (dolist (directive (cdr (validate-source-registry-form form)))
(process-source-registry-directive directive :inherit inherit :register register))))
<span style="color: #000000;background-color: #ffdddd">- (defun flatten-source-registry (&optional parameter)
</span><span style="color: #000000;background-color: #ddffdd">+ (defun flatten-source-registry (&optional (parameter *source-registry-parameter*))
</span> (remove-duplicates
(while-collecting (collect)
(with-pathname-defaults () ;; be location-independent
<span style="color: #aaaaaa">@@ -10067,7 +10077,7 @@ after having found a .asd file? True by default.")
</span> :test 'equal :from-end t))
;; Will read the configuration and initialize all internal variables.
<span style="color: #000000;background-color: #ffdddd">- (defun compute-source-registry (&optional parameter (registry *source-registry*))
</span><span style="color: #000000;background-color: #ddffdd">+ (defun compute-source-registry (&optional (parameter *source-registry-parameter*) (registry *source-registry*))
</span> (dolist (entry (flatten-source-registry parameter))
(destructuring-bind (directory &key recurse exclude) entry
(let* ((h (make-hash-table :test 'equal))) ; table to detect duplicates
<span style="color: #aaaaaa">@@ -10097,8 +10107,6 @@ after having found a .asd file? True by default.")
</span> h)))
(values))
<span style="color: #000000;background-color: #ffdddd">- (defvar *source-registry-parameter* nil)
-
</span> (defun initialize-source-registry (&optional (parameter *source-registry-parameter*))
;; Record the parameter used to configure the registry
(setf *source-registry-parameter* parameter)
<span style="color: #aaaaaa">@@ -10447,7 +10455,7 @@ system names contained using COERCE-NAME. Return the result."
</span> :asdf/action :asdf/lisp-action :asdf/plan :asdf/operate :asdf/defsystem)
(:export
#:bundle-op #:bundle-type #:program-system
<span style="color: #000000;background-color: #ffdddd">- #:bundle-system #:bundle-pathname-type #:bundlable-file-p #:direct-dependency-files
</span><span style="color: #000000;background-color: #ddffdd">+ #:bundle-system #:bundle-pathname-type #:direct-dependency-files
</span> #:monolithic-op #:monolithic-bundle-op #:operation-monolithic-p
#:basic-compile-bundle-op #:prepare-bundle-op
#:compile-bundle-op #:load-bundle-op #:monolithic-compile-bundle-op #:monolithic-load-bundle-op
<span style="color: #aaaaaa">@@ -10505,7 +10513,8 @@ itself.")) ;; operation on a system and its dependencies
</span> (:documentation "Abstract operation for linking files together"))
(defclass gather-op (bundle-op)
<span style="color: #000000;background-color: #ffdddd">- ((gather-op :initform nil :allocation :class :reader gather-op))
</span><span style="color: #000000;background-color: #ddffdd">+ ((gather-op :initform nil :allocation :class :reader gather-op)
+ (gather-type :initform :no-output-file :allocation :class :reader gather-type))
</span> (:documentation "Abstract operation for gathering many input files from a system"))
(defun operation-monolithic-p (op)
<span style="color: #aaaaaa">@@ -10525,7 +10534,9 @@ itself.")) ;; operation on a system and its dependencies
</span>
;; create a single fasl for the entire library
(defclass basic-compile-bundle-op (bundle-op)
<span style="color: #000000;background-color: #ffdddd">- ((bundle-type :initform :fasl)))
</span><span style="color: #000000;background-color: #ddffdd">+ ((gather-type :initform #-(or clasp ecl mkcl) :fasl #+(or clasp ecl mkcl) :object
+ :allocation :class)
+ (bundle-type :initform :fasl :allocation :class)))
</span>
(defclass prepare-bundle-op (sideway-operation)
((sideway-operation
<span style="color: #aaaaaa">@@ -10533,16 +10544,32 @@ itself.")) ;; operation on a system and its dependencies
</span> :allocation :class)))
(defclass lib-op (link-op gather-op non-propagating-operation)
<span style="color: #000000;background-color: #ffdddd">- ((bundle-type :initform :lib))
- (:documentation "compile the system and produce linkable (.a) library for it."))
</span><span style="color: #000000;background-color: #ddffdd">+ ((gather-type :initform :object :allocation :class)
+ (bundle-type :initform :lib :allocation :class))
+ (:documentation "Compile the system and produce a linkable static library (.a/.lib)
+for all the linkable object files associated with the system. Compare with DLL-OP.
+
+On most implementations, these object files only include extensions to the runtime
+written in C or another language with a compiler producing linkable object files.
+On CLASP, ECL, MKCL, these object files also include the contents of Lisp files
+themselves. In any case, this operation will produce what you need to further build
+a static runtime for your system, or a dynamic library to load in an existing runtime."))
</span>
(defclass compile-bundle-op (basic-compile-bundle-op selfward-operation
#+(or clasp ecl mkcl) link-op #-(or clasp ecl) gather-op)
((selfward-operation :initform '(prepare-bundle-op #+(or clasp ecl) lib-op)
<span style="color: #000000;background-color: #ffdddd">- :allocation :class)))
</span><span style="color: #000000;background-color: #ddffdd">+ :allocation :class))
+ (:documentation "This operator is an alternative to COMPILE-OP. Build a system
+and all of its dependencies, but build only a single (\"monolithic\") FASL, instead
+of one per source file, which may be more resource efficient. That monolithic
+FASL should be loaded with LOAD-BUNDLE-OP, rather than LOAD-OP."))
</span>
(defclass load-bundle-op (basic-load-op selfward-operation)
<span style="color: #000000;background-color: #ffdddd">- ((selfward-operation :initform '(prepare-bundle-op compile-bundle-op) :allocation :class)))
</span><span style="color: #000000;background-color: #ddffdd">+ ((selfward-operation :initform '(prepare-bundle-op compile-bundle-op) :allocation :class))
+ (:documentation "This operator is an alternative to LOAD-OP. Build a system
+and all of its dependencies, using COMPILE-BUNDLE-OP. The difference with
+respect to LOAD-OP is that it builds only a single FASL, which may be
+faster and more resource efficient."))
</span>
;; NB: since the monolithic-op's can't be sideway-operation's,
;; if we wanted lib-op, dll-op, deliver-asd-op to be sideway-operation's,
<span style="color: #aaaaaa">@@ -10550,39 +10577,55 @@ itself.")) ;; operation on a system and its dependencies
</span> ;; but instead inherit from a basic-FOO-op as with basic-compile-bundle-op above.
(defclass dll-op (link-op gather-op non-propagating-operation)
<span style="color: #000000;background-color: #ffdddd">- ((bundle-type :initform :dll))
- (:documentation "compile the system and produce dynamic (.so/.dll) library for it."))
</span><span style="color: #000000;background-color: #ddffdd">+ ((gather-type :initform :object :allocation :class)
+ (bundle-type :initform :dll :allocation :class))
+ (:documentation "Compile the system and produce a dynamic loadable library (.so/.dll)
+for all the linkable object files associated with the system. Compare with LIB-OP."))
</span>
(defclass deliver-asd-op (basic-compile-op selfward-operation)
<span style="color: #000000;background-color: #ffdddd">- ((selfward-operation :initform '(compile-bundle-op #+(or clasp ecl mkcl) lib-op) :allocation :class))
</span><span style="color: #000000;background-color: #ddffdd">+ ((selfward-operation
+ ;; TODO: implement link-op on all implementations, and make that
+ ;; '(compile-bundle-op lib-op #-(or clasp ecl mkcl) dll-op)
+ :initform '(compile-bundle-op #+(or clasp ecl mkcl) lib-op)
+ :allocation :class))
</span> (:documentation "produce an asd file for delivering the system as a single fasl"))
(defclass monolithic-deliver-asd-op (monolithic-bundle-op deliver-asd-op)
((selfward-operation
<span style="color: #000000;background-color: #ddffdd">+ ;; TODO: implement link-op on all implementations, and make that
+ ;; '(monolithic-compile-bundle-op monolithic-lib-op #-(or clasp ecl mkcl) monolithic-dll-op)
</span> :initform '(monolithic-compile-bundle-op #+(or clasp ecl mkcl) monolithic-lib-op)
:allocation :class))
(:documentation "produce fasl and asd files for combined system and dependencies."))
<span style="color: #000000;background-color: #ffdddd">- (defclass monolithic-compile-bundle-op (monolithic-bundle-op basic-compile-bundle-op
- #+(or clasp ecl mkcl) link-op gather-op non-propagating-operation)
- ((gather-op :initform #+(or clasp ecl mkcl) 'lib-op #-(or clasp ecl mkcl) 'compile-bundle-op :allocation :class))
</span><span style="color: #000000;background-color: #ddffdd">+ (defclass monolithic-compile-bundle-op
+ (monolithic-bundle-op basic-compile-bundle-op
+ #+(or clasp ecl mkcl) link-op gather-op non-propagating-operation)
+ ((gather-op :initform #-(or clasp ecl mkcl) 'compile-bundle-op #+(or clasp ecl mkcl) 'lib-op
+ :allocation :class)
+ (gather-type :initform #-(or clasp ecl mkcl) :fasl #+(or clasp ecl mkcl) :static-library
+ :allocation :class))
</span> (:documentation "Create a single fasl for the system and its dependencies."))
(defclass monolithic-load-bundle-op (monolithic-bundle-op load-bundle-op)
((selfward-operation :initform 'monolithic-compile-bundle-op :allocation :class))
(:documentation "Load a single fasl for the system and its dependencies."))
<span style="color: #000000;background-color: #ffdddd">- (defclass monolithic-lib-op (monolithic-bundle-op lib-op non-propagating-operation) ()
- (:documentation "Create a single linkable library for the system and its dependencies."))
</span><span style="color: #000000;background-color: #ddffdd">+ (defclass monolithic-lib-op (monolithic-bundle-op lib-op non-propagating-operation)
+ ((gather-type :initform :static-library :allocation :class))
+ (:documentation "Compile the system and produce a linkable static library (.a/.lib)
+for all the linkable object files associated with the system or its dependencies. See LIB-OP."))
</span>
(defclass monolithic-dll-op (monolithic-bundle-op dll-op non-propagating-operation)
<span style="color: #000000;background-color: #ffdddd">- ((bundle-type :initform :dll))
- (:documentation "Create a single dynamic (.so/.dll) library for the system and its dependencies."))
</span><span style="color: #000000;background-color: #ddffdd">+ ((gather-type :initform :static-library :allocation :class))
+ (:documentation "Compile the system and produce a dynamic loadable library (.so/.dll)
+for all the linkable object files associated with the system or its dependencies. See LIB-OP"))
</span>
(defclass image-op (monolithic-bundle-op selfward-operation
#+(or clasp ecl mkcl) link-op #+(or clasp ecl mkcl) gather-op)
((bundle-type :initform :image)
<span style="color: #000000;background-color: #ddffdd">+ #+(or clasp ecl mkcl) (gather-type :initform :static-library :allocation :class)
</span> (selfward-operation :initform '(#-(or clasp ecl mkcl) load-op) :allocation :class))
(:documentation "create an image file from the system and its dependencies"))
<span style="color: #aaaaaa">@@ -10592,17 +10635,29 @@ itself.")) ;; operation on a system and its dependencies
</span>
(defun bundle-pathname-type (bundle-type)
(etypecase bundle-type
<span style="color: #000000;background-color: #ffdddd">- ((eql :no-output-file) nil) ;; should we error out instead?
- ((or null string) bundle-type)
- ((eql :fasl) #-(or clasp ecl mkcl) (compile-file-type) #+(or clasp ecl mkcl) "fasb")
- #+(or clasp ecl)
- ((member :dll :lib :shared-library :static-library :program :object :program)
- (compile-file-type :type bundle-type))
- ((member :image) #+allegro "dxl" #+(and clisp os-windows) "exe" #-(or allegro (and clisp os-windows)) "image")
- ((member :dll :shared-library) (os-cond ((os-macosx-p) "dylib") ((os-unix-p) "so") ((os-windows-p) "dll")))
- ((member :lib :static-library) (os-cond ((os-unix-p) "a")
- ((os-windows-p) (if (featurep '(:or :mingw32 :mingw64)) "a" "lib"))))
- ((eql :program) (os-cond ((os-unix-p) nil) ((os-windows-p) "exe")))))
</span><span style="color: #000000;background-color: #ddffdd">+ ((or null string) ;; pass through nil or string literal
+ bundle-type)
+ ((eql :no-output-file) ;; marker for a bundle-type that has NO output file
+ (error "No output file, therefore no pathname type"))
+ ((eql :fasl) ;; the type of a fasl
+ #-(or clasp ecl mkcl) (compile-file-type) ; on image-based platforms, used as input and output
+ #+(or clasp ecl mkcl) "fasb") ; on C-linking platforms, only used as output for system bundles
+ ((member :image)
+ #+allegro "dxl"
+ #+(and clisp os-windows) "exe"
+ #-(or allegro (and clisp os-windows)) "image")
+ ;; NB: on CLASP and ECL these implementations, we better agree with
+ ;; (compile-file-type :type bundle-type))
+ ((eql :object) ;; the type of a linkable object file
+ (os-cond ((os-unix-p) "o")
+ ((os-windows-p) (if (featurep '(:or :mingw32 :mingw64)) "o" "obj"))))
+ ((member :lib :static-library) ;; the type of a linkable library
+ (os-cond ((os-unix-p) "a")
+ ((os-windows-p) (if (featurep '(:or :mingw32 :mingw64)) "a" "lib"))))
+ ((member :dll :shared-library) ;; the type of a shared library
+ (os-cond ((os-macosx-p) "dylib") ((os-unix-p) "so") ((os-windows-p) "dll")))
+ ((eql :program) ;; the type of an executable program
+ (os-cond ((os-unix-p) nil) ((os-windows-p) "exe")))))
</span>
(defun bundle-output-files (o c)
(let ((bundle-type (bundle-type o)))
<span style="color: #aaaaaa">@@ -10612,7 +10667,10 @@ itself.")) ;; operation on a system and its dependencies
</span> (format nil "~A~@[~A~]" (component-name c) (slot-value o 'name-suffix))))
(type (bundle-pathname-type bundle-type)))
(values (list (subpathname (component-pathname c) name :type type))
<span style="color: #000000;background-color: #ffdddd">- (eq (type-of o) (component-build-operation c)))))))
</span><span style="color: #000000;background-color: #ddffdd">+ (eq (type-of o) (coerce-class (component-build-operation c)
+ :package :asdf/interface
+ :super 'operation
+ :error nil)))))))
</span>
(defmethod output-files ((o bundle-op) (c system))
(bundle-output-files o c))
<span style="color: #aaaaaa">@@ -10667,16 +10725,6 @@ itself.")) ;; operation on a system and its dependencies
</span> :force :force-not :plan-class) ;; TODO: refactor so we don't mix plan and operation arguments
(operation-original-initargs instance))))
<span style="color: #000000;background-color: #ffdddd">- (defun bundlable-file-p (pathname)
- (let ((type (pathname-type pathname)))
- (declare (ignorable type))
- (or #+(or clasp ecl) (or (equalp type (compile-file-type :type :object))
- (equalp type (compile-file-type :type :static-library)))
- #+mkcl (or (equalp type (compile-file-type :fasl-p nil))
- #+(or unix mingw32 mingw64) (equalp type "a") ;; valid on Unix and MinGW
- #+(and windows (not (or mingw32 mingw64))) (equalp type "lib"))
- #+(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type)))))
-
</span> (defgeneric* (trivial-system-p) (component))
(defun user-system-p (s)
<span style="color: #aaaaaa">@@ -10705,9 +10753,14 @@ itself.")) ;; operation on a system and its dependencies
</span> (loop :for f :in (funcall key sub-o sub-c)
:when (funcall test f) :do (collect f))))))
<span style="color: #000000;background-color: #ddffdd">+ (defun pathname-type-equal-function (type)
+ #'(lambda (p) (equal (pathname-type p) type)))
+
</span> (defmethod input-files ((o gather-op) (c system))
(unless (eq (bundle-type o) :no-output-file)
<span style="color: #000000;background-color: #ffdddd">- (direct-dependency-files o c :test 'bundlable-file-p :key 'output-files)))
</span><span style="color: #000000;background-color: #ddffdd">+ (direct-dependency-files
+ o c :key 'output-files
+ :test (pathname-type-equal-function (bundle-pathname-type (gather-type o))))))
</span>
(defun select-bundle-operation (type &optional monolithic)
(ecase type
<span style="color: #aaaaaa">@@ -10906,10 +10959,11 @@ itself.")) ;; operation on a system and its dependencies
</span>
#+(or clasp ecl mkcl)
(with-upgradability ()
<span style="color: #000000;background-color: #ffdddd">- ;; I think that Juanjo intended for this to be,
- ;; but beware the weird bug in test-xach-update-bug.script,
- ;; and also it makes mkcl fail test-logical-pathname.script,
- ;; and ecl fail test-bundle.script.
</span><span style="color: #000000;background-color: #ddffdd">+ ;; I think that Juanjo intended for this to be, but it was disabled before 3.1
+ ;; due to implementation bugs in ECL and MKCL that seem to have been fixed since
+ ;; -- see for ECL test-xach-update-bug.script and test-bundle.script,
+ ;; and for MKCL test-logical-pathname.script.
+ ;; We should probably reenable these after consulting with ECL and MKCL maintainers.
</span> ;;(unless (or #+(or clasp ecl) (use-ecl-byte-compiler-p))
;; (setf *load-system-operation* 'load-bundle-op))
<span style="color: #aaaaaa">@@ -10942,12 +10996,12 @@ itself.")) ;; operation on a system and its dependencies
</span> `(,(make-library-system
"cmp" (compiler-library-pathname))))
,@(unless (or (no-uiop c) (has-it-p "uiop") (has-it-p "asdf"))
<span style="color: #000000;background-color: #ffdddd">- `(cond
- ((system-source-directory :uiop) `(,(find-system :uiop)))
- ((system-source-directory :asdf) `(,(find-system :asdf)))
- (t `(,@(if-let (uiop (uiop-library-pathname))
- `(,(make-library-system "uiop" uiop)))
- ,(make-library-system "asdf" (asdf-library-pathname))))))
</span><span style="color: #000000;background-color: #ddffdd">+ (cond
+ ((system-source-directory :uiop) `(,(find-system :uiop)))
+ ((system-source-directory :asdf) `(,(find-system :asdf)))
+ (t `(,@(if-let (uiop (uiop-library-pathname))
+ `(,(make-library-system "uiop" uiop)))
+ ,(make-library-system "asdf" (asdf-library-pathname))))))
</span> ,@deps)))))
(defmethod perform ((o link-op) (c system))
<span style="color: #aaaaaa">@@ -10979,21 +11033,6 @@ itself.")) ;; operation on a system and its dependencies
</span> "BASIC-COMPILE-BUNDLE-OP operations are not supported on Mac OS X for this lisp.~%~T~
To continue, push :asdf-use-unsafe-mac-bundle-op onto *FEATURES*.~%~T~
Please report to ASDF-DEVEL if this works for you.")))
<span style="color: #000000;background-color: #ffdddd">-
-
-;;; Backward compatibility with pre-3.1.2 names
-;; (defclass fasl-op (selfward-operation)
-;; ((selfward-operation :initform 'compile-bundle-op :allocation :class)))
-;; (defclass load-fasl-op (selfward-operation)
-;; ((selfward-operation :initform 'load-bundle-op :allocation :class)))
-;; (defclass binary-op (selfward-operation)
-;; ((selfward-operation :initform 'deliver-asd-op :allocation :class)))
-;; (defclass monolithic-fasl-op (selfward-operation)
-;; ((selfward-operation :initform 'monolithic-compile-bundle-op :allocation :class)))
-;; (defclass monolithic-load-fasl-op (selfward-operation)
-;; ((selfward-operation :initform 'monolithic-load-bundle-op :allocation :class)))
-;; (defclass monolithic-binary-op (selfward-operation)
-;; ((selfward-operation :initform 'monolithic-deliver-asd-op :allocation :class)))
</span> ;;;; -------------------------------------------------------------------------
;;;; Concatenate-source
<span style="color: #aaaaaa">@@ -11198,7 +11237,7 @@ otherwise return a default system name computed from PACKAGE-NAME."
</span> (unless (equal primary system)
(let ((top (find-system primary nil)))
(when (typep top 'package-inferred-system)
<span style="color: #000000;background-color: #ffdddd">- (if-let (dir (system-source-directory top))
</span><span style="color: #000000;background-color: #ddffdd">+ (if-let (dir (component-pathname top))
</span> (let* ((sub (subseq system (1+ (length primary))))
(f (probe-file* (subpathname dir sub :type "lisp")
:truename *resolve-symlinks*)))
</code></pre>
<br>
</li>
<li id='diff-1'>
<a href='https://gitlab.common-lisp.net/cmucl/cmucl/compare/b239ce3f44b62821701e3447437705d3d914a5b4...1d034d24f6c87575de73422e32cdca5501d37ef5#diff-1'>
<strong>
src/contrib/asdf/doc/asdf.html
</strong>
</a>
<hr>
<pre class="highlight"><code><span style="color: #000000;background-color: #ffdddd">--- a/src/contrib/asdf/doc/asdf.html
</span><span style="color: #000000;background-color: #ddffdd">+++ b/src/contrib/asdf/doc/asdf.html
</span><span style="color: #aaaaaa">@@ -1,23 +1,16 @@
</span><span style="color: #000000;background-color: #ffdddd">-<html lang="en">
-<head>
-<title>ASDF Manual</title>
-<meta http-equiv="Content-Type" content="text/html">
-<meta name="description" content="ASDF Manual">
-<meta name="generator" content="makeinfo 4.13">
-<link title="Top" rel="top" href="#Top">
-<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
-<!--
-This manual describes ASDF, a system definition facility
</span><span style="color: #000000;background-color: #ddffdd">+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<!-- This manual describes ASDF, a system definition facility
</span> for Common Lisp programs and libraries.
You can find the latest version of this manual at
<span style="color: #000000;background-color: #ffdddd">-`http://common-lisp.net/project/asdf/asdf.html'.
</span><span style="color: #000000;background-color: #ddffdd">+https://common-lisp.net/project/asdf/asdf.html.
</span>
<span style="color: #000000;background-color: #ffdddd">-ASDF Copyright (C) 2001-2013 Daniel Barlow and contributors.
</span><span style="color: #000000;background-color: #ddffdd">+ASDF Copyright (C) 2001-2015 Daniel Barlow and contributors.
</span>
<span style="color: #000000;background-color: #ffdddd">-This manual Copyright (C) 2001-2013 Daniel Barlow and contributors.
</span><span style="color: #000000;background-color: #ddffdd">+This manual Copyright (C) 2001-2015 Daniel Barlow and contributors.
</span>
<span style="color: #000000;background-color: #ffdddd">-This manual revised (C) 2009-2013 Robert P. Goldman and Francois-Rene Rideau.
</span><span style="color: #000000;background-color: #ddffdd">+This manual revised (C) 2009-2015 Robert P. Goldman and Francois-Rene Rideau.
</span>
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
<span style="color: #aaaaaa">@@ -36,1720 +29,2144 @@ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
</span> NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
<span style="color: #000000;background-color: #ffdddd">-WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.-->
-<meta http-equiv="Content-Style-Type" content="text/css">
-<style type="text/css"><!--
- pre.display { font-family:inherit }
- pre.format { font-family:inherit }
- pre.smalldisplay { font-family:inherit; font-size:smaller }
- pre.smallformat { font-family:inherit; font-size:smaller }
- pre.smallexample { font-size:smaller }
- pre.smalllisp { font-size:smaller }
- span.sc { font-variant:small-caps }
- span.roman { font-family:serif; font-weight:normal; }
- span.sansserif { font-family:sans-serif; font-weight:normal; }
---></style>
-</head>
-<body>
-<h1 class="settitle">ASDF Manual</h1>
- <div class="contents">
-<h2>Table of Contents</h2>
-<ul>
-<li><a name="toc_Top" href="#Top">asdf: another system definition facility</a>
-<li><a name="toc_Introduction" href="#Introduction">1 Introduction</a>
-<li><a name="toc_Loading-ASDF" href="#Loading-ASDF">2 Loading ASDF</a>
-<ul>
-<li><a href="#Loading-ASDF">2.1 Loading a pre-installed ASDF</a>
-<li><a href="#Loading-ASDF">2.2 Checking whether ASDF is loaded</a>
-<li><a href="#Loading-ASDF">2.3 Upgrading ASDF</a>
-<li><a href="#Loading-ASDF">2.4 Loading an otherwise installed ASDF</a>
-</li></ul>
-<li><a name="toc_Configuring-ASDF" href="#Configuring-ASDF">3 Configuring ASDF</a>
-<ul>
-<li><a href="#Configuring-ASDF">3.1 Configuring ASDF to find your systems</a>
-<li><a href="#Configuring-ASDF">3.2 Configuring ASDF to find your systems — old style</a>
-<li><a href="#Configuring-ASDF">3.3 Configuring where ASDF stores object files</a>
-<li><a href="#Using-ASDF">3.4 Resetting Configuration</a>
-</li></ul>
-<li><a name="toc_Using-ASDF" href="#Using-ASDF">4 Using ASDF</a>
-<ul>
-<li><a href="#Using-ASDF">4.1 Loading a system</a>
-<li><a href="#Using-ASDF">4.2 Other Operations</a>
-<li><a href="#Using-ASDF">4.3 Summary</a>
-<li><a href="#Using-ASDF">4.4 Moving on</a>
-</li></ul>
-<li><a name="toc_Defining-systems-with-defsystem" href="#Defining-systems-with-defsystem">5 Defining systems with defsystem</a>
-<ul>
-<li><a href="#The-defsystem-form">5.1 The defsystem form</a>
-<li><a href="#A-more-involved-example">5.2 A more involved example</a>
-<li><a href="#The-defsystem-grammar">5.3 The defsystem grammar</a>
-<ul>
-<li><a href="#The-defsystem-grammar">5.3.1 Component names</a>
-<li><a href="#The-defsystem-grammar">5.3.2 Component types</a>
-<li><a href="#The-defsystem-grammar">5.3.3 System class names</a>
-<li><a href="#The-defsystem-grammar">5.3.4 Defsystem depends on</a>
-<li><a href="#The-defsystem-grammar">5.3.5 Weakly depends on</a>
-<li><a href="#The-defsystem-grammar">5.3.6 Pathname specifiers</a>
-<li><a href="#The-defsystem-grammar">5.3.7 Version specifiers</a>
-<li><a href="#The-defsystem-grammar">5.3.8 Using logical pathnames</a>
-<li><a href="#The-defsystem-grammar">5.3.9 Serial dependencies</a>
-<li><a href="#The-defsystem-grammar">5.3.10 Source location</a>
-<li><a href="#The-defsystem-grammar">5.3.11 if-feature option</a>
-<li><a href="#The-defsystem-grammar">5.3.12 if-component-dep-fails option</a>
-</li></ul>
-<li><a href="#Other-code-in-_002easd-files">5.4 Other code in .asd files</a>
-</li></ul>
-<li><a name="toc_The-object-model-of-ASDF" href="#The-object-model-of-ASDF">6 The object model of ASDF</a>
-<ul>
-<li><a href="#Operations">6.1 Operations</a>
-<ul>
-<li><a href="#Predefined-operations-of-ASDF">6.1.1 Predefined operations of ASDF</a>
-<li><a href="#Creating-new-operations">6.1.2 Creating new operations</a>
-</li></ul>
-<li><a href="#Components">6.2 Components</a>
-<ul>
-<li><a href="#Common-attributes-of-components">6.2.1 Common attributes of components</a>
-<ul>
-<li><a href="#Common-attributes-of-components">6.2.1.1 Name</a>
-<li><a href="#Common-attributes-of-components">6.2.1.2 Version identifier</a>
-<li><a href="#Common-attributes-of-components">6.2.1.3 Required features</a>
-<li><a href="#Common-attributes-of-components">6.2.1.4 Dependencies</a>
-<li><a href="#Common-attributes-of-components">6.2.1.5 pathname</a>
-<li><a href="#Common-attributes-of-components">6.2.1.6 properties</a>
-</li></ul>
-<li><a href="#Pre_002ddefined-subclasses-of-component">6.2.2 Pre-defined subclasses of component</a>
-<li><a href="#Creating-new-component-types">6.2.3 Creating new component types</a>
-</li></ul>
-<li><a href="#Functions">6.3 Functions</a>
-</li></ul>
-<li><a name="toc_Controlling-where-ASDF-searches-for-systems" href="#Controlling-where-ASDF-searches-for-systems">7 Controlling where ASDF searches for systems</a>
-<ul>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.1 Configurations</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.2 Truenames and other dangers</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.3 XDG base directory</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.4 Backward Compatibility</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.5 Configuration DSL</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.6 Configuration Directories</a>
-<ul>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.6.1 The :here directive</a>
-</li></ul>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.7 Shell-friendly syntax for configuration</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.8 Search Algorithm</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.9 Caching Results</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.10 Configuration API</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.11 Status</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.12 Rejected ideas</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.13 TODO</a>
-<li><a href="#Controlling-where-ASDF-searches-for-systems">7.14 Credits for the source-registry</a>
-</li></ul>
-<li><a name="toc_Controlling-where-ASDF-saves-compiled-files" href="#Controlling-where-ASDF-saves-compiled-files">8 Controlling where ASDF saves compiled files</a>
-<ul>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.1 Configurations</a>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.2 Backward Compatibility</a>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.3 Configuration DSL</a>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.4 Configuration Directories</a>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.5 Shell-friendly syntax for configuration</a>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.6 Semantics of Output Translations</a>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.7 Caching Results</a>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.8 Output location API</a>
-<li><a href="#Controlling-where-ASDF-saves-compiled-files">8.9 Credits for output translations</a>
-</li></ul>
-<li><a name="toc_Error-handling" href="#Error-handling">9 Error handling</a>
-<ul>
-<li><a href="#Error-handling">9.1 ASDF errors</a>
-<li><a href="#Error-handling">9.2 Compilation error and warning handling</a>
-</li></ul>
-<li><a name="toc_Miscellaneous-additional-functionality" href="#Miscellaneous-additional-functionality">10 Miscellaneous additional functionality</a>
-<ul>
-<li><a href="#Miscellaneous-additional-functionality">10.1 Controlling file compilation</a>
-<li><a href="#Miscellaneous-additional-functionality">10.2 Controlling source file character encoding</a>
-<li><a href="#Miscellaneous-additional-functionality">10.3 Miscellaneous Functions</a>
-<li><a href="#Miscellaneous-additional-functionality">10.4 Some Utility Functions</a>
-</li></ul>
-<li><a name="toc_Getting-the-latest-version" href="#Getting-the-latest-version">11 Getting the latest version</a>
-<li><a name="toc_FAQ" href="#FAQ">12 FAQ</a>
-<ul>
-<li><a href="#FAQ">12.1 “Where do I report a bug?”</a>
-<li><a href="#FAQ">12.2 “What has changed between ASDF 1 and ASDF 2?”</a>
-<ul>
-<li><a href="#FAQ">12.2.1 What are ASDF 1 and ASDF 2?</a>
-<li><a href="#FAQ">12.2.2 ASDF can portably name files in subdirectories</a>
-<li><a href="#FAQ">12.2.3 Output translations</a>
-<li><a href="#FAQ">12.2.4 Source Registry Configuration</a>
-<li><a href="#FAQ">12.2.5 Usual operations are made easier to the user</a>
-<li><a href="#FAQ">12.2.6 Many bugs have been fixed</a>
-<li><a href="#FAQ">12.2.7 ASDF itself is versioned</a>
-<li><a href="#FAQ">12.2.8 ASDF can be upgraded</a>
-<li><a href="#FAQ">12.2.9 Decoupled release cycle</a>
-<li><a href="#FAQ">12.2.10 Pitfalls of the transition to ASDF 2</a>
-</li></ul>
-<li><a href="#FAQ">12.3 Issues with installing the proper version of ASDF</a>
-<ul>
-<li><a href="#FAQ">12.3.1 “My Common Lisp implementation comes with an outdated version of ASDF. What to do?”</a>
-<li><a href="#FAQ">12.3.2 “I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?”</a>
-</li></ul>
-<li><a href="#FAQ">12.4 Issues with configuring ASDF</a>
-<ul>
-<li><a href="#FAQ">12.4.1 “How can I customize where fasl files are stored?”</a>
-<li><a href="#FAQ">12.4.2 “How can I wholly disable the compiler output cache?”</a>
-</li></ul>
-<li><a href="#FAQ">12.5 Issues with using and extending ASDF to define systems</a>
-<ul>
-<li><a href="#FAQ">12.5.1 “How can I cater for unit-testing in my system?”</a>
-<li><a href="#FAQ">12.5.2 “How can I cater for documentation generation in my system?”</a>
-<li><a href="#FAQ">12.5.3 “How can I maintain non-Lisp (e.g. C) source files?”</a>
-<li><a href="#FAQ">12.5.4 “I want to put my module's files at the top level. How do I do this?”</a>
-<li><a href="#FAQ">12.5.5 How do I create a system definition where all the source files have a .cl extension?</a>
-</li></ul>
-</li></ul>
-<li><a name="toc_TODO-list" href="#TODO-list">13 TODO list</a>
-<ul>
-<li><a href="#TODO-list">13.1 Outstanding spec questions, things to add</a>
-<li><a href="#TODO-list">13.2 Missing bits in implementation</a>
-</li></ul>
-<li><a name="toc_Inspiration" href="#Inspiration">14 Inspiration</a>
-<ul>
-<li><a href="#Inspiration">14.1 mk-defsystem (defsystem-3.x)</a>
-<li><a href="#Inspiration">14.2 defsystem-4 proposal</a>
-<li><a href="#Inspiration">14.3 kmp's “The Description of Large Systems”, MIT AI Memo 801</a>
-</li></ul>
-<li><a name="toc_Concept-Index" href="#Concept-Index">Concept Index</a>
-<li><a name="toc_Function-and-Class-Index" href="#Function-and-Class-Index">Function and Class Index</a>
-<li><a name="toc_Variable-Index" href="#Variable-Index">Variable Index</a>
-</li></ul>
-</div>
-
</span><span style="color: #000000;background-color: #ddffdd">+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ -->
+<!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
+<head>
+<title>ASDF Manual</title>
</span>
<span style="color: #000000;background-color: #ddffdd">+<meta name="description" content="ASDF Manual">
+<meta name="keywords" content="ASDF Manual">
+<meta name="resource-type" content="document">
+<meta name="distribution" content="global">
+<meta name="Generator" content="makeinfo">
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+<link href="#Top" rel="start" title="Top">
+<link href="#Concept-Index" rel="index" title="Concept Index">
+<link href="#SEC_Contents" rel="contents" title="Table of Contents">
+<link href="dir.html#Top" rel="up" title="(dir)">
+<style type="text/css">
+<!--
+a.summary-letter {text-decoration: none}
+blockquote.smallquotation {font-size: smaller}
+div.display {margin-left: 3.2em}
+div.example {margin-left: 3.2em}
+div.indentedblock {margin-left: 3.2em}
+div.lisp {margin-left: 3.2em}
+div.smalldisplay {margin-left: 3.2em}
+div.smallexample {margin-left: 3.2em}
+div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
+div.smalllisp {margin-left: 3.2em}
+kbd {font-style:oblique}
+pre.display {font-family: inherit}
+pre.format {font-family: inherit}
+pre.menu-comment {font-family: serif}
+pre.menu-preformatted {font-family: serif}
+pre.smalldisplay {font-family: inherit; font-size: smaller}
+pre.smallexample {font-size: smaller}
+pre.smallformat {font-family: inherit; font-size: smaller}
+pre.smalllisp {font-size: smaller}
+span.nocodebreak {white-space:nowrap}
+span.nolinebreak {white-space:nowrap}
+span.roman {font-family:serif; font-weight:normal}
+span.sansserif {font-family:sans-serif; font-weight:normal}
+ul.no-bullet {list-style: none}
+-->
+</style>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- -->
-<p><a name="Top"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h2 class="unnumbered">asdf: another system definition facility</h2>
</span><span style="color: #000000;background-color: #ddffdd">+</head>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>This manual describes ASDF, a system definition facility
-for Common Lisp programs and libraries.
</span><span style="color: #000000;background-color: #ddffdd">+<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
+<h1 class="settitle" align="center">ASDF Manual</h1>
+
+
+
+
+
+
+<a name="SEC_Contents"></a>
+<h2 class="contents-heading">Table of Contents</h2>
+
+<div class="contents">
+
+<ul class="no-bullet">
+ <li><a name="toc-Introduction-1" href="#Introduction">1 Introduction</a></li>
+ <li><a name="toc-Quick-start-summary-1" href="#Quick-start-summary">2 Quick start summary</a></li>
+ <li><a name="toc-Loading-ASDF-1" href="#Loading-ASDF">3 Loading ASDF</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Loading-a-pre_002dinstalled-ASDF-1" href="#Loading-a-pre_002dinstalled-ASDF">3.1 Loading a pre-installed ASDF</a></li>
+ <li><a name="toc-Checking-whether-ASDF-is-loaded-1" href="#Checking-whether-ASDF-is-loaded">3.2 Checking whether ASDF is loaded</a></li>
+ <li><a name="toc-Upgrading-ASDF-1" href="#Upgrading-ASDF">3.3 Upgrading ASDF</a></li>
+ <li><a name="toc-Replacing-your-implementation_0027s-ASDF-1" href="#Replacing-your-implementation_0027s-ASDF">3.4 Replacing your implementation’s ASDF</a></li>
+ <li><a name="toc-Loading-ASDF-from-source-1" href="#Loading-ASDF-from-source">3.5 Loading ASDF from source</a></li>
+ </ul></li>
+ <li><a name="toc-Configuring-ASDF-1" href="#Configuring-ASDF">4 Configuring ASDF</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Configuring-ASDF-to-find-your-systems-1" href="#Configuring-ASDF-to-find-your-systems">4.1 Configuring ASDF to find your systems</a></li>
+ <li><a name="toc-Configuring-ASDF-to-find-your-systems-_002d_002d_002d-old-style-1" href="#Configuring-ASDF-to-find-your-systems-_002d_002d_002d-old-style">4.2 Configuring ASDF to find your systems — old style</a></li>
+ <li><a name="toc-Configuring-where-ASDF-stores-object-files-1" href="#Configuring-where-ASDF-stores-object-files">4.3 Configuring where ASDF stores object files</a></li>
+ <li><a name="toc-Resetting-the-ASDF-configuration-1" href="#Resetting-the-ASDF-configuration">4.4 Resetting the ASDF configuration</a></li>
+ </ul></li>
+ <li><a name="toc-Using-ASDF-1" href="#Using-ASDF">5 Using ASDF</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Loading-a-system-1" href="#Loading-a-system">5.1 Loading a system</a></li>
+ <li><a name="toc-Convenience-Functions-1" href="#Convenience-Functions">5.2 Convenience Functions</a></li>
+ <li><a name="toc-Moving-on-1" href="#Moving-on">5.3 Moving on</a></li>
+ </ul></li>
+ <li><a name="toc-Defining-systems-with-defsystem-1" href="#Defining-systems-with-defsystem">6 Defining systems with defsystem</a>
+ <ul class="no-bullet">
+ <li><a name="toc-The-defsystem-form-1" href="#The-defsystem-form">6.1 The defsystem form</a></li>
+ <li><a name="toc-A-more-involved-example-1" href="#A-more-involved-example">6.2 A more involved example</a></li>
+ <li><a name="toc-The-defsystem-grammar-1" href="#The-defsystem-grammar">6.3 The defsystem grammar</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Component-names" href="#Component-names">6.3.1 Component names</a></li>
+ <li><a name="toc-Component-types" href="#Component-types">6.3.2 Component types</a></li>
+ <li><a name="toc-System-class-names" href="#System-class-names">6.3.3 System class names</a></li>
+ <li><a name="toc-Defsystem-depends-on" href="#Defsystem-depends-on">6.3.4 Defsystem depends on</a></li>
+ <li><a name="toc-Weakly-depends-on" href="#Weakly-depends-on">6.3.5 Weakly depends on</a></li>
+ <li><a name="toc-Pathname-specifiers" href="#Pathname-specifiers">6.3.6 Pathname specifiers</a></li>
+ <li><a name="toc-Version-specifiers" href="#Version-specifiers">6.3.7 Version specifiers</a></li>
+ <li><a name="toc-Require" href="#Require">6.3.8 Require</a></li>
+ <li><a name="toc-Using-logical-pathnames" href="#Using-logical-pathnames">6.3.9 Using logical pathnames</a></li>
+ <li><a name="toc-Serial-dependencies" href="#Serial-dependencies">6.3.10 Serial dependencies</a></li>
+ <li><a name="toc-Source-location-_0028_003apathname_0029" href="#Source-location-_0028_003apathname_0029">6.3.11 Source location (<code>:pathname</code>)</a></li>
+ <li><a name="toc-if_002dfeature-option" href="#if_002dfeature-option">6.3.12 if-feature option</a></li>
+ <li><a name="toc-if_002dcomponent_002ddep_002dfails-option" href="#if_002dcomponent_002ddep_002dfails-option">6.3.13 if-component-dep-fails option</a></li>
+ <li><a name="toc-feature-requirement" href="#feature-requirement">6.3.14 feature requirement</a></li>
+ </ul></li>
+ <li><a name="toc-Other-code-in-_002easd-files-1" href="#Other-code-in-_002easd-files">6.4 Other code in .asd files</a></li>
+ <li><a name="toc-The-package_002dinferred_002dsystem-extension-1" href="#The-package_002dinferred_002dsystem-extension">6.5 The package-inferred-system extension</a></li>
+ </ul></li>
+ <li><a name="toc-The-Object-model-of-ASDF" href="#The-object-model-of-ASDF">7 The Object model of ASDF</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Operations-1" href="#Operations">7.1 Operations</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Predefined-operations-of-ASDF-1" href="#Predefined-operations-of-ASDF">7.1.1 Predefined operations of ASDF</a></li>
+ <li><a name="toc-Creating-new-operations-1" href="#Creating-new-operations">7.1.2 Creating new operations</a></li>
+ </ul></li>
+ <li><a name="toc-Components-1" href="#Components">7.2 Components</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Common-attributes-of-components-1" href="#Common-attributes-of-components">7.2.1 Common attributes of components</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Name" href="#Name">7.2.1.1 Name</a></li>
+ <li><a name="toc-Version-identifier" href="#Version-identifier">7.2.1.2 Version identifier</a></li>
+ <li><a name="toc-Required-features" href="#Required-features">7.2.1.3 Required features</a></li>
+ <li><a name="toc-Dependencies-1" href="#Dependencies-1">7.2.1.4 Dependencies</a></li>
+ <li><a name="toc-pathname" href="#pathname">7.2.1.5 pathname</a></li>
+ <li><a name="toc-properties" href="#properties">7.2.1.6 properties</a></li>
+ </ul></li>
+ <li><a name="toc-Pre_002ddefined-subclasses-of-component-1" href="#Pre_002ddefined-subclasses-of-component">7.2.2 Pre-defined subclasses of component</a></li>
+ <li><a name="toc-Creating-new-component-types-1" href="#Creating-new-component-types">7.2.3 Creating new component types</a></li>
+ </ul></li>
+ <li><a name="toc-Dependencies-2" href="#Dependencies">7.3 Dependencies</a></li>
+ <li><a name="toc-Functions-1" href="#Functions">7.4 Functions</a></li>
+ </ul></li>
+ <li><a name="toc-Controlling-where-ASDF-searches-for-systems-1" href="#Controlling-where-ASDF-searches-for-systems">8 Controlling where ASDF searches for systems</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Configurations-1" href="#Configurations">8.1 Configurations</a></li>
+ <li><a name="toc-Truenames-and-other-dangers-1" href="#Truenames-and-other-dangers">8.2 Truenames and other dangers</a></li>
+ <li><a name="toc-XDG-base-directory-1" href="#XDG-base-directory">8.3 XDG base directory</a></li>
+ <li><a name="toc-Backward-Compatibility-1" href="#Backward-Compatibility">8.4 Backward Compatibility</a></li>
+ <li><a name="toc-Configuration-DSL-1" href="#Configuration-DSL">8.5 Configuration DSL</a></li>
+ <li><a name="toc-Configuration-Directories-1" href="#Configuration-Directories">8.6 Configuration Directories</a>
+ <ul class="no-bullet">
+ <li><a name="toc-The-_003ahere-directive" href="#The-here-directive">8.6.1 The :here directive</a></li>
+ </ul></li>
+ <li><a name="toc-Shell_002dfriendly-syntax-for-configuration-1" href="#Shell_002dfriendly-syntax-for-configuration">8.7 Shell-friendly syntax for configuration</a></li>
+ <li><a name="toc-Search-Algorithm-1" href="#Search-Algorithm">8.8 Search Algorithm</a></li>
+ <li><a name="toc-Caching-Results-1" href="#Caching-Results">8.9 Caching Results</a></li>
+ <li><a name="toc-Configuration-API-1" href="#Configuration-API">8.10 Configuration API</a></li>
+ <li><a name="toc-Introspection-1" href="#Introspection">8.11 Introspection</a>
+ <ul class="no-bullet">
+ <li><a name="toc-_002asource_002dregistry_002dparameter_002a-variable-1" href="#g_t_002asource_002dregistry_002dparameter_002a-variable">8.11.1 *source-registry-parameter* variable</a></li>
+ <li><a name="toc-Information-about-system-dependencies-1" href="#Information-about-system-dependencies">8.11.2 Information about system dependencies</a></li>
+ </ul></li>
+ <li><a name="toc-Status-1" href="#Status">8.12 Status</a></li>
+ <li><a name="toc-Rejected-ideas-1" href="#Rejected-ideas">8.13 Rejected ideas</a></li>
+ <li><a name="toc-TODO-1" href="#TODO">8.14 TODO</a></li>
+ <li><a name="toc-Credits-for-the-source_002dregistry-1" href="#Credits-for-the-source_002dregistry">8.15 Credits for the source-registry</a></li>
+ </ul></li>
+ <li><a name="toc-Controlling-where-ASDF-saves-compiled-files-1" href="#Controlling-where-ASDF-saves-compiled-files">9 Controlling where ASDF saves compiled files</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Configurations-2" href="#Output-Configurations">9.1 Configurations</a></li>
+ <li><a name="toc-Backward-Compatibility-2" href="#Output-Backward-Compatibility">9.2 Backward Compatibility</a></li>
+ <li><a name="toc-Configuration-DSL-2" href="#Output-Configuration-DSL">9.3 Configuration DSL</a></li>
+ <li><a name="toc-Configuration-Directories-2" href="#Output-Configuration-Directories">9.4 Configuration Directories</a></li>
+ <li><a name="toc-Shell_002dfriendly-syntax-for-configuration-2" href="#Output-Shell_002dfriendly-syntax-for-configuration">9.5 Shell-friendly syntax for configuration</a></li>
+ <li><a name="toc-Semantics-of-Output-Translations-1" href="#Semantics-of-Output-Translations">9.6 Semantics of Output Translations</a></li>
+ <li><a name="toc-Caching-Results-2" href="#Output-Caching-Results">9.7 Caching Results</a></li>
+ <li><a name="toc-Output-location-API-1" href="#Output-location-API">9.8 Output location API</a></li>
+ <li><a name="toc-Credits-for-output-translations-1" href="#Credits-for-output-translations">9.9 Credits for output translations</a></li>
+ </ul></li>
+ <li><a name="toc-Error-handling-1" href="#Error-handling">10 Error handling</a>
+ <ul class="no-bullet">
+ <li><a name="toc-ASDF-errors" href="#ASDF-errors">10.1 ASDF errors</a></li>
+ <li><a name="toc-Compilation-error-and-warning-handling" href="#Compilation-error-and-warning-handling">10.2 Compilation error and warning handling</a></li>
+ </ul></li>
+ <li><a name="toc-Miscellaneous-additional-functionality-1" href="#Miscellaneous-additional-functionality">11 Miscellaneous additional functionality</a>
+ <ul class="no-bullet">
+ <li><a name="toc-Controlling-file-compilation-1" href="#Controlling-file-compilation">11.1 Controlling file compilation</a></li>
+ <li><a name="toc-Controlling-source-file-character-encoding-1" href="#Controlling-source-file-character-encoding">11.2 Controlling source file character encoding</a></li>
+ <li><a name="toc-Miscellaneous-Functions-1" href="#Miscellaneous-Functions">11.3 Miscellaneous Functions</a></li>
+ <li><a name="toc-Some-Utility-Functions-1" href="#Some-Utility-Functions">11.4 Some Utility Functions</a></li>
+ </ul></li>
+ <li><a name="toc-Getting-the-latest-version-1" href="#Getting-the-latest-version">12 Getting the latest version</a></li>
+ <li><a name="toc-FAQ-1" href="#FAQ">13 FAQ</a>
+ <ul class="no-bullet">
+ <li><a name="toc-_0060_0060Where-do-I-report-a-bug_003f_0027_0027" href="#Where-do-I-report-a-bug_003f">13.1 “Where do I report a bug?”</a></li>
+ <li><a name="toc-Mailing-list-1" href="#Mailing-list">13.2 Mailing list</a></li>
+ <li><a name="toc-_0060_0060What-has-changed-between-ASDF-1_002c-ASDF-2_002c-and-ASDF-3_003f_0027_0027" href="#What-has-changed-between-ASDF-1-ASDF-2-and-ASDF-3_003f">13.3 “What has changed between ASDF 1, ASDF 2, and ASDF 3?”</a>
+ <ul class="no-bullet">
+ <li><a name="toc-What-are-ASDF-1_002c-ASDF-2_002c-and-ASDF-3_003f" href="#What-are-ASDF-1-2-3_003f">13.3.1 What are ASDF 1, ASDF 2, and ASDF 3?</a></li>
+ <li><a name="toc-How-do-I-detect-the-ASDF-version_003f-1" href="#How-do-I-detect-the-ASDF-version_003f">13.3.2 How do I detect the ASDF version?</a></li>
+ <li><a name="toc-ASDF-can-portably-name-files-in-subdirectories-1" href="#ASDF-can-portably-name-files-in-subdirectories">13.3.3 ASDF can portably name files in subdirectories</a></li>
+ <li><a name="toc-Output-translations-1" href="#Output-translations">13.3.4 Output translations</a></li>
+ <li><a name="toc-Source-Registry-Configuration-1" href="#Source-Registry-Configuration">13.3.5 Source Registry Configuration</a></li>
+ <li><a name="toc-Usual-operations-are-made-easier-to-the-user-1" href="#Usual-operations-are-made-easier-to-the-user">13.3.6 Usual operations are made easier to the user</a></li>
+ <li><a name="toc-Many-bugs-have-been-fixed-1" href="#Many-bugs-have-been-fixed">13.3.7 Many bugs have been fixed</a></li>
+ <li><a name="toc-ASDF-itself-is-versioned-1" href="#ASDF-itself-is-versioned">13.3.8 ASDF itself is versioned</a></li>
+ <li><a name="toc-ASDF-can-be-upgraded-1" href="#ASDF-can-be-upgraded">13.3.9 ASDF can be upgraded</a></li>
+ <li><a name="toc-Decoupled-release-cycle-1" href="#Decoupled-release-cycle">13.3.10 Decoupled release cycle</a></li>
+ <li><a name="toc-Pitfalls-of-the-transition-to-ASDF-2-1" href="#Pitfalls-of-the-transition-to-ASDF-2">13.3.11 Pitfalls of the transition to ASDF 2</a></li>
+ <li><a name="toc-Pitfalls-of-the-upgrade-to-ASDF-3-1" href="#Pitfalls-of-the-upgrade-to-ASDF-3">13.3.12 Pitfalls of the upgrade to ASDF 3</a></li>
+ <li><a name="toc-What-happened-to-the-bundle-operations_003f" href="#What-happened-to-the-bundle-operations">13.3.13 What happened to the bundle operations?</a></li>
+ </ul></li>
+ <li><a name="toc-Issues-with-installing-the-proper-version-of-ASDF-1" href="#Issues-with-installing-the-proper-version-of-ASDF">13.4 Issues with installing the proper version of ASDF</a>
+ <ul class="no-bullet">
+ <li><a name="toc-_0060_0060My-Common-Lisp-implementation-comes-with-an-outdated-version-of-ASDF_002e-What-to-do_003f_0027_0027" href="#My-Common-Lisp-implementation-comes-with-an-outdated-version-of-ASDF_002e-What-to-do_003f">13.4.1 “My Common Lisp implementation comes with an outdated version of ASDF. What to do?”</a></li>
+ <li><a name="toc-_0060_0060I_0027m-a-Common-Lisp-implementation-vendor_002e-When-and-how-should-I-upgrade-ASDF_003f_0027_0027" href="#I_0027m-a-Common-Lisp-implementation-vendor_002e-When-and-how-should-I-upgrade-ASDF_003f">13.4.2 “I’m a Common Lisp implementation vendor. When and how should I upgrade ASDF?”</a></li>
+ </ul></li>
+ <li><a name="toc-Issues-with-configuring-ASDF-1" href="#Issues-with-configuring-ASDF">13.5 Issues with configuring ASDF</a>
+ <ul class="no-bullet">
+ <li><a name="toc-_0060_0060How-can-I-customize-where-fasl-files-are-stored_003f_0027_0027" href="#How-can-I-customize-where-fasl-files-are-stored_003f">13.5.1 “How can I customize where fasl files are stored?”</a></li>
+ <li><a name="toc-_0060_0060How-can-I-wholly-disable-the-compiler-output-cache_003f_0027_0027" href="#How-can-I-wholly-disable-the-compiler-output-cache_003f">13.5.2 “How can I wholly disable the compiler output cache?”</a></li>
+ </ul></li>
+ <li><a name="toc-Issues-with-using-and-extending-ASDF-to-define-systems-1" href="#Issues-with-using-and-extending-ASDF-to-define-systems">13.6 Issues with using and extending ASDF to define systems</a>
+ <ul class="no-bullet">
+ <li><a name="toc-_0060_0060How-can-I-cater-for-unit_002dtesting-in-my-system_003f_0027_0027" href="#How-can-I-cater-for-unit_002dtesting-in-my-system_003f">13.6.1 “How can I cater for unit-testing in my system?”</a></li>
+ <li><a name="toc-_0060_0060How-can-I-cater-for-documentation-generation-in-my-system_003f_0027_0027" href="#How-can-I-cater-for-documentation-generation-in-my-system_003f">13.6.2 “How can I cater for documentation generation in my system?”</a></li>
+ <li><a name="toc-_0060_0060How-can-I-maintain-non_002dLisp-_0028e_002eg_002e-C_0029-source-files_003f_0027_0027" href="#How-can-I-maintain-non_002dLisp-_0028e_002eg_002e-C_0029-source-files_003f">13.6.3 “How can I maintain non-Lisp (e.g. C) source files?”</a></li>
+ <li><a name="toc-_0060_0060I-want-to-put-my-module_0027s-files-at-the-top-level_002e-How-do-I-do-this_003f_0027_0027" href="#I-want-to-put-my-module_0027s-files-at-the-top-level_002e-How-do-I-do-this_003f">13.6.4 “I want to put my module’s files at the top level. How do I do this?”</a></li>
+ <li><a name="toc-How-do-I-create-a-system-definition-where-all-the-source-files-have-a-_002ecl-extension_003f-1" href="#How-do-I-create-a-system-definition-where-all-the-source-files-have-a-_002ecl-extension_003f">13.6.5 How do I create a system definition where all the source files have a .cl extension?</a></li>
+ <li><a name="toc-How-do-I-mark-a-source-file-to-be-loaded-only-and-not-compiled_003f-1" href="#How-do-I-mark-a-source-file-to-be-loaded-only-and-not-compiled_003f">13.6.6 How do I mark a source file to be loaded only and not compiled?</a></li>
+ <li><a name="toc-How-do-I-work-with-readtables_003f-1" href="#How-do-I-work-with-readtables_003f">13.6.7 How do I work with readtables?</a>
+ <ul class="no-bullet">
+ <li><a name="toc-How-should-my-system-use-a-readtable-exported-by-another-system_003f" href="#How-should-my-system-use-a-readtable-exported-by-another-system_003f">13.6.7.1 How should my system use a readtable exported by another system?</a></li>
+ <li><a name="toc-How-should-my-library-make-a-readtable-available-to-other-systems_003f" href="#How-should-my-library-make-a-readtable-available-to-other-systems_003f">13.6.7.2 How should my library make a readtable available to other systems?</a></li>
+ </ul></li>
+ </ul></li>
+ <li><a name="toc-ASDF-development-FAQs-1" href="#ASDF-development-FAQs">13.7 ASDF development FAQs</a>
+ <ul class="no-bullet">
+ <li><a name="toc-How-do-I-run-the-tests-interactively-in-a-REPL_003f-1" href="#How-do-I-run-the-tests-interactively-in-a-REPL_003f">13.7.1 How do I run the tests interactively in a REPL?</a></li>
+ </ul></li>
+ </ul></li>
+ <li><a name="toc-Ongoing-Work-1" href="#Ongoing-Work">Ongoing Work</a></li>
+ <li><a name="toc-Bibliography-1" href="#Bibliography">Bibliography</a></li>
+ <li><a name="toc-Concept-Index-1" href="#Concept-Index">Concept Index</a></li>
+ <li><a name="toc-Function-and-Class-Index-1" href="#Function-and-Class-Index">Function and Class Index</a></li>
+ <li><a name="toc-Variable-Index-1" href="#Variable-Index">Variable Index</a></li>
+</ul>
+</div>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>You can find the latest version of this manual at
-<a href="http://common-lisp.net/project/asdf/asdf.html">http://common-lisp.net/project/asdf/asdf.html</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>ASDF Copyright © 2001-2013 Daniel Barlow and contributors.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>This manual Copyright © 2001-2013 Daniel Barlow and contributors.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>This manual revised © 2009-2013 Robert P. Goldman and Francois-Rene Rideau.
</span><span style="color: #000000;background-color: #ddffdd">+<a name="Top"></a>
+<a name="ASDF_003a-Another-System-Definition-Facility"></a>
+<h1 class="top">ASDF: Another System Definition Facility</h1>
+<p>Manual for Version 3.1.6
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Permission is hereby granted, free of charge, to any person obtaining
</span><span style="color: #000000;background-color: #ddffdd">+<p>This manual describes ASDF, a system definition facility
+for Common Lisp programs and libraries.
+</p>
+<p>You can find the latest version of this manual at
+<a href="https://common-lisp.net/project/asdf/asdf.html">https://common-lisp.net/project/asdf/asdf.html</a>.
+</p>
+<p>ASDF Copyright © 2001-2015 Daniel Barlow and contributors.
+</p>
+<p>This manual Copyright © 2001-2015 Daniel Barlow and contributors.
+</p>
+<p>This manual revised © 2009-2015 Robert P. Goldman and Francois-Rene Rideau.
+</p>
+<p>Permission is hereby granted, free of charge, to any person obtaining
</span> a copy of this software and associated documentation files (the
“Software”), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
<span style="color: #000000;background-color: #ffdddd">-
- <p>The above copyright notice and this permission notice shall be
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The above copyright notice and this permission notice shall be
</span> included in all copies or substantial portions of the Software.
<span style="color: #000000;background-color: #ffdddd">-
- <p>THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
</span> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
<span style="color: #000000;background-color: #ddffdd">+</p>
+
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- -->
-<p><a name="Introduction"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h2 class="chapter">1 Introduction</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-ASDF_002drelated-features-1"></a><a name="index-g_t_002afeatures_002a-2"></a><a name="index-Testing-for-ASDF-3"></a><a name="index-ASDF-versions-4"></a><a name="index-g_t_003aasdf-5"></a><a name="index-g_t_003aasdf2-6"></a><a name="index-g_t_003aasdf3-7"></a>
-ASDF is Another System Definition Facility:
</span><span style="color: #000000;background-color: #ddffdd">+
+<hr>
+<a name="Introduction"></a>
+<a name="Introduction-1"></a>
+<h2 class="chapter">1 Introduction</h2>
+<a name="index-ASDF_002drelated-features"></a>
+<a name="index-_002afeatures_002a-1"></a>
+<a name="index-Testing-for-ASDF"></a>
+<a name="index-ASDF-versions"></a>
+<a name="index-_003aasdf"></a>
+<a name="index-_003aasdf2"></a>
+<a name="index-_003aasdf3"></a>
+
+<p>ASDF is Another System Definition Facility:
</span> a tool for specifying how systems of Common Lisp software
<span style="color: #000000;background-color: #ffdddd">-are comprised of components (sub-systems and files),
</span><span style="color: #000000;background-color: #ddffdd">+are made up of components (sub-systems and files),
</span> and how to operate on these components in the right order
so that they can be compiled, loaded, tested, etc.
<span style="color: #000000;background-color: #ffdddd">-
- <p>ASDF presents three faces:
-one for users of Common Lisp software who want to reuse other people's code,
</span><span style="color: #000000;background-color: #ddffdd">+If you are new to ASDF, see <a href="#Quick-start-summary">the quick start
+guide</a>.
+</p>
+<p>ASDF presents three faces:
+one for users of Common Lisp software who want to reuse other people’s code,
</span> one for writers of Common Lisp software who want to specify how to build their systems,
<span style="color: #000000;background-color: #ffdddd">-one for implementers of Common Lisp extensions who want to extend the build system.
-See <a href="#Using-ASDF">Loading a system</a>,
-to learn how to use ASDF to load a system.
</span><span style="color: #000000;background-color: #ddffdd">+and one for implementers of Common Lisp extensions who want to extend
+the build system.
+For more specifics,
+see <a href="#Using-ASDF">Using ASDF</a>,
+to learn how to use ASDF to load a system.
</span> See <a href="#Defining-systems-with-defsystem">Defining systems with defsystem</a>,
<span style="color: #000000;background-color: #ffdddd">-to learn how to define a system of your own.
</span><span style="color: #000000;background-color: #ddffdd">+to learn how to define a system of your own.
</span> See <a href="#The-object-model-of-ASDF">The object model of ASDF</a>, for a description of
the ASDF internals and how to extend ASDF.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that
+ASDF is <em>not</em> a tool for library and system <em>installation</em>;
+it plays a role like <code>make</code> or <code>ant</code>, not like a package manager.
+In particular, ASDF should not to be confused with Quicklisp or ASDF-Install,
+that attempt to find and download ASDF systems for you.
+Despite what the name might suggest, ASDF-Install is not part of ASDF, but a separate piece of software.
+ASDF-Install is also unmaintained and obsolete.
+We recommend you use Quicklisp
+(<a href="http://www.quicklisp.org/">http://www.quicklisp.org/</a>) instead,
+a Common Lisp package manager which works well and is being actively maintained.
+If you want to download software from version control instead of tarballs,
+so you may more easily modify it, we recommend clbuild (<a href="http://common-lisp.net/project/clbuild/">http://common-lisp.net/project/clbuild/</a>).
+We recommend <samp>~/common-lisp/</samp>
+as a place into which to install Common Lisp software;
+starting with ASDF 3.1.2, it is included in the default source-registry configuration.
+</p>
+<p>Finally, note that this manual is incomplete.
+All the bases are covered,
+but many advanced topics are only barely alluded to,
+and there is not much in terms of examples.
+The source code remains the ultimate source of information,
+free software systems in Quicklisp remain the best source of examples,
+and the mailing-list the best place to ask for help.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><em>Nota Bene</em>:
-We have released ASDF 2.000 on May 31st 2010,
-and ASDF 3.0 on January 31st 2013.
-Releases of ASDF 2 and later have since then been included
-in all actively maintained CL implementations that used to bundle ASDF 1,
-plus some implementations that didn't use to,
-and has been made to work with all actively used CL implementations and a few more.
-See <a href="#FAQ">“What has changed between ASDF 1 and ASDF 2?”</a>.
-Furthermore, it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly.
-For this reason, we have stopped supporting ASDF 1 and ASDF 2.
-If you are using ASDF 1 or ASDF 2 and are experiencing any kind of issues or limitations,
-we recommend you upgrade to ASDF 3
-— and we explain how to do that. See <a href="#Loading-ASDF">Loading ASDF</a>.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Quick-start-summary"></a>
+<a name="Quick-start-summary-1"></a>
+<h2 class="chapter">2 Quick start summary</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Also note that ASDF is not to be confused with ASDF-Install.
-ASDF-Install is not part of ASDF, but a separate piece of software.
-ASDF-Install is also unmaintained and obsolete.
-We recommend you use Quicklisp instead,
-which works great and is being actively maintained.
-If you want to download software from version control instead of tarballs,
-so you may more easily modify it, we recommend clbuild.
</span><span style="color: #000000;background-color: #ddffdd">+<ul>
+<li> To load an ASDF system:
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Loading-ASDF"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<ul>
+<li> Load ASDF itself into your Lisp image, using
+<code>(require "asdf")</code>.
+Check that you have a recent version using <code>(asdf:asdf-version)</code>.
+For more details, or if any of the above fails, see <a href="#Loading-ASDF">Loading ASDF</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h2 class="chapter">2 Loading ASDF</h2>
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Make sure software is installed where ASDF can find it.
+The simplest way is to put all your Lisp code in subdirectories of
+<samp>~/common-lisp/</samp> (starting with ASDF 3.1.2),
+or <samp>~/.local/share/common-lisp/source/</samp>
+(for ASDF 2 and later, or if you want to keep source in a hidden directory).
+For more details, see <a href="#Configuring-ASDF-to-find-your-systems">Configuring ASDF to find your systems</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-g_t_002acentral_002dregistry_002a-8"></a><a name="index-link-farm-9"></a><a name="index-load_002dsystem-10"></a><a name="index-require_002dsystem-11"></a><a name="index-compile_002dsystem-12"></a><a name="index-test_002dsystem-13"></a><a name="index-system-directory-designator-14"></a><a name="index-operate-15"></a><a name="index-oos-16"></a>
-<!-- @menu -->
-<!-- * Installing ASDF:: -->
-<!-- @end menu -->
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Load your system with <code>(asdf:load-system "<var>my-system</var>")</code>.
+See <a href="#Using-ASDF">Using ASDF</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">2.1 Loading a pre-installed ASDF</h3>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Most recent Lisp implementations include a copy of ASDF 2, and soon ASDF 3.
-You can usually load this copy using Common Lisp's <code>require</code> function:
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> To make your own ASDF system:
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (require "asdf")
-</pre>
- <p>As of the writing of this manual,
-the following implementations provide ASDF 2 this way:
-abcl allegro ccl clisp cmucl ecl lispworks mkcl sbcl xcl.
-The following implementation doesn't provide it yet but will in an upcoming release:
-scl.
-The following implementations are obsolete, not actively maintained,
-and most probably will never bundle it:
-cormanlisp gcl genera mcl.
-
- <p>If the implementation you are using doesn't provide ASDF 2 or ASDF 3,
-see see <a href="#Loading-ASDF">Loading an otherwise installed ASDF</a> below.
-If that implementation is still actively maintained,
-you may also send a bug report to your Lisp vendor and complain
-about their failing to provide ASDF.
-
- <p>NB: all implementations except clisp also accept
-<code>(require "ASDF")</code>, <code>(require 'asdf)</code> and <code>(require :asdf)</code>.
-For portability's sake, you probably want to use <code>(require "asdf")</code>.
-
-<h3 class="section">2.2 Checking whether ASDF is loaded</h3>
-
-<p>To check whether ASDF is properly loaded in your current Lisp image,
-you can run this form:
-
-<pre class="lisp"> (asdf:asdf-version)
-</pre>
- <p>If it returns a string,
-that is the version of ASDF that is currently installed.
</span><span style="color: #000000;background-color: #ddffdd">+<ul>
+<li> As above, load and configure ASDF.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If it raises an error,
-then either ASDF is not loaded, or
-you are using an old version of ASDF.
-
- <p>You can check whether an old version is loaded
-by checking if the ASDF package is present.
-The form below will allow you to programmatically determine
-whether a recent version is loaded, an old version is loaded,
-or none at all:
-
-<pre class="lisp"> (when (find-package :asdf)
- (let ((ver (symbol-value (or (find-symbol (string :*asdf-version*) :asdf)
- (find-symbol (string :*asdf-revision*) :asdf)))))
- (etypecase ver
- (string ver)
- (cons (with-output-to-string (s)
- (loop for (n . m) on ver do (princ n s) (when m (princ "." s)))))
- (null "1.0"))))
-</pre>
- <p>If it returns <code>nil</code> then ASDF is not installed.
-Otherwise it should return a string.
-If it returns <code>"1.0"</code>, then it can actually be
-any version before 1.77 or so, or some buggy variant of 1.x.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Make a new directory for your system, <code><var>my-system</var>/</code>,
+again in a location where ASDF can find it.
+All else being equal, the easiest location is probably
+<samp>~/common-lisp/my-system/</samp>.
+See <a href="#Configuring-ASDF-to-find-your-systems">Configuring ASDF to find your systems</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If you are experiencing problems with ASDF,
-please try upgrading to the latest released version,
-using the method below,
-before you contact us and raise an issue.
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">2.3 Upgrading ASDF</h3>
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Create an ASDF system definition listing the dependencies of
+your system, its components, and their interdependencies,
+and put it in <samp><var>my-system</var>.asd</samp>.
+This file must have the same name as your system, all lowercase.
+See <a href="#Defining-systems-with-defsystem">Defining systems with defsystem</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>If your implementation provides ASDF 3 or later,
-you only need to <code>(require "asdf")</code>:
-ASDF will automatically look whether an updated version of itself is available
-amongst the regularly configured systems, before it compiles anything else.
-See see <a href="#Configuring-ASDF">Configuring ASDF</a> below.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Use <code>(asdf:load-system "<var>my-system</var>")</code>
+to make sure it’s all working properly. See <a href="#Using-ASDF">Using ASDF</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If your implementation does provide ASDF 2 or later,
-but not ASDF 3 or later,
-and you want to upgrade to a more recent version,
-you need to install and configure your ASDF as above,
-and additionally, you need to explicitly tell ASDF to load itself,
-right after you require your implementation's old ASDF 2:
</span><span style="color: #000000;background-color: #ddffdd">+</li></ul>
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (require "asdf")
- (asdf:load-system :asdf)
-</pre>
- <p>If on the other hand, your implementation only provides an old ASDF,
-you will require a special configuration step and an old-style loading.
-Take special attention to not omit the trailing directory separator
-<code>/</code> at the end of your pathname:
-
-<pre class="lisp"> (require "asdf")
- (push #p"<var>/path/to/new/asdf/</var>" asdf:*central-registry*)
- (asdf:oos 'asdf:load-op :asdf)
-</pre>
- <p>Note that ASDF 1 won't redirect its output files,
-or at least won't do it according to your usual ASDF 2 configuration.
-You therefore need write access on the directory
-where you install the new ASDF,
-and make sure you're not using it
-for multiple mutually incompatible implementations.
-At worst, you may have to have multiple copies of the new ASDF,
-e.g. one per implementation installation, to avoid clashes.
-Note that to our knowledge all implementations that provide ASDF
-provide ASDF 2 in their latest release, so
-you may want to upgrade your implementation rather than go through that hoop.
-
- <p>Finally, if you are using an unmaintained implementation
-that does not provide ASDF at all,
-see see <a href="#Loading-ASDF">Loading an otherwise installed ASDF</a> below.
-
- <p>Note that there are some limitations to upgrading ASDF:
- <ul>
-<li>Previously loaded ASDF extension becomes invalid, and will need to be reloaded.
-This applies to e.g. CFFI-Grovel, or to hacks used by ironclad, etc.
-Since it isn't possible to automatically detect what extensions are present
-that need to be invalidated,
-ASDF will actually invalidate all previously loaded systems
-when it is loaded on top of a different ASDF version,
-starting with ASDF 2.014.8 (as far as releases go, 2.015);
-and it will automatically attempt this self-upgrade as its very first step
-starting with ASDF 3.
-
- <li>For this an many other reasons,
-it important reason to load, configure and upgrade ASDF (if needed)
-as one of the very first things done by your build and startup scripts.
-Until all implementations provide ASDF 3 or later,
-it is safer if you upgrade ASDF and its extensions as a special step
-at the very beginning of whatever script you are running,
-before you start using ASDF to load anything else;
-even afterwards, it is still a good idea, to avoid having to
-load and reload code twice as it gets invalidated.
-
- <li>Until all implementations provide ASDF 3 or later,
-it is unsafe to upgrade ASDF as part of loading a system
-that depends on a more recent version of ASDF,
-since the new one might shadow the old one while the old one is running,
-and the running old one will be confused
-when extensions are loaded into the new one.
-In the meantime, we recommend that your systems should <em>not</em> specify
-<code>:depends-on (:asdf)</code>, or <code>:depends-on ((:version :asdf "2.010"))</code>,
-but instead that they check that a recent enough ASDF is installed,
-with such code as:
- <pre class="example"> (unless (or #+asdf2 (asdf:version-satisfies
- (asdf:asdf-version) *required-asdf-version*))
- (error "FOO requires ASDF ~A or later." *required-asdf-version*))
-</pre>
- <li>Until all implementations provide ASDF 3 or later,
-it is unsafe for a system to transitively depend on ASDF
-and not directly depend on ASDF;
-if any of the system you use either depends-on asdf,
-system-depends-on asdf, or transitively does,
-you should also do as well.
-</ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">2.4 Loading an otherwise installed ASDF</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>If your implementation doesn't include ASDF,
-if for some reason the upgrade somehow fails,
-does not or cannot apply to your case,
-you will have to install the file <samp><span class="file">asdf.lisp</span></samp>
-somewhere and load it with:
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (load "/path/to/your/installed/asdf.lisp")
-</pre>
- <p>The single file <samp><span class="file">asdf.lisp</span></samp> is all you normally need to use ASDF.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>You can extract this file from latest release tarball on the
-<a href="http://common-lisp.net/project/asdf/">ASDF website</a>.
-If you are daring and willing to report bugs, you can get
-the latest and greatest version of ASDF from its git repository.
-See <a href="#Getting-the-latest-version">Getting the latest version</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>For maximum convenience you might want to have ASDF loaded
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Loading-ASDF"></a>
+<a name="Loading-ASDF-1"></a>
+<h2 class="chapter">3 Loading ASDF</h2>
+
+
+<hr>
+<a name="Loading-a-pre_002dinstalled-ASDF"></a>
+<a name="Loading-a-pre_002dinstalled-ASDF-1"></a>
+<h3 class="section">3.1 Loading a pre-installed ASDF</h3>
+
+<p>The recommended way to load ASDF is via:
+</p><div class="lisp">
+<pre class="lisp">(require "asdf")
+</pre></div>
+
+<p>All actively maintained Lisp implementations now include a copy of ASDF 3
+that you can load this way using Common Lisp’s <code>require</code> function.<a name="DOCF1" href="#FOOT1"><sup>1</sup></a>
+</p>
+<p>If the implementation you are using doesn’t provide a recent ASDF 3,
+we recommend you upgrade it.
+If for some reason you would rather not upgrade it,
+we recommend you replace your implementation’s ASDF.
+See <a href="#Replacing-your-implementation_0027s-ASDF">Replacing your implementation's ASDF</a>.
+If all else fails, see see <a href="#Loading-ASDF-from-source">Loading ASDF from source</a> below.
+</p>
+<p>If you use an actively maintained implementation that fails to provide
+an up-to-date enough stable release of ASDF,
+you may also send a bug report to your Lisp vendor and complain about it
+— or you may fix the issue yourself if it’s free software.
+</p>
+<p>As of the writing of this manual,
+the following implementations provide ASDF 3 this way:
+ABCL, Allegro CL, CLASP, Clozure CL, CMUCL, ECL, GNU CLISP, LispWorks, MKCL, SBCL.
+The following implementations only provide ASDF 2:
+MOCL, XCL.
+The following implementations don’t provide ASDF:
+Corman CL, GCL, Genera, MCL, SCL.
+The latter implementations are not actively maintained (except maybe GCL);
+if some of them are ever released again, they probably will include ASDF 3.
+</p>
+<p>For maximum convenience you might want to have ASDF loaded
</span> whenever you start your Lisp implementation,
for example by loading it from the startup script or dumping a custom core
<span style="color: #000000;background-color: #ffdddd">-— check your Lisp implementation's manual for details.
</span><span style="color: #000000;background-color: #ddffdd">+— check your Lisp implementation’s manual for details.
+SLIME notably sports a <code>slime-asdf</code> contrib that makes life easier with ASDF.
+</p>
+
+<hr>
+<a name="Checking-whether-ASDF-is-loaded"></a>
+<a name="Checking-whether-ASDF-is-loaded-1"></a>
+<h3 class="section">3.2 Checking whether ASDF is loaded</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Configuring-ASDF"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<p>To check that ASDF is properly loaded, you can run this form:
+</p>
+<div class="lisp">
+<pre class="lisp">(asdf:asdf-version)
+</pre></div>
+
+<p>If it returns a string,
+that is the version of ASDF that is currently installed.
+If that version is suitably recent (say, 3.1.2 or later),
+then you can skip directly to next chapter: See <a href="#Configuring-ASDF">Configuring ASDF</a>.
+</p>
+<p>If it raises an error,
+then either ASDF is not loaded, or
+you are using a very old version of ASDF,
+and need to install ASDF 3.
+</p>
+<p>For more precision in detecting versions old and new,
+see <a href="#How-do-I-detect-the-ASDF-version_003f">How do I detect the ASDF version?</a>.
+</p>
+<p>If you are experiencing problems with ASDF,
+please try upgrading to the latest released version,
+using the method below,
+before you contact us and raise an issue.
+</p>
+<hr>
+<a name="Upgrading-ASDF"></a>
+<a name="Upgrading-ASDF-1"></a>
+<h3 class="section">3.3 Upgrading ASDF</h3>
+
+<p>If your implementation already provides ASDF 3 or later (and it should),
+but you want a more recent ASDF version than your implementation provides,
+then you just need to ensure the more recent ASDF is installed in a configured path, like any other system.
+We recommend you download an official tarball or checkout a release from git into
+<samp>~/common-lisp/asdf/</samp>.
+(see <a href="#Configuring-ASDF-to-find-your-systems">Configuring ASDF to find your systems</a>).
+</p>
+<p>Once the source code for ASDF is installed,
+you don’t need any extra step to load it beyond the usual <code>(require "asdf")</code>:
+ASDF 3 will automatically look whether an updated version of itself is available
+amongst the regularly configured systems, before it compiles anything else.
+</p>
+<p>If your implementation fails to provide ASDF 3 or later,
+see <a href="#Replacing-your-implementation_0027s-ASDF">Replacing your implementation's ASDF</a>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h2 class="chapter">3 Configuring ASDF</h2>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Replacing-your-implementation_0027s-ASDF"></a>
+<a name="Replacing-your-implementation_0027s-ASDF-1"></a>
+<h3 class="section">3.4 Replacing your implementation’s ASDF</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">3.1 Configuring ASDF to find your systems</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<p>All maintained implementations now provide ASDF 3 in their latest release.
+If your doesn’t, we recommend you upgrade it.
+</p>
+<p>Now, if you insist on using an old implementation that didn’t provide ASDF or provided an old version,
+we recommend installing a recent ASDF, as explained below,
+into your implementation’s installation directory.
+Thus your modified implementation will now provide ASDF 3.
+This requires proper write permissions and may necessitate execution as a system administrator.
+</p>
+<p>The ASDF source repository contains a tool to help you upgrade your implementation’s ASDF.
+You can invoke it from the shell command-line as
+<code>tools/asdf-tools install-asdf lispworks</code>
+(where you can replace <code>lispworks</code> by the name of the relevant implementation),
+or you can <code>(load "tools/install-asdf.lisp")</code> from your Lisp REPL.
+</p>
+<p>This script works on
+Allegro CL, Clozure CL, CMU CL, ECL, GCL, GNU CLISP, LispWorks, MKCL, SBCL, SCL, XCL.
+It doesn’t work on ABCL, Corman CL, Genera, MCL, MOCL.
+Happily, ABCL is usually pretty up to date and shouldn’t need that script.
+GCL requires a very recent version, and hasn’t been tested much.
+Corman CL, Genera, MCL are obsolete anyway.
+MOCL is incomplete.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>So it may compile and load your systems, ASDF must be configured to find
-the <samp><span class="file">.asd</span></samp> files that contain system definitions.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Loading-ASDF-from-source"></a>
+<a name="Loading-ASDF-from-source-1"></a>
+<h3 class="section">3.5 Loading ASDF from source</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Since ASDF 2, the preferred way to configure where ASDF finds your systems is
-the <code>source-registry</code> facility,
-fully described in its own chapter of this manual.
-See <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a>.
</span><span style="color: #000000;background-color: #ddffdd">+<p>If you write build scripts that must remain portable to old machines with old implementations
+that you cannot ensure have been upgraded or modified to provide a recent ASDF,
+you may have to install the file <samp>asdf.lisp</samp>
+somewhere and load it with:
+</p>
+<div class="lisp">
+<pre class="lisp">(load "/path/to/your/installed/asdf.lisp")
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The default location for a user to install Common Lisp software is under
-<samp><span class="file">~/.local/share/common-lisp/source/</span></samp>.
-If you install software there (it can be a symlink),
-you don't need further configuration.
-If you're installing software yourself at a location that isn't standard,
-you have to tell ASDF where you installed it. See below.
-If you're using some tool to install software (e.g. Quicklisp),
-the authors of that tool should already have configured ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+<p>The single file <samp>asdf.lisp</samp> is all you normally need to use ASDF.
+</p>
+<p>You can extract this file from latest release tarball on the
+<a href="https://common-lisp.net/project/asdf/">ASDF website</a>.
+If you are daring and willing to report bugs, you can get
+the latest and greatest version of ASDF from its git repository.
+See <a href="#Getting-the-latest-version">Getting the latest version</a>.
+</p>
+<p>For scripts that try to use ASDF simply via <code>require</code> at first, and
+make heroic attempts to load it the hard way if at first they don’t succeed,
+see <samp>tools/load-asdf.lisp</samp> distributed with the ASDF source repository,
+or the code of <a href="https://cliki.net/cl-launch"><code>cl-launch</code></a>.
+</p>
+
+<hr>
+<a name="Configuring-ASDF"></a>
+<a name="Configuring-ASDF-1"></a>
+<h2 class="chapter">4 Configuring ASDF</h2>
+
+<p>For standard use cases, ASDF should work pretty much out of the box.
+We recommend you skim the sections on configuring ASDF to find your systems
+and choose the method of installing Lisp software that works best for you.
+Then skip directly to See <a href="#Using-ASDF">Using ASDF</a>. That will probably be enough.
+You are unlikely to have to worry about the way ASDF stores object files,
+and resetting the ASDF configuration is usually only needed in corner cases.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The simplest way to add a path to your search path,
-say <samp><span class="file">/home/luser/.asd-link-farm/</span></samp>
-is to create the directory
-<samp><span class="file">~/.config/common-lisp/source-registry.conf.d/</span></samp>
-and there create a file with any name of your choice,
-and with the type <samp><span class="file">conf</span></samp>,
-for instance <samp><span class="file">42-asd-link-farm.conf</span></samp>
-containing the line:
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><kbd>(:directory "/home/luser/.asd-link-farm/")</kbd>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Configuring-ASDF-to-find-your-systems"></a>
+<a name="Configuring-ASDF-to-find-your-systems-1"></a>
+<h3 class="section">4.1 Configuring ASDF to find your systems</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If you want all the subdirectories under <samp><span class="file">/home/luser/lisp/</span></samp>
-to be recursively scanned for <samp><span class="file">.asd</span></samp> files, instead use:
</span><span style="color: #000000;background-color: #ddffdd">+<p>In order to compile and load your systems, ASDF must be configured to find
+the <samp>.asd</samp> files that contain system definitions.
+</p>
+<p>There are a number of different techniques for setting yourself up with
+ASDF, starting from easiest to the most complex:
+</p>
+<ul>
+<li> Put all of your systems in one of the standard locations,
+subdirectories of
+<ul>
+<li> <samp>~/common-lisp/</samp> or
+</li><li> <samp>~/.local/share/common-lisp/source/</samp>.
+</li></ul>
+<p>If you install software there, you don’t need further
+configuration.<a name="DOCF2" href="#FOOT2"><sup>2</sup></a>
+You can then skip to the next section. See <a href="#Loading-a-system">Loading a system</a>.
+</p>
+</li><li> If you’re using some tool to install software (e.g. Quicklisp),
+the authors of that tool should already have configured ASDF.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><kbd>(:tree "/home/luser/lisp/")</kbd>
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If you have more specific desires about how to lay out your software on
+disk, the preferred way to configure where ASDF finds your systems is
+the <code>source-registry</code> facility,
+fully described in its own chapter of this manual.
+See <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a>.
+Here is a quick recipe for getting started.
+
+<p>First create the directory
+<samp>~/.config/common-lisp/source-registry.conf.d/</samp><a name="DOCF3" href="#FOOT3"><sup>3</sup></a>;
+there create a file with any name of your choice
+but with the type <samp>conf</samp><a name="DOCF4" href="#FOOT4"><sup>4</sup></a>,
+for instance <samp>50-luser-lisp.conf</samp>;
+in this file, add the following line
+to tell ASDF to recursively scan all the subdirectories under <samp>/home/luser/lisp/</samp>
+for <samp>.asd</samp> files:
+<kbd>(:tree "/home/luser/lisp/")</kbd>
+</p>
+<p>That’s enough. You may replace <samp>/home/luser/lisp/</samp> by wherever you want to install your source code.
+You don’t actually need to specify anything if you use the default <samp>~/common-lisp/</samp> as above
+and your implementation provides ASDF 3.1.2 or later.
+If your implementation provides an earlier variant of ASDF 3,
+you might want to specify <kbd>(:tree (:home "common-lisp/"))</kbd> for bootstrap purposes,
+then install a recent source tree of ASDF under <samp>~/common-lisp/asdf/</samp>.
+</p>
+<p>If you prefer to use a “link farm”, which is faster to use but costlier to manage than a recursive traversal,
+say at <samp>/home/luser/.asd-link-farm/</samp>, then
+you may instead (or additionally) create a file <samp>42-asd-link-farm.conf</samp>, containing the line:
+<kbd>(:directory "/home/luser/.asd-link-farm/")</kbd>
+</p>
+<p>ASDF will automatically read your configuration
+the first time you try to find a system.
+If necessary, you can reset the source-registry configuration with:
+</p>
+<div class="lisp">
+<pre class="lisp">(asdf:clear-source-registry)
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Note that your Operating System distribution or your system administrator
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> In earlier versions of ASDF, the system source registry was configured
+using a global variable, <code>asdf:*central-registry*</code>.
+For more details about this, see the following section,
+<a href="#Configuring-ASDF-to-find-your-systems-_002d_002d_002d-old-style">Configuring ASDF to find your systems --- old style</a>.
+Unless you need to understand this,
+skip directly to <a href="#Configuring-where-ASDF-stores-object-files">Configuring where ASDF stores object files</a>.
+
+</li></ul>
+
+<p>Note that your Operating System distribution or your system administrator
</span> may already have configured system-managed libraries for you.
<span style="color: #000000;background-color: #ddffdd">+</p>
+
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The required <samp><span class="file">.conf</span></samp> extension allows you to have disabled files
-or editor backups (ending in <samp><span class="file">~</span></samp>), and works portably
-(for instance, it is a pain to allow both empty and non-empty extension on CLISP).
-Excluded are files the name of which start with a <samp><span class="file">.</span></samp> character.
-It is customary to start the filename with two digits
-that specify the order in which the directories will be scanned.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Configuring-ASDF-to-find-your-systems-_002d_002d_002d-old-style"></a>
+<a name="Configuring-ASDF-to-find-your-systems-_002d_002d_002d-old-style-1"></a>
+<h3 class="section">4.2 Configuring ASDF to find your systems — old style</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>ASDF will automatically read your configuration
-the first time you try to find a system.
-You can reset the source-registry configuration with:
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (asdf:clear-source-registry)
-</pre>
- <p>And you probably should do so before you dump your Lisp image,
-if the configuration may change
-between the machine where you save it at the time you save it
-and the machine you resume it at the time you resume it.
-Actually, you should use <code>(asdf:clear-configuration)</code>
-before you dump your Lisp image, which includes the above.
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">3.2 Configuring ASDF to find your systems — old style</h3>
</span>
<p>The old way to configure ASDF to find your systems is by
<code>push</code>ing directory pathnames onto the variable
<code>asdf:*central-registry*</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>You must configure this variable between the time you load ASDF
-and the time you first try to use it.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>You must configure this variable between the time you load ASDF
+and the time you first try to use it.
</span> Loading and configuring ASDF presumably happen
as part of some initialization script that builds or starts
<span style="color: #000000;background-color: #ffdddd">-your Common Lisp software system.
-(For instance, some SBCL users used to put it in their <samp><span class="file">~/.sbclrc</span></samp>.)
-
- <p>The <code>asdf:*central-registry*</code> is empty by default in ASDF 2 or ASDF 3,
-but is still supported for compatibility with ASDF 1.
-When used, it takes precedence over the above source-registry<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a>.
-
- <p>For instance, if you wanted ASDF to find the <samp><span class="file">.asd</span></samp> file
-<samp><span class="file">/home/me/src/foo/foo.asd</span></samp> your initialization script
-could after it loads ASDF with <code>(require "asdf")</code>
-configure it with:
</span><span style="color: #000000;background-color: #ddffdd">+your Common Lisp software system.
+(For instance, some SBCL users used to put it in their <samp>~/.sbclrc</samp>.)
+</p>
+<p>The <code>asdf:*central-registry*</code> is empty by default in ASDF 2 or ASDF 3,
+but is still supported for compatibility with ASDF 1.
+When used, it takes precedence over the above source-registry.<a name="DOCF5" href="#FOOT5"><sup>5</sup></a>
+</p>
+<p>For example, let’s say you want ASDF to find the <samp>.asd</samp> file
+<samp>/home/me/src/foo/foo.asd</samp>.
+In your lisp initialization file, you could have the following:
+</p>
+<div class="lisp">
+<pre class="lisp">(require "asdf")
+(push "/home/me/src/foo/" asdf:*central-registry*)
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (push "/home/me/src/foo/" asdf:*central-registry*)
-</pre>
- <p>Note the trailing slash: when searching for a system,
</span><span style="color: #000000;background-color: #ddffdd">+<p>Note the trailing slash: when searching for a system,
</span> ASDF will evaluate each entry of the central registry
<span style="color: #000000;background-color: #ffdddd">-and coerce the result to a pathname<a rel="footnote" href="#fn-2" name="fnd-2"><sup>2</sup></a>
-at which point the presence of the trailing directory name separator
-is necessary to tell Lisp that you're discussing a directory
-rather than a file.
-
- <p>Typically, however, there are a lot of <samp><span class="file">.asd</span></samp> files, and
-a common idiom was to have to put
-a bunch of <em>symbolic links</em> to <samp><span class="file">.asd</span></samp> files
</span><span style="color: #000000;background-color: #ddffdd">+and coerce the result to a pathname.<a name="DOCF6" href="#FOOT6"><sup>6</sup></a>
+The trailing directory name separator
+is necessary to tell Lisp that you’re discussing a directory
+rather than a file. If you leave it out, ASDF is likely to look in
+<code>/home/me/src/</code> instead of <code>/home/me/src/foo/</code> as you
+intended, and fail to find your system definition.
+</p>
+<p>Typically there are a lot of <samp>.asd</samp> files, and
+a common idiom was to put
+<em>symbolic links</em> to all of one’s <samp>.asd</samp> files
</span> in a common directory
and push <em>that</em> directory (the “link farm”)
<span style="color: #000000;background-color: #ffdddd">-to the
-<code>asdf:*central-registry*</code>
-instead of pushing each of the many involved directories
-to the <code>asdf:*central-registry*</code>.
-ASDF knows how to follow such <em>symlinks</em>
-to the actual file location when resolving the paths of system components
-(on Windows, you can use Windows shortcuts instead of POSIX symlinks;
-if you try aliases under MacOS, we are curious to hear about your experience).
-
- <p>For example, if <code>#p"/home/me/cl/systems/"</code> (note the trailing slash)
-is a member of <code>*central-registry*</code>, you could set up the
-system <var>foo</var> for loading with asdf with the following
-commands at the shell:
-
-<pre class="example"> $ cd /home/me/cl/systems/
- $ ln -s ~/src/foo/foo.asd .
-</pre>
- <p>This old style for configuring ASDF is not recommended for new users,
-but it is supported for old users, and for users who want to programmatically
-control what directories are added to the ASDF search path.
</span><span style="color: #000000;background-color: #ddffdd">+onto
+<code>asdf:*central-registry*</code>,
+instead of pushing each individual system directory.
+</p>
+<p>ASDF knows to follow <em>symlinks</em>
+to the actual location of the systems.<a name="DOCF7" href="#FOOT7"><sup>7</sup></a>
+</p>
+<p>For example, if <code>#p"/home/me/cl/systems/"</code>
+is an element of <code>*central-registry*</code>, you could set up the
+system <var>foo</var> as follows:
+</p>
+<div class="example">
+<pre class="example">$ cd /home/me/cl/systems/
+$ ln -s ~/src/foo/foo.asd .
+</pre></div>
+
+<p>This old style for configuring ASDF is not recommended for new users,
+but it is supported for old users, and for users who want a simple way to
+programmatically control what directories are added to the ASDF search path.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">3.3 Configuring where ASDF stores object files</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Configuring-where-ASDF-stores-object-files"></a>
+<a name="Configuring-where-ASDF-stores-object-files-1"></a>
+<h3 class="section">4.3 Configuring where ASDF stores object files</h3>
+<a name="index-clear_002doutput_002dtranslations"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-clear_002doutput_002dtranslations-17"></a>
-ASDF lets you configure where object files will be stored.
</span><span style="color: #000000;background-color: #ddffdd">+<p>ASDF lets you configure where object files will be stored.
</span> Sensible defaults are provided and
<span style="color: #000000;background-color: #ffdddd">-you shouldn't normally have to worry about it.
-
- <p>This allows the same source code repository may be shared
</span><span style="color: #000000;background-color: #ddffdd">+you shouldn’t normally have to worry about it.
+</p>
+<p>This allows the same source code repository to be shared
</span> between several versions of several Common Lisp implementations,
<span style="color: #000000;background-color: #ffdddd">-between several users using different compilation options
-and without write privileges on shared source directories, etc.
-This also allows to keep source directories uncluttered
-by plenty of object files.
-
- <p>Starting with ASDF 2, the <code>asdf-output-translations</code> facility
-was added to ASDF itself, that controls where object files will be stored.
</span><span style="color: #000000;background-color: #ddffdd">+between several users using different compilation options,
+with users who lack write privileges on shared source directories, etc.
+This also keeps source directories from being cluttered
+with object/fasl files.
+</p>
+<p>Starting with ASDF 2, the <code>asdf-output-translations</code> facility
+was added to ASDF itself. This facility controls where object files will be stored.
</span> This facility is fully described in a chapter of this manual,
<a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a>.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The simplest way to add a translation to your search path,
-say from <samp><span class="file">/foo/bar/baz/quux/</span></samp>
-to <samp><span class="file">/where/i/want/my/fasls/</span></samp>
-is to create the directory
-<samp><span class="file">~/.config/common-lisp/asdf-output-translations.conf.d/</span></samp>
-and there create a file with any name of your choice and the type <samp><span class="file">conf</span></samp>,
-for instance <samp><span class="file">42-bazquux.conf</span></samp>
-containing the line:
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><kbd>("/foo/bar/baz/quux/" "/where/i/want/my/fasls/")</kbd>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>To disable output translations for source under a given directory,
-say <samp><span class="file">/toto/tata/</span></samp>
-you can create a file <samp><span class="file">40-disable-toto.conf</span></samp>
-with the line:
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><kbd>("/toto/tata/")</kbd>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>To wholly disable output translations for all directories,
-you can create a file <samp><span class="file">00-disable.conf</span></samp>
-with the line:
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><kbd>(t t)</kbd>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Note that your Operating System distribution or your system administrator
-may already have configured translations for you.
-In absence of any configuration, the default is to redirect everything
-under an implementation-dependent subdirectory of <samp><span class="file">~/.cache/common-lisp/</span></samp>.
-See <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a>, for full details.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The required <samp><span class="file">.conf</span></samp> extension allows you to have disabled files
-or editor backups (ending in <samp><span class="file">~</span></samp>), and works portably
-(for instance, it is a pain to allow both empty and non-empty extension on CLISP).
-Excluded are files the name of which start with a <samp><span class="file">.</span></samp> character.
-It is customary to start the filename with two digits
-that specify the order in which the directories will be scanned.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>ASDF will automatically read your configuration
-the first time you try to find a system.
-You can reset the source-registry configuration with:
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (asdf:clear-output-translations)
-</pre>
- <p>And you probably should do so before you dump your Lisp image,
-if the configuration may change
-between the machine where you save it at the time you save it
-and the machine you resume it at the time you resume it.
-(Once again, you should use <code>(asdf:clear-configuration)</code>
-before you dump your Lisp image, which includes the above.)
-
- <p>Finally note that before ASDF 2,
</span><span style="color: #000000;background-color: #ddffdd">+
+<p>Note that before ASDF 2,
</span> other ASDF add-ons offered the same functionality,
each in subtly different and incompatible ways:
<span style="color: #000000;background-color: #ffdddd">-ASDF-Binary-Locations, cl-launch, common-lisp-controller.
-ASDF-Binary-Locations is now not needed anymore and should not be used.
</span><span style="color: #000000;background-color: #ddffdd">+ASDF-Binary-Locations, cl-launch, common-lisp-controller.
+ASDF-Binary-Locations is now not needed anymore and should not be used.
</span> cl-launch 3.000 and common-lisp-controller 7.2 have been updated
<span style="color: #000000;background-color: #ffdddd">-to just delegate this functionality to ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+to delegate object file placement to ASDF.
+</p>
+<hr>
+<a name="Resetting-the-ASDF-configuration"></a>
+<a name="Resetting-the-ASDF-configuration-1"></a>
+<h3 class="section">4.4 Resetting the ASDF configuration</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Using-ASDF"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h3 class="section">3.4 Resetting Configuration</h3>
</span>
<p>When you dump and restore an image, or when you tweak your configuration,
<span style="color: #000000;background-color: #ffdddd">-you may want to reset the ASDF configuration.
</span><span style="color: #000000;background-color: #ddffdd">+you may want to reset the ASDF configuration.
</span> For that you may use the following function:
<span style="color: #000000;background-color: #ddffdd">+</p>
+<dl>
+<dt><a name="index-clear_002dconfiguration"></a>Function: <strong>clear-configuration</strong></dt>
+<dd><p>Undoes any ASDF configuration
+ regarding source-registry or output-translations.
+</p></dd></dl>
+
+<a name="index-_002aimage_002ddump_002dhook_002a"></a>
+<p>This function is pushed onto the <code>uiop:*image-dump-hook*</code> by default,
+which means that if you save an image using <code>uiop:dump-image</code>,
+or via <code>asdf:image-op</code> and <code>asdf:program-op</code>,
+it will be automatically called to clear your configuration.
+If for some reason you prefer to call your implementation’s underlying functionality,
+be sure to call <code>clear-configuration</code> manually,
+or push it into your implementation’s equivalent of <code>uiop:*image-dump-hook*</code>,
+e.g. <code>sb-ext:*save-hooks*</code> on SBCL, or <code>ext:*before-save-initializations*</code>
+on CMUCL and SCL, etc.
+</p>
+<hr>
+<a name="Using-ASDF"></a>
+<a name="Using-ASDF-1"></a>
+<h2 class="chapter">5 Using ASDF</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<div class="defun">
-— Function: <b>clear-configuration</b><var><a name="index-clear_002dconfiguration-18"></a></var><br>
-<blockquote><p> undoes any ASDF configuration,
- regarding source-registry or output-translations.
-</p></blockquote></div>
-
- <p>If you use SBCL, CMUCL or SCL, you may use this snippet
-so that the ASDF configuration be cleared automatically as you dump an image:
-
-<pre class="example"> #+(or cmu sbcl scl)
- (pushnew 'clear-configuration
- #+(or cmu scl) ext:*before-save-initializations*
- #+sbcl sb-ext:*save-hooks*)
-</pre>
- <p>For compatibility with all Lisp implementations, however,
-you might want instead your build script to explicitly call
-<code>(asdf:clear-configuration)</code> at an appropriate moment before dumping.
-
-<h2 class="chapter">4 Using ASDF</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">4.1 Loading a system</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Loading-a-system"></a>
+<a name="Loading-a-system-1"></a>
+<h3 class="section">5.1 Loading a system</h3>
</span>
<p>The system <var>foo</var> is loaded (and compiled, if necessary)
by evaluating the following Lisp form:
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="example">
+<pre class="example">(asdf:load-system :<var>foo</var>)
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (asdf:load-system :<var>foo</var>)
-</pre>
- <p>On some implementations (namely recent versions of
-ABCL, Allegro CL, Clozure CL, CMUCL, ECL, GNU CLISP,
-LispWorks, MKCL, SBCL and XCL),
-ASDF hooks into the <code>CL:REQUIRE</code> facility
-and you can just use:
</span><span style="color: #000000;background-color: #ddffdd">+<p>On some implementations (see <a href="#Convenience-Functions">Convenience Functions</a>),
+ASDF hooks into the <code>cl:require</code> facility and you can just use:
+</p>
+<div class="example">
+<pre class="example">(require :<var>foo</var>)
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (require :<var>foo</var>)
-</pre>
- <p>In older versions of ASDF, you needed to use
-<code>(asdf:oos 'asdf:load-op :</code><var>foo</var><code>)</code>.
-If your ASDF is too old to provide <code>asdf:load-system</code> though
-we recommend that you upgrade to ASDF 3.
-See <a href="#Loading-ASDF">Loading an otherwise installed ASDF</a>.
-
- <p>Note the name of a system is specified as a string or a symbol,
-typically a keyword.
-If a symbol (including a keyword), its name is taken and lowercased.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Note that the canonical name of a system is a string, conventionally lowercase.
+A system name can also be specified as a symbol (including a keyword),
+in which case its <code>symbol-name</code> is taken and lowercased.
</span> The name must be a suitable value for the <code>:name</code> initarg
<span style="color: #000000;background-color: #ffdddd">-to <code>make-pathname</code> in whatever filesystem the system is to be found.
-The lower-casing-symbols behaviour is unconventional,
-but was selected after some consideration.
-Observations suggest that the type of systems we want to support
-either have lowercase as customary case (unix, mac, windows)
-or silently convert lowercase to uppercase (lpns),
-so this makes more sense than attempting to use <code>:case :common</code>,
-which is reported not to work on some implementations
</span><span style="color: #000000;background-color: #ddffdd">+to <code>make-pathname</code> in whatever filesystem the system is to be found.
+</p>
+<p>The lower-casing-symbols behaviour is unconventional,
+but was selected after some consideration.
+The type of systems we want to support
+either have lowercase as customary case (Unix, Mac, Windows)
+or silently convert lowercase to uppercase (lpns).
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">4.2 Other Operations</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Convenience-Functions"></a>
+<a name="Convenience-Functions-1"></a>
+<h3 class="section">5.2 Convenience Functions</h3>
+
+<a name="index-load_002dsystem"></a>
+<a name="index-compile_002dsystem"></a>
+<a name="index-test_002dsystem"></a>
+<a name="index-require_002dsystem"></a>
+<a name="index-make"></a>
</span>
<p>ASDF provides three commands for the most common system operations:
<span style="color: #000000;background-color: #ffdddd">-<code>load-system</code>, <code>compile-system</code> or <code>test-system</code>.
</span><span style="color: #000000;background-color: #ddffdd">+<code>load-system</code>, <code>compile-system</code>, and <code>test-system</code>.
</span> It also provides <code>require-system</code>, a version of <code>load-system</code>
that skips trying to update systems that are already loaded.
<span style="color: #000000;background-color: #ddffdd">+And it provides <code>make</code>, a function that uses whichever operation
+was specified by the author of the target system,
+which by default behaves like <code>load-system</code>.
+</p>
+
+<a name="index-operate"></a>
+<a name="index-oos"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Because ASDF is an extensible system
</span><span style="color: #000000;background-color: #ddffdd">+<p>Because ASDF is an extensible system
</span> for defining <em>operations</em> on <em>components</em>,
<span style="color: #000000;background-color: #ffdddd">-it also provides a generic function <code>operate</code>
-(which is usually abbreviated by <code>oos</code>).
-You'll use <code>oos</code> whenever you want to do something beyond
</span><span style="color: #000000;background-color: #ddffdd">+it also provides a generic function <code>operate</code>,
+so you may arbitrarily operate on your systems beyond the default operations.
+(At the interactive REPL, users often use its shorter alias <code>oos</code>,
+which stands for operate-on-system, a name inherited from <code>mk-defsystem</code>.)
+You’ll use <code>operate</code> whenever you want to do something beyond
</span> compiling, loading and testing.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Output from ASDF and ASDF extensions are supposed to be sent
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that output from ASDF and ASDF extensions are sent
</span> to the CL stream <code>*standard-output*</code>,
<span style="color: #000000;background-color: #ffdddd">-and so rebinding that stream around calls to <code>asdf:operate</code>
</span><span style="color: #000000;background-color: #ddffdd">+so rebinding that stream around calls to <code>asdf:operate</code>
</span> should redirect all output from ASDF operations.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Reminder: before ASDF can operate on a system, however,
-it must be able to find and load that system's definition.
-See <a href="#Configuring-ASDF">Configuring ASDF to find your systems</a>.
-
- <p><a name="index-already_002dloaded_002dsystems-19"></a>
-For the advanced users, note that
-<code>require-system</code> calls <code>load-system</code>
-with keyword arguments <code>:force-not (already-loaded-systems)</code>.
-<code>already-loaded-systems</code> returns a list of the names of loaded systems.
-<code>load-system</code> applies <code>operate</code> with the operation from
-<code>*load-system-operation*</code>, which by default is <code>load-op</code>,
-the system, and any provided keyword arguments.
-
-<h3 class="section">4.3 Summary</h3>
-
-<p>To use ASDF:
-
- <ul>
-<li>Load ASDF itself into your Lisp image, either through
-<code>(require "asdf")</code> or else through
-<code>(load "/path/to/asdf.lisp")</code>.
-
- <li>Make sure ASDF can find system definitions
-thanks to proper source-registry configuration.
-
- <li>Load a system with <code>(asdf:load-system :my-system)</code>
-or use some other operation on some system of your choice.
</span>
<span style="color: #000000;background-color: #ffdddd">- </ul>
</span><span style="color: #000000;background-color: #ddffdd">+<a name="index-load_002dsystem-1"></a>
+<a name="index-_002aload_002dsystem_002doperation_002a"></a>
+<a name="index-already_002dloaded_002dsystems"></a>
+<a name="index-require_002dsystem-1"></a>
+<p><code>load-system</code> applies <code>operate</code> with the operation from
+<code>*load-system-operation*</code>
+the system, and any provided keyword arguments.
+<code>*load-system-operation*</code> by default is <code>load-op</code>;
+it would be <code>load-bundle-op</code> by default on ECL, if only an implementation bug were fixed.
+</p>
+<p><code>require-system</code> skips any update to systems that have already been loaded,
+in the spirit of <code>cl:require</code>.
+It does it by calling <code>load-system</code> with a keyword option excluding already loaded systems.<a name="DOCF8" href="#FOOT8"><sup>8</sup></a>.
+On actively maintained free software implementations
+(namely recent versions of ABCL, Clozure CL, CMUCL, ECL, GNU CLISP, MKCL and SBCL),
+once ASDF itself is loaded, <code>cl:require</code> too can load ASDF systems,
+by falling back on <code>require-system</code>
+for module names not recognized by the implementation.
+</p>
+<p>Note that <code>cl:require</code> and <code>require-system</code> are appropriate to load code
+that is not being modified during the current programming session.
+This notably includes the implementation-provided extension modules that <code>cl:require</code> can load.
+This also includes any number of ASDF systems that the user isn’t either developing or debugging,
+for which a previously installed version is deemed to be satisfactory.
+<code>require-system</code> and through it <code>cl:require</code> can load these systems without any problem.
+But for code that you are actively developing, debugging, or otherwise modifying,
+you should use <code>load-system</code>, so ASDF will pick on your modifications
+and transitively re-build the modified files and everything that depends on them.
+</p>
+<p>Finally, starting with ASDF 3.1, a function <code>make</code> is also available,
+that does “The Right Thing” with your system.
+The default behaviour is to load the system as if by <code>load-system</code>;
+but instead of this default, system authors can specify
+the intended use of their system by specifying their desired operation
+with a <code>:build-operation</code> argument in the system definition.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">4.4 Moving on</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Moving-on"></a>
+<a name="Moving-on-1"></a>
+<h3 class="section">5.3 Moving on</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>That's all you need to know to use ASDF to load systems written by others.
</span><span style="color: #000000;background-color: #ddffdd">+<p>That’s all you need to know to use ASDF to load systems written by others.
</span> The rest of this manual deals with writing system definitions
for Common Lisp software you write yourself,
including how to extend ASDF to define new operation and component types.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Defining-systems-with-defsystem"></a>
-
-<!-- node-name, next, previous, up -->
-<h2 class="chapter">5 Defining systems with defsystem</h2>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Defining-systems-with-defsystem"></a>
+<a name="Defining-systems-with-defsystem-1"></a>
+<h2 class="chapter">6 Defining systems with defsystem</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>This chapter describes how to use asdf to define systems and develop
</span><span style="color: #000000;background-color: #ddffdd">+<p>This chapter describes how to use ASDF to define systems and develop
</span> software.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="The-defsystem-form"></a>
-
-<!-- node-name, next, previous, up -->
-<h3 class="section">5.1 The defsystem form</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Systems can be constructed programmatically
-by instantiating components using <code>make-instance</code>.
-Most of the time, however, it is much more practical to use
-a static <code>defsystem</code> form.
-This section begins with an example of a system definition,
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="The-defsystem-form"></a>
+<a name="The-defsystem-form-1"></a>
+<h3 class="section">6.1 The defsystem form</h3>
+<a name="index-defsystem"></a>
+<a name="index-asdf_002duser"></a>
+<a name="index-load_002dasd"></a>
+
+<p>This section begins with an example of a system definition,
</span> then gives the full grammar of <code>defsystem</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Let's look at a simple system.
-This is a complete file that would
-usually be saved as <samp><span class="file">hello-lisp.asd</span></samp>:
-
-<pre class="lisp"> (in-package :asdf)
-
- (defsystem "hello-lisp"
- :description "hello-lisp: a sample Lisp system."
- :version "0.2.1"
- :author "Joe User <joe@example.com>"
- :licence "Public Domain"
- :components ((:file "packages")
- (:file "macros" :depends-on ("packages"))
- (:file "hello" :depends-on ("macros"))))
-</pre>
- <p>Some notes about this example:
-
- <ul>
-<li>The file starts with an <code>in-package</code> form
-to use package <code>asdf</code>.
-You could instead start your definition by using
-a qualified name <code>asdf:defsystem</code>.
-
- <li>If in addition to simply using <code>defsystem</code>,
-you are going to define functions,
-create ASDF extension, globally bind symbols, etc.,
-it is recommended that to avoid namespace pollution between systems,
-you should create your own package for that purpose,
-for instance replacing the above <code>(in-package :asdf)</code> with:
-
- <pre class="lisp"> (defpackage :foo-system
- (:use :cl :asdf))
-
- (in-package :foo-system)
-</pre>
- <li>The <code>defsystem</code> form defines a system named <code>hello-lisp</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Let’s look at a simple system.
+This is a complete file that should be saved as <samp>hello-lisp.asd</samp>
+(in order that ASDF can find it
+when ordered to operate on the system named <code>"hello-lisp"</code>).
+</p>
+<div class="lisp">
+<pre class="lisp">;; Usual Lisp comments are allowed here
+
+(defsystem "hello-lisp"
+ :description "hello-lisp: a sample Lisp system."
+ :version "0.0.1"
+ :author "Joe User <joe@example.com>"
+ :licence "Public Domain"
+ :depends-on ("optima.ppcre" "command-line-arguments")
+ :components ((:file "packages")
+ (:file "macros" :depends-on ("packages"))
+ (:file "hello" :depends-on ("macros"))))
+</pre></div>
+
+<p>Some notes about this example:
+</p>
+<ul>
+<li> The <code>defsystem</code> form defines a system named <code>hello-lisp</code>
</span> that contains three source files:
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">packages</span></samp>, <samp><span class="file">macros</span></samp> and <samp><span class="file">hello</span></samp>.
-
- <li>The file <samp><span class="file">macros</span></samp> depends on <samp><span class="file">packages</span></samp>
-(presumably because the package it's in is defined in <samp><span class="file">packages</span></samp>),
-and the file <samp><span class="file">hello</span></samp> depends on <samp><span class="file">macros</span></samp>
-(and hence, transitively on <samp><span class="file">packages</span></samp>).
-This means that ASDF will compile and load <samp><span class="file">packages</span></samp> and <samp><span class="file">macros</span></samp>
-before starting the compilation of file <samp><span class="file">hello</span></samp>.
-
- <li>The files are located in the same directory
-as the file with the system definition.
-ASDF resolves symbolic links (or Windows shortcuts)
-before loading the system definition file and
-stores its location in the resulting system<a rel="footnote" href="#fn-3" name="fnd-3"><sup>3</sup></a>.
-This is a good thing because the user can move the system sources
-without having to edit the system definition.
-
- <!-- FIXME: Should have cross-reference to "Version specifiers" in the -->
- <!-- defsystem grammar, but the cross-referencing is so broken by -->
- <!-- insufficient node breakdown that I have not put one in. -->
- <li>Make sure you know how the <code>:version</code> numbers will be parsed!
-They are parsed as period-separated lists of integers.
-I.e., in the example, <code>0.2.1</code> is to be interpreted,
-roughly speaking, as <code>(0 2 1)</code>.
-In particular, version <code>0.2.1</code>
-is interpreted the same as <code>0.0002.1</code> and
-is strictly version-less-than version <code>0.20.1</code>,
-even though the two are the same when interpreted as decimal fractions.
-Instead of a string representing the version,
-the <code>:version</code> argument can be an expression that is resolved to
-such a string using the following trivial domain-specific language:
-in addition to being a literal string, it can be an expression of the form
-<code>(:read-file-form <pathname-or-string> :at <access-at-specifier>)</code>,
-which will be resolved by reading a form in the specified pathname
-(read as a subpathname of the current system if relative or a unix-namestring).
-You may use a <code>uiop:access-at</code> specifier
-with the (optional) <code>:at</code> keyword,
-by default the specifier is <code>0</code>, meaning the first form is returned.
</span><span style="color: #000000;background-color: #ddffdd">+<samp>packages.lisp</samp>, <samp>macros.lisp</samp> and <samp>hello.lisp</samp>.
+
+</li><li> The <samp>.lisp</samp> suffix is implicit for Lisp source files.
+The source files are located in the same directory
+as the <code>.asd</code> file with the system definition.
+
+</li><li> The file <samp>macros</samp> depends on <samp>packages</samp>
+(presumably because the package it’s in is defined in <samp>packages</samp>),
+and the file <samp>hello</samp> depends on <samp>macros</samp>
+(and hence, transitively on <samp>packages</samp>).
+This means that ASDF will compile and load <samp>packages</samp> then <samp>macros</samp>
+before starting the compilation of file <samp>hello</samp>.
+
+</li><li> This example system has external dependencies on two other systems,
+<code>optima.ppcre</code> (that provides a friendly interface to matching regular expressions),
+and <code>command-line-arguments</code> (that provides a way to parse arguments passed from the shell command line).
+To use this system, ASDF must be configured to find installed copies of these systems;
+it will load them before it tries to compile and load <code>hello-lisp</code>.
+
+</li><li> This system also defines a bunch of metadata.
+While it is optional to define these fields
+(and other fields like <code>:bug-tracker</code>, <code>:mailto</code>, <code>:long-name</code>,
+<code>:long-description</code>, <code>:source-control</code>),
+it is strongly recommended to define the fields <code>:description</code>, <code>:version</code>, <code>:author</code>, and <code>:licence</code>,
+especially if you intend your software to be eventually included in Quicklisp.
+
+</li><li> Make sure you know how the <code>:version</code> numbers will be parsed!
+Only period-separated non-negative integers are accepted at present.
+See below Version specifiers in <a href="#The-defsystem-grammar">The defsystem grammar</a>.
+
+</li><li> This file contains a single form, the <code>defsystem</code> declaration.
+No <code>in-package</code> form, no <code>asdf:</code> package prefix, no nothing.
+Just the one naked <code>defsystem</code> form.
+This is what we recommend.
+More complex system definition files are possible with arbitrary Lisp code,
+but we recommend that you keep it simple if you can.
+This will make your system definitions more robust and more future-proof.
+
+<a name="index-_003aversion"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><a name="index-g_t_003aversion-20"></a>
-</ul>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="A-more-involved-example"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<p>This is all you need to know to define simple systems.
+The next example is much more involved, to give you a glimpse of how you can do more complex things.
+However, since it’s ultimately arbitrary Lisp code, there is no bottom to the rabbit hole.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h3 class="section">5.2 A more involved example</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="A-more-involved-example"></a>
+<a name="A-more-involved-example-1"></a>
+<h3 class="section">6.2 A more involved example</h3>
+<a name="index-defsystem-1"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Let's illustrate some more involved uses of <code>defsystem</code> via a
</span><span style="color: #000000;background-color: #ddffdd">+<p>Let’s illustrate some more involved uses of <code>defsystem</code> via a
</span> slightly convoluted example:
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">(in-package :asdf-user)
+
+(defsystem "foo"
+ :version (:read-file-form "variables" :at (3 2))
+ :components
+ ((:file "package")
+ (:file "variables" :depends-on ("package"))
+ (:module "mod"
+ :depends-on ("package")
+ :serial t
+ :components ((:file "utils")
+ (:file "reader")
+ (:file "cooker")
+ (:static-file "data.raw"))
+ :output-files (compile-op (o c) (list "data.cooked"))
+ :perform (compile-op :after (o c)
+ (cook-data
+ :in (component-pathname (find-component c "data.raw"))
+ :out (first (output-files o c)))))
+ (:file "foo" :depends-on ("mod"))))
+
+(defmethod action-description
+ ((o compile-op) (c (eql (find-component "foo" "mod"))))
+ "cooking data")
+</pre></div>
+
+<p>Here are some notes about this example:
+</p>
+<ul>
+<li> The main thing this file does is define a system <code>foo</code>.
+It also contains other Lisp forms, which we’ll examine below.
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (defsystem "foo"
- :version "1.0.0"
- :components ((:module "mod"
- :components ((:file "bar")
- (:file"baz")
- (:file "quux"))
- :perform (compile-op :after (op c)
- (do-something c))
- :explain (compile-op :after (op c)
- (explain-something c)))
- (:file "blah")))
-</pre>
- <p>The <code>:module</code> component named <code>"mod"</code> is a collection of three files,
-which will be located in a subdirectory of the main code directory named
-<samp><span class="file">mod</span></samp> (this location can be overridden; see the discussion of the
-<code>:pathname</code> option in <a href="#The-defsystem-grammar">The defsystem grammar</a>).
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Besides Lisp source files, this system contains a <code>:module</code> component
+named <code>"mod"</code>, which is a collection of three Lisp source files
+<samp>utils.lisp</samp>, <samp>reader.lisp</samp>, <samp>cooker.lisp</samp> and <samp>data.raw</samp>
+
+</li><li> Note that the <code>:static-file</code> does not have an implicit file type,
+unlike the Lisp source files.
+
+</li><li> This files will be located in a subdirectory of the main code directory named
+<samp>mod/</samp> (this location could have been overridden to be
+in the same directory, or in a different subdirectory;
+see the discussion of the <code>:pathname</code> option in <a href="#The-defsystem-grammar">The defsystem grammar</a>).
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The method-form tokens provide a shorthand for defining methods on
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The <code>:serial t</code> says that each sub-component of <code>mod</code> depends on the previous components,
+so that <samp>cooker.lisp</samp> depends-on <samp>utils.lisp</samp>, which depends-on <samp>reader.lisp</samp>.
+Also <samp>data.raw</samp> depends on all of them, but that doesn’t matter since it’s a static file;
+on the other hand, if it appeared first, then all the Lisp files would be recompiled
+when the data is modified, which is probably not what is desired in this case.
+
+</li><li> The method-form tokens provide a shorthand for defining methods on
</span> particular components. This part
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> :perform (compile-op :after (op c)
- (do-something c))
- :explain (compile-op :after (op c)
- (explain-something c))
-</pre>
- <p>has the effect of
</span><span style="color: #000000;background-color: #ddffdd">+<div class="lisp">
+<pre class="lisp"> :output-files (compile-op (o c) (list "data.cooked"))
+ :perform (compile-op :after (o c)
+ (cook-data
+ :in (component-pathname (find-component c "data.raw"))
+ :out (first (output-files o c))))
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (defmethod perform :after ((op compile-op) (c (eql ...)))
- (do-something c))
- (defmethod explain :after ((op compile-op) (c (eql ...)))
- (explain-something c))
-</pre>
- <p>where <code>...</code> is the component in question.
</span><span style="color: #000000;background-color: #ddffdd">+<p>has the effect of
+</p>
+<div class="lisp">
+<pre class="lisp">(defmethod output-files ((o compile-op) (c (eql ...)))
+ (list "data.cooked"))
+(defmethod perform :after ((o compile-op) (c (eql ...)))
+ (cook-data
+ :in (component-pathname (find-component c "data.raw"))
+ :out (first (output-files o c))))
+</pre></div>
+
+<p>where <code>...</code> is the component in question.
</span> In this case <code>...</code> would expand to something like
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">(find-component "foo" "mod")
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (find-component "foo" "mod")
-</pre>
- <p>For more details on the syntax of such forms, see <a href="#The-defsystem-grammar">The defsystem grammar</a>.
</span><span style="color: #000000;background-color: #ddffdd">+<p>For more details on the syntax of such forms,
+see <a href="#The-defsystem-grammar">The defsystem grammar</a>.
</span> For more details on what these methods do, see <a href="#Operations">Operations</a> in
<a href="#The-object-model-of-ASDF">The object model of ASDF</a>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+</li><li> There is an additional <code>defmethod</code> with a similar effect,
+because ASDF (as of ASDF 3.1.5)
+fails to accept inline-methods as above for <code>action-description</code>,
+instead only supporting the deprecated <code>explain</code> interface.
+
+
+</li><li> In this case, these methods describe how this module defines code
+that it then uses to cook some data.
+
+</li><li> Importantly, ASDF is told about the input and output files
+used by the data cooker,
+and to make sure everyone agrees,
+the cooking function explicitly uses ASDF to access pathnames
+to the input and output data.
+
+
+</li><li> The file starts with a form <code>(in-package :asdf-user)</code>,
+but it is actually redundant, not necessary and not recommended.
+But yet more complex cases (also not recommended) may usefully use an <code>in-package</code> form.
+
+</li><li> Indeed, ASDF does not load <samp>.asd</samp> files simply with <code>cl:load</code>,
+and neither should you.
+You should let ASDF find and load them when you operate on systems.
+If you somehow <em>must</em> load a <samp>.asd</samp> file,
+use the same function <code>asdf:load-asd</code> that ASDF uses.
+Among other things, it already binds the <code>*package*</code> to <code>asdf-user</code>.
+Recent versions of SLIME (2013-02 and later) know to do that when you <kbd>C-c C-k</kbd>
+when you use the <code>slime-asdf</code> contrib.
+
+</li><li> You shouldn’t use an <code>in-package</code> form
+if you’re keeping things simple.
+You should only use <code>in-package</code> (and before it, a <code>defpackage</code>)
+when you’re going to define new classes, functions, variables, macros, etc.,
+in the <code>.asd</code> file, and want to thereby avoid name clashes.
+Manuals for old versions of ASDF recommended use of such an idiom in <samp>.asd</samp> files,
+but as of ASDF 3, we recommend that you don’t do that anymore,
+and instead define any ASDF extensions in their own system,
+on which you can then declare a dependency using <code>:defsystem-depends-on</code>.
+See <a href="#The-defsystem-grammar">The defsystem grammar</a>.
+
+</li><li> More generally, you can always rely on symbols
+from packages <code>asdf</code>, <code>common-lisp</code> and <code>uiop</code>
+being available in <code>.asd</code> files —
+most importantly including <code>defsystem</code>.
+It is therefore redundant and in bad taste to use a package-prefixed <code>asdf:defsystem</code> symbol
+in a <samp>.asd</samp> file.
+Just use <code>(defsystem ...)</code>.
+Only package-prefix it when somehow dynamically generating system definitions
+from a package that doesn’t already use the ASDF package.
+
+</li><li> <code>asdf-user</code> is actually only available starting since ASDF 3, but then again,
+ASDF 1 and 2 did crazy things with packages that ASDF 3 has stopped doing<a name="DOCF9" href="#FOOT9"><sup>9</sup></a>,
+and since all implementations provide ASDF 3, you shouldn’t care about compatibility with ASDF 2.
+We do not support ASDF 2 anymore, and we recommend that neither should you.
+
+</li><li> Starting with ASDF 3.1, <code>asdf-user</code> uses <code>uiop</code>,
+whereas in earlier variants of ASDF 3 it only used <code>uiop/package</code>.
+We recommend you either prefix use of UIOP functions with the package prefix <code>uiop:</code>,
+or make sure your system <code>:depends-on ((:version "asdf" "3.1.2"))</code>
+or has a <code>#-asdf3.1 (error "MY-SYSTEM requires ASDF 3.1.2")</code>.
+
+</li><li> Finally, we elided most metadata, but showed how you can have ASDF automatically extract
+the system’s version from a source file. In this case, the 3rd subform of the 4th form
+(note that Lisp uses 0-based indexing, English uses 1-based indexing).
+Presumably, the 4th form looks like <code>(defparameter *foo-version* "5.6.7")</code>.
+
+</li></ul>
+
+
+<hr>
+<a name="The-defsystem-grammar"></a>
+<a name="The-defsystem-grammar-1"></a>
+<h3 class="section">6.3 The defsystem grammar</h3>
+<a name="index-defsystem-2"></a>
+<a name="index-DEFSYSTEM-grammar"></a>
+
+
+
+<div class="example">
+<pre class="example">system-definition := ( defsystem system-designator <var>system-option</var>* )
+
+system-option := :defsystem-depends-on system-list
+ | :weakly-depends-on <var>system-list</var>
+ | :class class-name (see discussion below)
+ | system-option
+ | module-option
+ | option
+
+# These are only available since ASDF 3 (actually its alpha release 2.27)
+system-option := :homepage string
+ | :bug-tracker string
+ | :mailto string
+ | :long-name string
+ | :source-control source-control
+ | :version version-specifier
+
+source-control := (keyword string)
+
+module-option := :components component-list
+ | :serial [ t | nil ]
+
+option :=
+ | :pathname pathname-specifier
+ | :default-component-class class-name
+ | :perform method-form
+ | :explain method-form
+ | :output-files method-form
+ | :operation-done-p method-form
+ | :if-feature feature-expression
+ | :depends-on ( <var>dependency-def</var>* )
+ | :in-order-to ( <var>dependency</var>+ )
+
+
+system-list := ( <var>simple-component-name</var>* )
+
+component-list := ( <var>component-def</var>* )
+
+component-def := ( component-type simple-component-name <var>option</var>* )
+
+component-type := :module | :file | :static-file | other-component-type
+
+other-component-type := symbol-by-name
+ (see <a href="#The-defsystem-grammar">Component types</a>)
+
+# This is used in :depends-on, as opposed to ``dependency,''
+# which is used in :in-order-to
+dependency-def := simple-component-name
+ | ( :feature <var>feature-expression</var> dependency-def )
+ | ( :version simple-component-name version-specifier )
+ | ( :require module-name )
+
+# ``dependency'' is used in :in-order-to, as opposed to
+# ``dependency-def''
+dependency := (dependent-op <var>requirement</var>+)
+requirement := (required-op <var>required-component</var>+)
+dependent-op := operation-name
+required-op := operation-name
+
+simple-component-name := string
+ | symbol
+
+pathname-specifier := pathname | string | symbol
+
+method-form := (operation-name qual lambda-list &rest body)
+qual := method qualifier
+
+component-dep-fail-option := :fail | :try-next | :ignore
+
+feature-expression := keyword
+ | (:and <var>feature-expression</var>*)
+ | (:or <var>feature-expression</var>*)
+ | (:not <var>feature-expression</var>)
+</pre></div>
+
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- The following plunge into the weeds is not appropriate in this -->
-<!-- location. [2010/10/03:rpg] -->
-<!-- note that although this also supports @code{:before} methods, -->
-<!-- they may not do what you want them to - -->
-<!-- a @code{:before} method on perform @code{((op compile-op) (c (eql ...)))} -->
-<!-- will run after all the dependencies and sub-components have been processed, -->
-<!-- but before the component in question has been compiled. -->
-<p><a name="The-defsystem-grammar"></a>
-
-<!-- node-name, next, previous, up -->
-<h3 class="section">5.3 The defsystem grammar</h3>
-
-<!-- FIXME: @var typesetting not consistently used here. We should either expand -->
-<!-- its use to everywhere, or we should kill it everywhere. -->
-<pre class="example"> system-definition := ( defsystem system-designator <var>system-option</var>* )
-
- system-option := :defsystem-depends-on system-list
- | :weakly-depends-on <var>system-list</var>
- | :class class-name (see discussion below)
- | module-option
- | option
-
- module-option := :components component-list
- | :serial [ t | nil ]
-
- option :=
- | :pathname pathname-specifier
- | :default-component-class class-name
- | :perform method-form
- | :explain method-form
- | :output-files method-form
- | :operation-done-p method-form
- | :if-feature feature-expression
- | :depends-on ( <var>dependency-def</var>* )
- | :in-order-to ( <var>dependency</var>+ )
-
-
- system-list := ( <var>simple-component-name</var>* )
-
- component-list := ( <var>component-def</var>* )
-
- component-def := ( component-type simple-component-name <var>option</var>* )
-
- component-type := :module | :file | :static-file | other-component-type
-
- other-component-type := symbol-by-name (see <a href="#The-defsystem-grammar">Component types</a>)
-
- # This is used in :depends-on, as opposed to ``dependency,''
- # which is used in :in-order-to
- dependency-def := simple-component-name
- | (feature <var>feature-name</var>)
- | ( :version simple-component-name version-specifier)
-
- # ``dependency'' is used in :in-order-to, as opposed to
- # ``dependency-def''
- dependency := (dependent-op <var>requirement</var>+)
- requirement := (required-op <var>required-component</var>+)
- | (:feature <var>feature-name</var>)
- dependent-op := operation-name
- required-op := operation-name
-
- simple-component-name := string
- | symbol
-
- pathname-specifier := pathname | string | symbol
-
- method-form := (operation-name qual lambda-list &rest body)
- qual := method qualifier
-
- component-dep-fail-option := :fail | :try-next | :ignore
-
- feature-expression := keyword | (:and <var>feature-expression</var>*)
- | (:or <var>feature-expression</var>*) | (:not <var>feature-expression</var>)
-</pre>
-<h4 class="subsection">5.3.1 Component names</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<a name="Component-names"></a>
+<h4 class="subsection">6.3.1 Component names</h4>
</span>
<p>Component names (<code>simple-component-name</code>)
may be either strings or symbols.
<span style="color: #000000;background-color: #ffdddd">-
-<h4 class="subsection">5.3.2 Component types</h4>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="Component-types"></a>
+<h4 class="subsection">6.3.2 Component types</h4>
</span>
<p>Component type names, even if expressed as keywords, will be looked up
by name in the current package and in the asdf package, if not found in
the current package. So a component type <code>my-component-type</code>, in
the current package <code>my-system-asd</code> can be specified as
<code>:my-component-type</code>, or <code>my-component-type</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>system</code> and its subclasses are <em>not</em>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>system</code> and its subclasses are <em>not</em>
</span> allowed as component types for such children components.
<span style="color: #000000;background-color: #ffdddd">-
-<h4 class="subsection">5.3.3 System class names</h4>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="System-class-names"></a>
+<h4 class="subsection">6.3.3 System class names</h4>
</span>
<p>A system class name will be looked up
in the same way as a Component type (see above),
<span style="color: #000000;background-color: #ffdddd">-except that only <code>system</code> and its subclasses are allowed.
</span><span style="color: #000000;background-color: #ddffdd">+except that only <code>system</code> and its subclasses are allowed.
</span> Typically, one will not need to specify a system
class name, unless using a non-standard system class defined in some
ASDF extension, typically loaded through <code>DEFSYSTEM-DEPENDS-ON</code>,
see below. For such class names in the ASDF package, we recommend that
the <code>:class</code> option be specified using a keyword symbol, such as
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="example">
+<pre class="example">:class :MY-NEW-SYSTEM-SUBCLASS
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> :class :MY-NEW-SYSTEM-SUBCLASS
-</pre>
- <p>This practice will ensure that package name conflicts are avoided.
</span><span style="color: #000000;background-color: #ddffdd">+<p>This practice will ensure that package name conflicts are avoided.
</span> Otherwise, the symbol <code>MY-NEW-SYSTEM-SUBCLASS</code> will be read into
the current package <em>before</em> it has been exported from the ASDF
extension loaded by <code>:defsystem-depends-on</code>, causing a name
conflict in the current package.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="Defsystem-depends-on"></a>
+<h4 class="subsection">6.3.4 Defsystem depends on</h4>
+<a name="index-_003adefsystem_002ddepends_002don"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">5.3.4 Defsystem depends on</h4>
-
-<p><a name="index-g_t_003adefsystem_002ddepends_002don-21"></a>
-The <code>:defsystem-depends-on</code> option to <code>defsystem</code> allows the
</span><span style="color: #000000;background-color: #ddffdd">+<p>The <code>:defsystem-depends-on</code> option to <code>defsystem</code> allows the
</span> programmer to specify another ASDF-defined system or set of systems that
<span style="color: #000000;background-color: #ffdddd">-must be loaded <em>before</em> the system definition is processed.
</span><span style="color: #000000;background-color: #ddffdd">+must be loaded <em>before</em> the system definition is processed.
</span> Typically this is used to load an ASDF extension that is used in the
system definition.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="Weakly-depends-on"></a>
+<h4 class="subsection">6.3.5 Weakly depends on</h4>
+<a name="index-_003aweakly_002ddepends_002don"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">5.3.5 Weakly depends on</h4>
-
-<p><a name="index-g_t_003aweakly_002ddepends_002don-22"></a>
-We do <em>NOT</em> recommend you use this feature.
</span><span style="color: #000000;background-color: #ddffdd">+<p>We do <em>NOT</em> recommend you use this feature.
</span> If you are tempted to write a system <var>foo</var>
that weakly-depends-on a system <var>bar</var>,
we recommend that you should instead
write system <var>foo</var> in a parametric way,
<span style="color: #000000;background-color: #ffdddd">-and offer some special variable and/or some hook to specialize its behavior;
</span><span style="color: #000000;background-color: #ddffdd">+and offer some special variable and/or some hook to specialize its behaviour;
</span> then you should write a system <var>foo+bar</var>
that does the hooking of things together.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The (deprecated) <code>:weakly-depends-on</code> option to <code>defsystem</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The (deprecated) <code>:weakly-depends-on</code> option to <code>defsystem</code>
</span> allows the programmer to specify another ASDF-defined system or set of systems
that ASDF should <em>try</em> to load,
<span style="color: #000000;background-color: #ffdddd">-but need not load in order to be successful.
</span><span style="color: #000000;background-color: #ddffdd">+but need not load in order to be successful.
</span> Typically this is used if there are a number of systems
that, if present, could provide additional functionality,
but which are not necessary for basic function.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Currently, although it is specified to be an option only to <code>defsystem</code>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Currently, although it is specified to be an option only to <code>defsystem</code>,
</span> this option is accepted at any component, but it probably
<span style="color: #000000;background-color: #ffdddd">-only makes sense at the <code>defsystem</code> level.
</span><span style="color: #000000;background-color: #ddffdd">+only makes sense at the <code>defsystem</code> level.
</span> Programmers are cautioned not
to use this component option except at the <code>defsystem</code> level, as
<span style="color: #000000;background-color: #ffdddd">-this anomalous behavior may be removed without warning.
</span><span style="color: #000000;background-color: #ddffdd">+this anomalous behaviour may be removed without warning.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Finally, you might look into the <code>asdf-system-connections</code> extension,
-that will let you define additional code to be loaded
-when two systems are simultaneously loaded.
-It may or may not be considered good style, but at least it can be used
-in a way that has deterministic behavior independent of load order,
-unlike <code>weakly-depends-on</code>.
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">5.3.6 Pathname specifiers</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<a name="Pathname-specifiers"></a>
+<h4 class="subsection">6.3.6 Pathname specifiers</h4>
+<a name="index-pathname-specifiers"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-pathname-specifiers-23"></a>
-A pathname specifier (<code>pathname-specifier</code>)
-may be a pathname, a string or a symbol.
</span><span style="color: #000000;background-color: #ddffdd">+<p>A pathname specifier (<code>pathname-specifier</code>)
+may be a pathname, a string or a symbol.
</span> When no pathname specifier is given for a component,
which is the usual case, the component name itself is used.
<span style="color: #000000;background-color: #ffdddd">-
- <p>If a string is given, which is the usual case,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If a string is given, which is the usual case,
</span> the string will be interpreted as a Unix-style pathname
<span style="color: #000000;background-color: #ffdddd">-where <code>/</code> characters will be interpreted as directory separators.
</span><span style="color: #000000;background-color: #ddffdd">+where <code>/</code> characters will be interpreted as directory separators.
</span> Usually, Unix-style relative pathnames are used
(i.e. not starting with <code>/</code>, as opposed to absolute pathnames);
<span style="color: #000000;background-color: #ffdddd">-they are relative to the path of the parent component.
</span><span style="color: #000000;background-color: #ddffdd">+they are relative to the path of the parent component.
</span> Finally, depending on the <code>component-type</code>,
the pathname may be interpreted as either a file or a directory,
<span style="color: #000000;background-color: #ffdddd">-and if it's a file,
</span><span style="color: #000000;background-color: #ddffdd">+and if it’s a file,
</span> a file type may be added corresponding to the <code>component-type</code>,
or else it will be extracted from the string itself (if applicable).
<span style="color: #000000;background-color: #ffdddd">-
- <p>For instance, the <code>component-type</code> <code>:module</code>
-wants a directory pathname, and so a string <code>"foo/bar"</code>
-will be interpreted as the pathname <samp><span class="file">#p"foo/bar/"</span></samp>.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>For instance, the <code>component-type</code> <code>:module</code>
+wants a directory pathname, and so a string <code>"foo/bar"</code>
+will be interpreted as the pathname <samp>#p"foo/bar/"</samp>.
</span> On the other hand, the <code>component-type</code> <code>:file</code>
<span style="color: #000000;background-color: #ffdddd">-wants a file of type <code>lisp</code>, and so a string <code>"foo/bar"</code>
-will be interpreted as the pathname <samp><span class="file">#p"foo/bar.lisp"</span></samp>,
-and a string <code>"foo/bar.quux"</code>
-will be interpreted as the pathname <samp><span class="file">#p"foo/bar.quux.lisp"</span></samp>.
</span><span style="color: #000000;background-color: #ddffdd">+wants a file of type <code>lisp</code>, and so a string <code>"foo/bar"</code>
+will be interpreted as the pathname <samp>#p"foo/bar.lisp"</samp>,
+and a string <code>"foo/bar.quux"</code>
+will be interpreted as the pathname <samp>#p"foo/bar.quux.lisp"</samp>.
</span> Finally, the <code>component-type</code> <code>:static-file</code>
<span style="color: #000000;background-color: #ffdddd">-wants a file without specifying a type, and so a string <code>"foo/bar"</code>
-will be interpreted as the pathname <samp><span class="file">#p"foo/bar"</span></samp>,
-and a string <code>"foo/bar.quux"</code>
-will be interpreted as the pathname <samp><span class="file">#p"foo/bar.quux"</span></samp>.
-
- <p>ASDF does not interpret the string <code>".."</code> to designate the parent
-directory. This string will be passed through to the underlying
-operating system for interpretation. We <em>believe</em> that this will
-work on all platforms where ASDF is deployed, but do not guarantee this
-behavior. A pathname object with a relative directory component of
-<code>:up</code> or <code>:back</code> is the only guaranteed way to specify a
-parent directory.
-
- <p>If a symbol is given, it will be translated into a string,
-and downcased in the process.
</span><span style="color: #000000;background-color: #ddffdd">+wants a file without specifying a type, and so a string <code>"foo/bar"</code>
+will be interpreted as the pathname <samp>#p"foo/bar"</samp>,
+and a string <code>"foo/bar.quux"</code>
+will be interpreted as the pathname <samp>#p"foo/bar.quux"</samp>.
+</p>
+<p>ASDF interprets the string <code>".."</code>
+as the pathname directory component word <code>:back</code>,
+which when merged, goes back one level in the directory hierarchy.
+</p>
+<p>If a symbol is given, it will be translated into a string,
+and downcased in the process.
</span> The downcasing of symbols is unconventional,
<span style="color: #000000;background-color: #ffdddd">-but was selected after some consideration.
</span><span style="color: #000000;background-color: #ddffdd">+but was selected after some consideration.
</span> Observations suggest that the type of systems we want to support
either have lowercase as customary case (Unix, Mac, windows)
or silently convert lowercase to uppercase (lpns),
so this makes more sense than attempting to use <code>:case :common</code>
as argument to <code>make-pathname</code>,
which is reported not to work on some implementations.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Pathname objects may be given to override the path for a component.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Pathname objects may be given to override the path for a component.
</span> Such objects are typically specified using reader macros such as <code>#p</code>
<span style="color: #000000;background-color: #ffdddd">-or <code>#.(make-pathname ...)</code>.
</span><span style="color: #000000;background-color: #ddffdd">+or <code>#.(make-pathname ...)</code>.
</span> Note however, that <code>#p...</code> is
a shorthand for <code>#.(parse-namestring ...)</code>
<span style="color: #000000;background-color: #ffdddd">-and that the behavior of <code>parse-namestring</code> is completely non-portable,
</span><span style="color: #000000;background-color: #ddffdd">+and that the behaviour of <code>parse-namestring</code> is completely non-portable,
</span> unless you are using Common Lisp <code>logical-pathname</code>s,
<span style="color: #000000;background-color: #ffdddd">-which themselves involve other non-portable behavior
-(see <a href="#The-defsystem-grammar">Using logical pathnames</a>, below).
</span><span style="color: #000000;background-color: #ddffdd">+which themselves involve other non-portable behaviour
+(see <a href="#The-defsystem-grammar">Using logical pathnames</a>, below).
</span> Pathnames made with <code>#.(make-pathname ...)</code>
<span style="color: #000000;background-color: #ffdddd">-can usually be done more easily with the string syntax above.
</span><span style="color: #000000;background-color: #ddffdd">+can usually be done more easily with the string syntax above.
</span> The only case that you really need a pathname object is to override
<span style="color: #000000;background-color: #ffdddd">-the component-type default file type for a given component.
-Therefore, pathname objects should only rarely be used.
-Unhappily, ASDF 1 didn't properly support
</span><span style="color: #000000;background-color: #ddffdd">+the component-type default file type for a given component.
+Therefore, pathname objects should only rarely be used.
+Unhappily, ASDF 1 used not to properly support
</span> parsing component names as strings specifying paths with directories,
<span style="color: #000000;background-color: #ffdddd">-and the cumbersome <code>#.(make-pathname ...)</code> syntax had to be used.
</span><span style="color: #000000;background-color: #ddffdd">+and the cumbersome <code>#.(make-pathname ...)</code> syntax had to be used.
</span> An alternative to <code>#.</code> read-time evaluation is to use
<code>(eval `(defsystem ... ,pathname ...))</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Note that when specifying pathname objects,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that when specifying pathname objects,
</span> ASDF does not do any special interpretation of the pathname
influenced by the component type, unlike the procedure for
<span style="color: #000000;background-color: #ffdddd">-pathname-specifying strings.
</span><span style="color: #000000;background-color: #ddffdd">+pathname-specifying strings.
</span> On the one hand, you have to be careful to provide a pathname that correctly
fulfills whatever constraints are required from that component type
(e.g. naming a directory or a file with appropriate type);
on the other hand, you can circumvent the file type that would otherwise
be forced upon you if you were specifying a string.
<span style="color: #000000;background-color: #ffdddd">-
-<h4 class="subsection">5.3.7 Version specifiers</h4>
-
-<p><a name="index-version-specifiers-24"></a><a name="index-g_t_003aversion-25"></a>
-Version specifiers are strings to be parsed as period-separated lists of integers.
-I.e., in the example, <code>"0.2.1"</code> is to be interpreted,
-roughly speaking, as <code>(0 2 1)</code>.
-In particular, version <code>"0.2.1"</code> is interpreted the same as <code>"0.0002.1"</code>,
-though the latter is not canonical and may lead to a warning being issued.
-Also, <code>"1.3"</code> and <code>"1.4"</code> are both strictly <code>uiop:version<</code> to <code>"1.30"</code>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="Version-specifiers"></a>
+<h4 class="subsection">6.3.7 Version specifiers</h4>
+<a name="index-version-specifiers"></a>
+<a name="index-_003aversion-1"></a>
+
+<p>Version specifiers are strings to be parsed as period-separated lists of integers.
+I.e., in the example, <code>"0.2.1"</code> is to be interpreted,
+roughly speaking, as <code>(0 2 1)</code>.
+In particular, version <code>"0.2.1"</code> is interpreted the same as <code>"0.0002.1"</code>,
+though the latter is not canonical and may lead to a warning being issued.
+Also, <code>"1.3"</code> and <code>"1.4"</code> are both strictly <code>uiop:version<</code> to <code>"1.30"</code>,
</span> quite unlike what would have happened
had the version strings been interpreted as decimal fractions.
<span style="color: #000000;background-color: #ffdddd">-
- <p>System definers are encouraged to use version identifiers of the form
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Instead of a string representing the version,
+the <code>:version</code> argument can be an expression that is resolved to
+such a string using the following trivial domain-specific language:
+in addition to being a literal string, it can be an expression of the form
+<code>(:read-file-form <pathname-or-string> :at <access-at-specifier>)</code>,
+which will be resolved by reading a form in the specified pathname
+(read as a subpathname of the current system if relative or a unix-namestring).
+You may use a <code>uiop:access-at</code> specifier
+with the (optional) <code>:at</code> keyword,
+by default the specifier is <code>0</code>, meaning the first form is returned;
+subforms can also be specified, with e.g. <code>(1 2 2)</code> specifying
+“the third subform (index 2) of the third subform (index 2) of the second form (index 1)”
+in the file (mind the off-by-one error in the English language).
+</p>
+<p>System definers are encouraged to use version identifiers of the form
</span> <var>x</var>.<var>y</var>.<var>z</var> for
major version, minor version and patch level,
where significant API incompatibilities are signaled by an increased major number.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>See <a href="#Common-attributes-of-components">Common attributes of components</a>.
+</p>
+<a name="Require"></a>
+<h4 class="subsection">6.3.8 Require</h4>
+<a name="index-_003arequire-dependencies"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>See <a href="#Common-attributes-of-components">Common attributes of components</a>.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Use the implementation’s own <code>require</code> to load the <var>module-name</var>.
+</p>
+<p>It is good taste to use <code>:if-feature <em>:implementation-name</em></code>
+rather than <code>#+<em>implementation-name</em></code>
+to only depend on the specified module on the specific implementation that provides it.
+See <a href="#if_002dfeature_002doption">if-feature-option</a>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">5.3.8 Using logical pathnames</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<a name="Using-logical-pathnames"></a>
+<h4 class="subsection">6.3.9 Using logical pathnames</h4>
+<a name="index-logical-pathnames"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-logical-pathnames-26"></a>
-We do not generally recommend the use of logical pathnames,
-especially not so to newcomers to Common Lisp.
</span><span style="color: #000000;background-color: #ddffdd">+<p>We do not generally recommend the use of logical pathnames,
+especially not so to newcomers to Common Lisp.
</span> However, we do support the use of logical pathnames by old timers,
when such is their preference.
<span style="color: #000000;background-color: #ffdddd">-
- <p>To use logical pathnames,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>To use logical pathnames,
</span> you will have to provide a pathname object as a <code>:pathname</code> specifier
to components that use it, using such syntax as
<span style="color: #000000;background-color: #ffdddd">-<code>#p"LOGICAL-HOST:absolute;path;to;component.lisp"</code>.
-
- <p>You only have to specify such logical pathname
-for your system or some top-level component.
-Sub-components' relative pathnames,
</span><span style="color: #000000;background-color: #ddffdd">+<code>#p"LOGICAL-HOST:absolute;path;to;component.lisp"</code>.
+</p>
+<p>You only have to specify such logical pathname
+for your system or some top-level component.
+Sub-components’ relative pathnames,
</span> specified using the string syntax for names,
<span style="color: #000000;background-color: #ffdddd">-will be properly merged with the pathnames of their parents.
</span><span style="color: #000000;background-color: #ddffdd">+will be properly merged with the pathnames of their parents.
</span> The specification of a logical pathname host however is <em>not</em>
otherwise directly supported in the ASDF syntax
for pathname specifiers as strings.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The <code>asdf-output-translation</code> layer will
-avoid trying to resolve and translate logical pathnames.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The <code>asdf-output-translation</code> layer will
+avoid trying to resolve and translate logical pathnames.
</span> The advantage of this is that
you can define yourself what translations you want to use
<span style="color: #000000;background-color: #ffdddd">-with the logical pathname facility.
</span><span style="color: #000000;background-color: #ddffdd">+with the logical pathname facility.
</span> The disadvantage is that if you do not define such translations,
any system that uses logical pathnames will behave differently under
asdf-output-translations than other systems you use.
<span style="color: #000000;background-color: #ffdddd">-
- <p>If you wish to use logical pathnames you will have to configure the
-translations yourself before they may be used.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If you wish to use logical pathnames you will have to configure the
+translations yourself before they may be used.
</span> ASDF currently provides no specific support
for defining logical pathname translations.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Note that the reasons we do not recommend logical pathnames are that
-(1) there is no portable way to set up logical pathnames before they are used,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that the reasons we do not recommend logical pathnames are that
+(1) there is no portable way to set up logical pathnames <em>before</em> they are used,
</span> (2) logical pathnames are limited to only portably use
<span style="color: #000000;background-color: #ffdddd">-a single character case, digits and hyphens.
</span><span style="color: #000000;background-color: #ddffdd">+a single character case, digits and hyphens.
</span> While you can solve the first issue on your own,
describing how to do it on each of fifteen implementations supported by ASDF
<span style="color: #000000;background-color: #ffdddd">-is more than we can document.
</span><span style="color: #000000;background-color: #ddffdd">+is more than we can document.
</span> As for the second issue, mind that the limitation is notably enforced on SBCL,
<span style="color: #000000;background-color: #ffdddd">-and that you therefore can't portably violate the limitations
</span><span style="color: #000000;background-color: #ddffdd">+and that you therefore can’t portably violate the limitations
</span> but must instead define some encoding of your own and add individual mappings
<span style="color: #000000;background-color: #ffdddd">-to name physical pathnames that do not fit the restrictions.
</span><span style="color: #000000;background-color: #ddffdd">+to name physical pathnames that do not fit the restrictions.
</span> This can notably be a problem when your Lisp files are part of a larger project
in which it is common to name files or directories in a way that
includes the version numbers of supported protocols,
or in which files are shared with software written
in different programming languages where conventions include the use of
underscores, dots or CamelCase in pathnames.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">5.3.9 Serial dependencies</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<a name="Serial-dependencies"></a>
+<h4 class="subsection">6.3.10 Serial dependencies</h4>
+<a name="index-serial-dependencies"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-serial-dependencies-27"></a>
-If the <code>:serial t</code> option is specified for a module,
</span><span style="color: #000000;background-color: #ddffdd">+<p>If the <code>:serial t</code> option is specified for a module,
</span> ASDF will add dependencies for each child component,
<span style="color: #000000;background-color: #ffdddd">-on all the children textually preceding it.
</span><span style="color: #000000;background-color: #ddffdd">+on all the children textually preceding it.
</span> This is done as if by <code>:depends-on</code>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">:serial t
+:components ((:file "a") (:file "b") (:file "c"))
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> :serial t
- :components ((:file "a") (:file "b") (:file "c"))
-</pre>
- <p>is equivalent to
</span><span style="color: #000000;background-color: #ddffdd">+<p>is equivalent to
+</p>
+<div class="lisp">
+<pre class="lisp">:components ((:file "a")
+ (:file "b" :depends-on ("a"))
+ (:file "c" :depends-on ("a" "b")))
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> :components ((:file "a")
- (:file "b" :depends-on ("a"))
- (:file "c" :depends-on ("a" "b")))
-</pre>
- <h4 class="subsection">5.3.10 Source location</h4>
</span><span style="color: #000000;background-color: #ddffdd">+
+<a name="Source-location-_0028_003apathname_0029"></a>
+<h4 class="subsection">6.3.11 Source location (<code>:pathname</code>)</h4>
</span>
<p>The <code>:pathname</code> option is optional in all cases for systems
<span style="color: #000000;background-color: #ffdddd">-defined via <code>defsystem</code>,
-and in the usual case the user is recommended not to supply it.
</span><span style="color: #000000;background-color: #ddffdd">+defined via <code>defsystem</code>, and generally is unnecessary. In the
+simple case, source files will be found in the same directory as the
+system or, in the case of modules, in a subdirectory with the same name
+as the module.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Instead, ASDF follows a hairy set of rules that are designed so that
- <ol type=1 start=1>
-<li><code>find-system</code>
</span><span style="color: #000000;background-color: #ddffdd">+<p>More specifically, ASDF follows a hairy set of rules that are designed so that
+</p><ol>
+<li> <code>find-system</code>
</span> will load a system from disk
and have its pathname default to the right place.
<span style="color: #000000;background-color: #ffdddd">- <li>This pathname information will not be overwritten with
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> This pathname information will not be overwritten with
</span> <code>*default-pathname-defaults*</code>
(which could be somewhere else altogether)
<span style="color: #000000;background-color: #ffdddd">-if the user loads up the <samp><span class="file">.asd</span></samp> file into his editor
</span><span style="color: #000000;background-color: #ddffdd">+if the user loads up the <samp>.asd</samp> file into his editor
</span> and interactively re-evaluates that form.
<span style="color: #000000;background-color: #ffdddd">- </ol>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ol>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If a system is being loaded for the first time,
</span><span style="color: #000000;background-color: #ddffdd">+<p>If a system is being loaded for the first time,
</span> its top-level pathname will be set to:
<span style="color: #000000;background-color: #ddffdd">+</p>
+<ul>
+<li> The host/device/directory parts of <code>*load-truename*</code>,
+if it is bound.
+</li><li> <code>*default-pathname-defaults*</code>, otherwise.
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- <ul>
-<li>The host/device/directory parts of <code>*load-truename*</code>,
-if it is bound.
-<li><code>*default-pathname-defaults*</code>, otherwise.
-</ul>
-
- <p>If a system is being redefined, the top-level pathname will be
-
- <ul>
-<li>changed, if explicitly supplied or obtained from <code>*load-truename*</code>
</span><span style="color: #000000;background-color: #ddffdd">+<p>If a system is being redefined, the top-level pathname will be
+</p>
+<ul>
+<li> changed, if explicitly supplied or obtained from <code>*load-truename*</code>
</span> (so that an updated source location is reflected in the system definition)
<span style="color: #000000;background-color: #ffdddd">- <li>changed if it had previously been set from <code>*default-pathname-defaults*</code>
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> changed if it had previously been set from <code>*default-pathname-defaults*</code>
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>left as before, if it had previously been set from <code>*load-truename*</code>
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> left as before, if it had previously been set from <code>*load-truename*</code>
</span> and <code>*load-truename*</code> is currently unbound
(so that a developer can evaluate a <code>defsystem</code> form
from within an editor without clobbering its source location)
<span style="color: #000000;background-color: #ffdddd">-</ul>
-
-<h4 class="subsection">5.3.11 if-feature option</h4>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ul>
</span>
<span style="color: #000000;background-color: #ddffdd">+<a name="if_002dfeature-option"></a>
+<h4 class="subsection">6.3.12 if-feature option</h4>
+<a name="index-_003aif_002dfeature-component-option"></a>
+<a name="if_002dfeature_002doption"></a>
</span> <p>This option allows you to specify a feature expression to be evaluated
<span style="color: #000000;background-color: #ffdddd">-as if by <code>#+</code> to conditionally include a component in your build.
</span><span style="color: #000000;background-color: #ddffdd">+as if by <code>#+</code> to conditionally include a component in your build.
</span> If the expression is false, the component is dropped
<span style="color: #000000;background-color: #ffdddd">-as well as any dependency pointing to it.
</span><span style="color: #000000;background-color: #ddffdd">+as well as any dependency pointing to it.
</span> As compared to using <code>#+</code> which is expanded at read-time,
this allows you to have an object in your component hierarchy
<span style="color: #000000;background-color: #ffdddd">-that can be used for manipulations beside building your project.
-This option was added in ASDF 3.
-
-<h4 class="subsection">5.3.12 if-component-dep-fails option</h4>
-
-<p>This option was removed in ASDF 3.
</span><span style="color: #000000;background-color: #ddffdd">+that can be used for manipulations beside building your project, and
+that is accessible to outside code that wishes to reason about system
+structure.
+</p>
+<p>Programmers should be careful to consider <strong>when</strong> the
+<code>:if-feature</code> is evaluated. Recall that ASDF first computes a
+build plan, and then executes that plan. ASDF will check to see whether
+or not a feature is present <strong>at planning time</strong>, not during the
+build. It follows that one cannot use <code>:if-feature</code> to check
+features that are set during the course of the build. It can only be
+used to check the state of features before any build operations have
+been performed.
+</p>
+<p>This option was added in ASDF 3. For more information,
+See <a href="#required_002dfeatures">Required features</a>.
+</p>
+<a name="if_002dcomponent_002ddep_002dfails-option"></a>
+<h4 class="subsection">6.3.13 if-component-dep-fails option</h4>
+<a name="index-_003aif_002dcomponent_002ddep_002dfails-component-option"></a>
+<p>This option was removed in ASDF 3.
</span> Its semantics was limited in purpose and dubious to explain,
<span style="color: #000000;background-color: #ffdddd">-and its implementation was breaking a hole into the ASDF object model.
</span><span style="color: #000000;background-color: #ddffdd">+and its implementation was breaking a hole into the ASDF object model.
</span> Please use the <code>if-feature</code> option instead.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="feature-requirement"></a>
+<h4 class="subsection">6.3.14 feature requirement</h4>
+<p>This requirement was removed in ASDF 3.1. Please do not use it. In
+most cases, <code>:if-feature</code> (see <a href="#if_002dfeature_002doption">if-feature-option</a>) will provide
+an adequate substitute.
+</p>
+<p>The <code>feature</code> requirement used to ensure that a chain of component
+dependencies would fail when a key feature was absent.
+Used in conjunction with <code>:if-component-dep-fails</code>
+this provided
+a roundabout way to express conditional compilation.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Other-code-in-.asd-files"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
</span> <a name="Other-code-in-_002easd-files"></a>
<span style="color: #000000;background-color: #ffdddd">-
-<h3 class="section">5.4 Other code in .asd files</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<a name="Other-code-in-_002easd-files-1"></a>
+<h3 class="section">6.4 Other code in .asd files</h3>
</span>
<p>Files containing <code>defsystem</code> forms
<span style="color: #000000;background-color: #ffdddd">-are regular Lisp files that are executed by <code>load</code>.
-Consequently, you can put whatever Lisp code you like into these files.
</span><span style="color: #000000;background-color: #ddffdd">+are regular Lisp files that are executed by <code>load</code>.
+Consequently, you can put whatever Lisp code you like into these files.
</span> However, it is recommended to keep such forms to a minimal,
and to instead define <code>defsystem</code> extensions
that you use with <code>:defsystem-depends-on</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>If however, you might insist on including code in the <code>.asd</code> file itself,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If however, you might insist on including code in the <samp>.asd</samp> file itself,
</span> e.g., to examine and adjust the compile-time environment,
<span style="color: #000000;background-color: #ffdddd">-possibly adding appropriate features to <code>*features*</code>.
</span><span style="color: #000000;background-color: #ddffdd">+possibly adding appropriate features to <code>*features*</code>.
</span> If so, here are some conventions we recommend you follow,
so that users can control certain details of execution
<span style="color: #000000;background-color: #ffdddd">-of the Lisp in <samp><span class="file">.asd</span></samp> files:
-
- <ul>
-<li>Any informative output
</span><span style="color: #000000;background-color: #ddffdd">+of the Lisp in <samp>.asd</samp> files:
+</p>
+<ul>
+<li> Any informative output
</span> (other than warnings and errors,
<span style="color: #000000;background-color: #ffdddd">-which are the condition system's to dispose of)
</span><span style="color: #000000;background-color: #ddffdd">+which are the condition system’s to dispose of)
</span> should be sent to the standard CL stream <code>*standard-output*</code>,
so that users can easily control the disposition
<span style="color: #000000;background-color: #ffdddd">-of output from ASDF operations.
-</ul>
-
-<p><a name="The-object-model-of-ASDF"></a>
-
-<!-- node-name, next, previous, up -->
-<h2 class="chapter">6 The object model of ASDF</h2>
-
-<p>ASDF is designed in an object-oriented way from the ground up.
-Both a system's structure and the operations that can be performed on systems
-follow a extensible protocol.
-
- <p>This allows the addition of behaviours:
-for example, <code>cffi</code> adds support of special FFI description files
-to interface with C libraries and of wrapper files to embed C code in Lisp;
-<code>abcl-jar</code> supports creating Java JAR archives in ABCL;
-and <code>poiu</code> supports for compiling code in parallel using background processes.
</span><span style="color: #000000;background-color: #ddffdd">+of output from ASDF operations.
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>This chapter deals with <code>component</code>s and <code>operation</code>s.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>A <code>component</code> represents an individual source file or a group of source files,
-and the things that get transformed into.
-A <code>system</code> is a component at the top level of the component hierarchy.
-A <code>source-file</code> is a component representing a single source-file
-and the successive output files into which it is transformed.
-A <code>module</code> is an intermediate component itself grouping several other components,
-themselves source-files or further modules.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="The-package_002dinferred_002dsystem-extension"></a>
+<a name="The-package_002dinferred_002dsystem-extension-1"></a>
+<h3 class="section">6.5 The package-inferred-system extension</h3>
+
+<p>Starting with release 3.1.2,
+ASDF supports a one-package-per-file style of programming,
+whereby each file is its own system,
+and dependencies are deduced from the <code>defpackage</code> form
+(or its variant <code>uiop:define-package</code>).
+</p>
+<p>In this style, packages refer to a system with the same name (downcased);
+and if a system is defined with <code>:class package-inferred-system</code>,
+then system names that start with that name
+(using the slash <code>/</code> separator)
+refer to files under the filesystem hierarchy where the system is defined.
+For instance, if system <code>my-lib</code> is defined in
+<samp>/foo/bar/my-lib/my-lib.asd</samp>, then system <code>my-lib/src/utility</code>
+will be found in file <samp>/foo/bar/my-lib/src/utility.lisp</samp>.
+</p>
+<p>This style was made popular by <code>faslpath</code> and <code>quick-build</code> before,
+and at the cost of a stricter package discipline,
+seems to make for more maintainable code.
+It is used by ASDF itself (starting with ASDF 3), by <code>lisp-interface-library</code>,
+and a few other libraries.
+</p>
+<p>To use this style, choose a toplevel system name, e.g. <code>my-lib</code>,
+and create a file <samp>my-lib.asd</samp>
+with the <code>:class :package-inferred-system</code> option in its <code>defsystem</code>.
+For instance:
+</p><div class="example">
+<pre class="example">#-asdf3.1 (error "my-lib requires ASDF 3.1")
+(defsystem "my-lib"
+ :class :package-inferred-system
+ :depends-on ("my-lib/interface/all"
+ "my-lib/src/all"
+ "my-lib/extras/all")
+ :in-order-to ((test-op (load-op "my-lib/test/all")))
+ :perform (test-op (o c) (symbol-call :my-lib/test/all :test-suite)))
+
+(defsystem "my-lib/test" :depends-on ("my-lib/test/all"))
+
+(register-system-packages "my-lib/interface/all" '(:my-lib-interface))
+(register-system-packages "my-lib/src/all" '(:my-lib-implementation))
+(register-system-packages "my-lib/test/all" '(:my-lib-test))
+
+(register-system-packages
+ "closer-mop"
+ '(:c2mop :closer-common-lisp :c2cl :closer-common-lisp-user :c2cl-user))
+</pre></div>
+
+<p>In the code above, the first line checks that we are using ASDF 3.1,
+which provides <code>package-inferred-system</code>.
+</p>
+<p>The function <code>register-system-packages</code> has to be called to register
+packages used or provided by your system and its components
+where the name of the system that provides the package
+is not the downcase of the package name.
+</p>
+<p>Then, file <samp>interface/order.lisp</samp> under the <code>lil</code> hierarchy,
+that defines abstract interfaces for order comparisons,
+starts with the following form,
+dependencies being trivially computed from the <code>:use</code> and <code>:mix</code> clauses:
+</p>
+<div class="example">
+<pre class="example">(uiop:define-package :lil/interface/order
+ (:use :closer-common-lisp
+ :lil/interface/definition
+ :lil/interface/base
+ :lil/interface/eq :lil/interface/group)
+ (:mix :fare-utils :uiop :alexandria)
+ (:export ...))
+</pre></div>
+
+<p>ASDF can tell that this file depends on system <code>closer-mop</code> (registered above),
+<code>lil/interface/definition</code>, <code>lil/interface/base</code>,
+<code>lil/interface/eq</code>, and <code>lil/interface/group</code>
+(package and system names match, and they will be looked up hierarchically).
+</p>
+<p>ASDF also detects dependencies from <code>:import-from</code> clauses.
+You may thus import a well-defined set of symbols from an existing package
+as loaded from suitably named system;
+or if you prefer to use any such symbol fully qualified by a package prefix,
+you may declare a dependency on such a package and its corresponding system
+via an <code>:import-from</code> clause with an empty list of symbols, as in:
+</p>
+<div class="example">
+<pre class="example">(defpackage :foo/bar
+ (:use :cl)
+ (:import-from :foo/baz #:sym1 #:sym2)
+ (:import-from :foo/quux)
+ (:export ...))
+</pre></div>
+
+<p>The form <code>uiop:define-package</code> is supported as well as <code>defpackage</code>,
+and has many options that prove useful in this context,
+such as <code>:use-reexport</code> and <code>:mix-reexport</code>
+that allow for “inheritance” of symbols being exported.
+</p>
+<p>Note that starting with ASDF 3.1.5.6 only, ASDF will look for source files under
+the <code>component-pathname</code> as specified via the <code>:pathname</code> option,
+whereas earlier versions ignore this option and use the <code>system-source-directory</code>
+where the <samp>.asd</samp> file resides.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>An <code>Operation</code> represents a transformation that can be performed on a component,
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="The-object-model-of-ASDF"></a>
+<a name="The-Object-model-of-ASDF"></a>
+<h2 class="chapter">7 The Object model of ASDF</h2>
+<a name="index-component-1"></a>
+<a name="index-operation-1"></a>
+
+<p>ASDF is designed in an object-oriented way from the ground up.
+Both a system’s structure and the operations that can be performed on systems
+follow a extensible protocol, allowing programmers to add new behaviours to ASDF.
+For example, <code>cffi</code> adds support for special FFI description files
+that interface with C libraries and for wrapper files that embed C code in Lisp.
+<code>abcl-jar</code> supports creating Java JAR archives in ABCL.
+<code>poiu</code> supports compiling code in parallel using background processes.
+</p>
+<p>The key classes in ASDF are <code>component</code> and <code>operation</code>.
+A <code>component</code> represents an individual source file or a group of source files,
+and the products (e.g., fasl files) produced from it.
+An <code>operation</code> represents a transformation that can be performed on a component,
</span> turning them from source files to intermediate results to final outputs.
<span style="color: #000000;background-color: #ddffdd">+Components are related by <em>dependencies</em>, specified in system
+definitions.
+</p>
+<p>When ordered to <code>operate</code> with some operation on a component (usually a system),
+ASDF will first compute a <em>plan</em>
+by traversing the dependency graph using function <code>make-plan</code>.<a name="DOCF10" href="#FOOT10"><sup>10</sup></a>
+The resulting plan object contains an ordered list of <em>actions</em>.
+An action is a pair of an <code>operation</code> and a <code>component</code>,
+representing a particular build step to be <code>perform</code>ed.
+The ordering of the plan ensures that no action is performed before
+all its dependencies have been fulfilled.<a name="DOCF11" href="#FOOT11"><sup>11</sup></a>
+</p>
+<p>In this chapter, we describe ASDF’s object-oriented protocol,
+the classes that make it up, and the generic functions on those classes.
+These generic functions often take
+both an operation and a component as arguments:
+much of the power and configurability of ASDF is provided by
+this use of CLOS’s multiple dispatch.
+We will describe the built-in component and operation classes, and
+explain how to extend the ASDF protocol by defining new classes and
+methods for ASDF’s generic functions.
+We will also describe the many <em>hooks</em> that can be configured to
+customize the behaviour of existing <em>functions</em>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>A pair of an <code>operation</code> and a <code>component</code> is called an <code>action</code>.
-An <code>action</code> represents a particular build step to be <code>perform</code>ed,
-after all its dependencies have been fulfilled.
-In the ASDF model, actions depend on other actions.
-The term <em>action</em> itself was used by Kent Pitman in his old article,
-but was only used by ASDF hackers starting with the ASDF 2;
-but the concept is ubiquitous since the very beginning of ASDF 1,
-though previously implicit.
-
- <p>Then, there are many <em>functions</em> available
-to users, extenders and implementers of ASDF
-to use, define or implement the activities
-that are part of building your software.
-Though they manipulate <code>action</code>s,
-most of these functions do not take as an argument
-a reified pair (a <code>cons</code> cell) of an operation and a component;
-instead, they usually take two separate arguments,
-which allows to take advantage of the power CLOS-style multiple dispatch
-for fun and profit.
-
- <p>There are many <em>hooks</em> in which to add functionality,
-by customizing the behavior of existing <em>functions</em>.
-
- <p>Last but not least is the notion of <em>dependency</em> between two actions.
-The structure of dependencies between actions is
-a directed <em>dependency graph</em>.
-ASDF is invoked by being told to <em>operate</em>
-with some <em>operation</em> on some toplevel <em>system</em>;
-it will then <em>traverse</em> the graph and build a <em>plan</em>
-that follows its structure.
-To be successfully buildable, this graph of actions but be acyclic.
-If, as a user, extender or implementer of ASDF, you fail
-to keep the dependency graph without cycles,
-ASDF will fail loudly as it eventually finds one.
-To clearly distinguish the direction of dependencies,
-ASDF 3 uses the words <em>requiring</em> and <em>required</em>
-as applied to an action depending on the other:
-the requiring action <code>depends-on</code> the completion of all required actions
-before it may itself be <code>perform</code>ed.
-
- <p>Using the <code>defsystem</code> syntax, users may easily express
-direct dependencies along the graph of the object hierarchy:
-between a component and its parent, its children, and its siblings.
-By defining custom CLOS methods, you can express more elaborate dependencies as you wish.
-Most common operations, such as <code>load-op</code>, <code>compile-op</code> or <code>load-source-op</code>
-are automatically propagate “downward” the component hierarchy and are “covariant” with it:
-to act the operation on the parent module, you must first act it on all the children components,
-with the action on the parent being parent of the action on each child.
-Other operations, such as <code>prepare-op</code> and <code>prepare-source-op</code>
-(introduced in ASDF 3) are automatically propagated “upward” the component hierarchy
-and are “contravariant” with it:
-to perform the operation of preparing for compilation of a child component,
-you must perform the operation of preparing for compilation of its parent component, and so on,
-ensuring that all the parent's dependencies are (compiled and) loaded
-before the child component may be compiled and loaded.
-Yet other operations, such as <code>test-op</code> or <code>load-fasl-op</code>
-remain at the system level, and are not propagated along the hierarchy,
-but instead do something global on the system.
-
-<p><a name="Operations"></a>
-
-<!-- node-name, next, previous, up -->
-<h3 class="section">6.1 Operations</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Operations"></a>
+<a name="Operations-1"></a>
+<h3 class="section">7.1 Operations</h3>
+<a name="index-operation"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-operation-28"></a>
-An <dfn>operation</dfn> object of the appropriate type is instantiated
</span><span style="color: #000000;background-color: #ddffdd">+<p>An <em>operation</em> object of the appropriate type is instantiated
</span> whenever the user wants to do something with a system like
<span style="color: #000000;background-color: #ddffdd">+</p>
+<ul>
+<li> compile all its files
+</li><li> load the files into a running lisp environment
+</li><li> copy its source files somewhere else
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- <ul>
-<li>compile all its files
-<li>load the files into a running lisp environment
-<li>copy its source files somewhere else
-</ul>
-
- <p>Operations can be invoked directly, or examined
-to see what their effects would be without performing them.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Operations can be invoked directly, or examined
+to see what their effects would be without performing them.
</span> There are a bunch of methods specialised on operation and component type
that actually do the grunt work.
<span style="color: #000000;background-color: #ddffdd">+Operations are invoked on systems via <code>operate</code> (see <a href="#operate">operate</a>).
+</p>
+<p>ASDF contains a number of pre-defined <tt>operation</tt> classes for common,
+and even fairly uncommon tasks that you might want to do with it.
+In addition, ASDF contains “abstract” <tt>operation</tt> classes that
+programmers can use as building blocks to define ASDF extensions. We
+discuss these in turn below.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The operation object contains whatever state is relevant for this purpose
-(perhaps a list of visited nodes, for example)
-but primarily is a nice thing to specialise operation methods on
-and easier than having them all be <code>EQL</code> methods.
-
- <p>Operations are invoked on systems via <code>operate</code>.
-<a name="operate"></a>
-
-<div class="defun">
-— Generic function: <code>operate</code><var> operation system &rest initargs &key </var><code>force</code> <code>force-not</code> <code>verbose</code><var> &allow-other-keys<a name="index-g_t_0040code_007boperate_007d-29"></a></var><br>
-— Generic function: <code>oos</code><var> operation system &rest initargs &key &allow-other-keys<a name="index-g_t_0040code_007boos_007d-30"></a></var><br>
-<blockquote><p><code>operate</code> invokes <var>operation</var> on <var>system</var>.
-<code>oos</code> is a synonym for <code>operate</code>.
-
- <p><var>operation</var> is a symbol that is passed, along with the supplied
-<var>initargs</var>, to <code>make-instance</code> to create the operation object.
-<var>system</var> is a system designator.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The <var>initargs</var> are passed to the <code>make-instance</code> call
-when creating the operation object.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Operations are invoked on systems via <code>operate</code>.
+<a name="operate"></a></p><dl>
+<dt><a name="index-operate-1"></a>Generic function: <strong><code>operate</code></strong> <em><var>operation</var> <var>component</var> &rest <var>initargs</var> &key <code>force</code> <code>force-not</code> <code>verbose</code> &allow-other-keys</em></dt>
+<dt><a name="index-oos-1"></a>Generic function: <strong><code>oos</code></strong> <em><var>operation</var> <var>component</var> &rest <var>initargs</var> &key &allow-other-keys</em></dt>
+<dd><p><code>operate</code> invokes <var>operation</var> on <var>system</var>.
+<code>oos</code> is a synonym for <code>operate</code> (it stands for operate-on-system).
+</p>
+<p><var>operation</var> is a symbol that is passed,
+along with the supplied <var>initargs</var>,
+to <code>make-operation</code> (which will call <code>make-instance</code>)
+to create the operation object.
+<var>component</var> is a component designator,
+usually a string or symbol that designates a system,
+sometimes a list of strings or symbols that designate a subcomponent of a system.
+</p>
+<p>The <var>initargs</var> are passed to the <code>make-instance</code> call
+when creating the operation object.
</span> Note that dependencies may cause the operation
to invoke other operations on the system or its components:
the new operations will be created
with the same <var>initargs</var> as the original one.
<span style="color: #000000;background-color: #ffdddd">-
- <p>If <var>force</var> is <code>:all</code>, then all systems
-are forced to be recompiled even if not modified since last compilation.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If <var>force</var> is <code>:all</code>, then all systems
+are forced to be recompiled even if not modified since last compilation.
</span> If <var>force</var> is <code>t</code>, then only the system being loaded
is forced to be recompiled even if not modified since last compilation,
<span style="color: #000000;background-color: #ffdddd">-but other systems are not affected.
</span><span style="color: #000000;background-color: #ddffdd">+but other systems are not affected.
</span> If <var>force</var> is a list, then it specifies a list of systems that
<span style="color: #000000;background-color: #ffdddd">-are forced to be recompiled even if not modified since last compilation.
</span><span style="color: #000000;background-color: #ddffdd">+are forced to be recompiled even if not modified since last compilation.
</span> If <var>force-not</var> is <code>:all</code>, then all systems
<span style="color: #000000;background-color: #ffdddd">-are forced not to be recompiled even if modified since last compilation.
-If <var>force-not</var> is <code>t</code>, then only the system being loaded
-is forced not to be recompiled even if modified since last compilation,
-but other systems are not affected.
</span><span style="color: #000000;background-color: #ddffdd">+are forced not to be recompiled even if modified since last compilation.
+If <var>force-not</var> is <code>t</code>, then all systems but the system being loaded
+are forced not to be recompiled even if modified since last compilation
+(note: this was changed in ASDF 3.1.2).
</span> If <var>force-not</var> is a list, then it specifies a list of systems that
<span style="color: #000000;background-color: #ffdddd">-are forced not to be recompiled even if modified since last compilation.
-<var>force</var> takes precedences over <var>force-not</var>;
-both of them apply to systems that are dependencies and were already compiled.
</span><span style="color: #000000;background-color: #ddffdd">+are forced not to be recompiled even if modified since last compilation.
+</p>
+<a name="index-register_002dimmutable_002dsystem"></a>
+<a name="index-immutable-systems"></a>
+<p>Both <var>force</var> and <var>force-not</var> apply to systems that are dependencies and were already compiled.
+<var>force-not</var> takes precedences over <var>force</var>,
+as it should, really, but unhappily only since ASDF 3.1.2.
+Moreover, systems which have been registered as immutable by <code>register-immutable-system</code> (since ASDF 3.1.5)
+are always considered <var>forced-not</var>, and even their <samp>.asd</samp> are not refreshed from the filesystem.
+See <a href="#Miscellaneous-Functions">Miscellaneous Functions</a>.
+</p>
+<a name="index-traverse"></a>
+<p>To see what <code>operate</code> would do, you can use:
+</p><div class="example">
+<pre class="example">(asdf:traverse operation-class system-name)
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>To see what <code>operate</code> would do, you can use:
- <pre class="example"> (asdf:traverse operation-class system-name)
-</pre>
- </blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+</dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Predefined-operations-of-ASDF"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h4 class="subsection">6.1.1 Predefined operations of ASDF</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>All the operations described in this section are in the <code>asdf</code> package.
-They are invoked via the <code>operate</code> generic function.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Predefined-operations-of-ASDF"></a>
+<a name="Predefined-operations-of-ASDF-1"></a>
+<h4 class="subsection">7.1.1 Predefined operations of ASDF</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (asdf:operate 'asdf:<var>operation-name</var> :<var>system-name</var> {<var>operation-options ...</var>})
-</pre>
- <div class="defun">
-— Operation: <code>compile-op</code><var><a name="index-g_t_0040code_007bcompile_002dop_007d-31"></a></var><br>
-<blockquote>
- <p>This operation compiles the specified component.
-A <code>cl-source-file</code> will be <code>compile-file</code>'d.
</span><span style="color: #000000;background-color: #ddffdd">+<p>All the operations described in this section are in the <code>asdf</code> package.
+They are invoked via the <code>operate</code> generic function.
+</p>
+<div class="lisp">
+<pre class="lisp">(asdf:operate 'asdf:<var>operation-name</var> :<var>system-name</var> {<var>operation-options ...</var>})
+</pre></div>
+
+<dl>
+<dt><a name="index-compile_002dop"></a>Operation: <strong><code>compile-op</code></strong></dt>
+<dd>
+<p>This operation compiles the specified component.
+A <code>cl-source-file</code> will be <code>compile-file</code>’d.
</span> All the children and dependencies of a system or module
will be recursively compiled by <code>compile-op</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>compile-op</code> depends on <code>prepare-op</code> which
-itself depends on a <code>load-op</code> of all of a component's dependencies,
-as well as of its parent's dependencies.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>compile-op</code> depends on <code>prepare-op</code> which
+itself depends on a <code>load-op</code> of all of a component’s dependencies,
+as well as of its parent’s dependencies.
</span> When <code>operate</code> is called on <code>compile-op</code>,
all these dependencies will be loaded as well as compiled;
yet, some parts of the system main remain unloaded,
<span style="color: #000000;background-color: #ffdddd">-because nothing depends on them.
-Use <code>load-op</code> to load a system.
-</p></blockquote></div>
-
-<div class="defun">
-— Operation: <code>load-op</code><var><a name="index-g_t_0040code_007bload_002dop_007d-32"></a></var><br>
-<blockquote>
- <p>This operation loads the compiled code for a specified component.
</span><span style="color: #000000;background-color: #ddffdd">+because nothing depends on them.
+Use <code>load-op</code> to load a system.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-load_002dop"></a>Operation: <strong><code>load-op</code></strong></dt>
+<dd>
+<p>This operation loads the compiled code for a specified component.
</span> A <code>cl-source-file</code> will have its compiled fasl <code>load</code>ed,
<span style="color: #000000;background-color: #ffdddd">-which fasl is the output of <code>compile-op</code> that <code>load-op</code> depends on.
-All the children and dependencies of a system or module
-will be recursively loaded by <code>load-op</code>.
-
- <p><code>load-op</code> depends on <code>prepare-op</code> which
-itself depends on a <code>load-op</code> of all of a component's dependencies,
-as well as of its parent's dependencies.
-</p></blockquote></div>
-
-<div class="defun">
-— Operation: <code>prepare-op</code><var><a name="index-g_t_0040code_007bprepare_002dop_007d-33"></a></var><br>
-<blockquote>
- <p>This operation ensures that the dependencies of a component
</span><span style="color: #000000;background-color: #ddffdd">+which fasl is the output of <code>compile-op</code> that <code>load-op</code> depends on.
+</p>
+<p><code>load-op</code> will recursively load all the children of a system or module.
+</p>
+<p><code>load-op</code> also depends on <code>prepare-op</code> which
+itself depends on a <code>load-op</code> of all of a component’s dependencies,
+as well as of its parent’s dependencies.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-prepare_002dop"></a>Operation: <strong><code>prepare-op</code></strong></dt>
+<dd>
+<p>This operation ensures that the dependencies of a component
</span> and its recursive parents are loaded (as per <code>load-op</code>),
as a prerequisite before <code>compile-op</code> and <code>load-op</code> operations
<span style="color: #000000;background-color: #ffdddd">-may be performed on a given component.
-</p></blockquote></div>
-
-<div class="defun">
-— Operation: <code>load-source-op</code><var>, </var><code>prepare-source-op</code><var><a name="index-g_t_0040code_007bload_002dsource_002dop_007d-34"></a></var><br>
-<blockquote>
- <p><code>load-source-op</code> will load the source for the files in a module
-rather than they compiled fasl output.
</span><span style="color: #000000;background-color: #ddffdd">+may be performed on a given component.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-load_002dsource_002dop"></a>Operation: <strong><code>load-source-op</code></strong> <em>, <code>prepare-source-op</code></em></dt>
+<dd>
+<p><code>load-source-op</code> will load the source for the files in a module
+rather than the compiled fasl output.
</span> It has a <code>prepare-source-op</code> analog to <code>prepare-op</code>,
that ensures the dependencies are themselves loaded via <code>load-source-op</code>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+</dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>There is no provision in ASDF for ensuring that
-some components are always loaded as source, while others are always compiled.
-While this idea often comes up in discussions,
-it actually doesn't play well with either the linking model of ECL
-or with various bundle operations (see below), and is eventually not workable;
-also the dependency model of ASDF would have to be modified incompatibly
-to allow for such trick.
-If your code doesn't compile cleanly, fix it.
-If compilation makes it slow, use <code>declaim</code> or <code>eval-when</code>
-to adjust your compiler settings,
-or eschew compilation by <code>eval</code>uating a quoted source form at load-time.
-</p></blockquote></div>
-
- <p><a name="test_002dop"></a>
-
-<div class="defun">
-— Operation: <code>test-op</code><var><a name="index-g_t_0040code_007btest_002dop_007d-35"></a></var><br>
-<blockquote>
- <p>This operation will perform some tests on the module.
-The default method will do nothing.
</span><span style="color: #000000;background-color: #ddffdd">+<a name="test_002dop"></a><dl>
+<dt><a name="index-test_002dop"></a>Operation: <strong><code>test-op</code></strong></dt>
+<dd>
+<p>This operation will perform some tests on the module.
+The default method will do nothing.
</span> The default dependency is to require
<span style="color: #000000;background-color: #ffdddd">-<code>load-op</code> to be performed on the module first.
-The default <code>operation-done-p</code> is that the operation is <em>never</em> done
-—
</span><span style="color: #000000;background-color: #ddffdd">+<code>load-op</code> to be performed on the module first.
+Its <code>operation-done-p</code> method returns <code>nil</code>,
+which means that the operation is <em>never</em> done
+–
</span> we assume that if you invoke the <code>test-op</code>,
you want to test the system, even if you have already done so.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The results of this operation are not defined by ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The results of this operation are not defined by ASDF.
</span> It has proven difficult to define how the test operation
should signal its results to the user
in a way that is compatible with all of the various test libraries
<span style="color: #000000;background-color: #ffdddd">-and test techniques in use in the community.
-
- <p>People typically define <code>test-op</code> methods like thus:
- <pre class="example"> (defmethod perform ((o asdf:test-op)
- (s (eql (asdf:find-system <var>:my-system</var>))))
- (asdf:load-system <var>:my-system-test</var>)
- (funcall (read-from-string "my-system-test:test-suite")))
-</pre>
- <p>Using <code>load-system</code> in the perform method
-rather than an <code>:in-order-to</code> dependency,
-is sometimes necessary for backward compatibility with ASDF 2 and older,
-to avoid circular dependencies that could arise
-because of the way these old versions propagate dependencies.
-
- <p>If you don't care for compatibility with ASDF 2,
-you could use the following options in your <code>defsystem</code> form:
- <pre class="example"> :in-order-to ((test-op (load-op :my-system-test)))
- :perform (test-op (o c) (symbol-call :my-system-test :test-suite))
-</pre>
- </blockquote></div>
-
-<div class="defun">
-— Operation: <code>fasl-op</code><var>, </var><code>monolithic-fasl-op</code><var>, </var><code>load-fasl-op</code><var>, </var><code>binary-op</code><var>, </var><code>monolithic-binary-op</code><var>, </var><code>lib-op</code><var>, </var><code>monolithic-lib-op</code><var>, </var><code>dll-op</code><var>, </var><code>monolithic-dll-op</code><var>, </var><code>program-op</code><var><a name="index-g_t_0040code_007bfasl_002dop_007d-36"></a></var><br>
-<blockquote>
- <p>These are “bundle” operations, that can create a single-file “bundle”
</span><span style="color: #000000;background-color: #ddffdd">+and test techniques in use in the community, and
+given the fact that ASDF operations do not return a value indicating
+success or failure.
+For those willing to go to the effort, we suggest defining conditions to
+signal when a <code>test-op</code> fails, and storing in those conditions
+information that describes which tests fail.
+</p>
+<p>People typically define a separate test <em>system</em> to hold the tests.
+Doing this avoids unnecessarily adding a test framework as a dependency
+on a library. For example, one might have
+</p><div class="lisp">
+<pre class="lisp">(defsystem "foo"
+ :in-order-to ((test-op (test-op "foo/test")))
+ ...)
+
+(defsystem "foo/test"
+ :depends-on ("foo" "fiveam") ; fiveam is a test framework library
+ ...)
+</pre></div>
+
+<p>Then one defines <code>perform</code> methods on
+<code>test-op</code> such as the following:
+</p><div class="lisp">
+<pre class="lisp">(defsystem "foo/test"
+ :depends-on ("foo" "fiveam") ; fiveam is a test framework library
+ :perform (test-op (o s)
+ (uiop:symbol-call :fiveam '#:run!
+ (uiop:find-symbol* '#:foo-test-suite
+ :foo-tests)))
+ ...)
+</pre></div>
+
+</dd></dl>
+
+
+
+<dl>
+<dt><a name="index-compile_002dbundle_002dop"></a>Operation: <strong><code>compile-bundle-op</code></strong> <em>, <code>monolithic-compile-bundle-op</code>, <code>load-bundle-op</code>, <code>monolithic-load-bundle-op</code>, <code>deliver-asd-op</code>, <code>monolithic-deliver-asd-op</code>, <code>lib-op</code>, <code>monolithic-lib-op</code>, <code>dll-op</code>, <code>monolithic-dll-op</code>, <code>image-op</code>, <code>program-op</code></em></dt>
+<dd>
+<p>These are “bundle” operations, that can create a single-file “bundle”
</span> for all the contents of each system in an application,
or for the entire application.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>fasl-op</code> will create a single fasl file for each of the systems needed,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>compile-bundle-op</code> will create a single fasl file for each of the systems needed,
</span> grouping all its many fasls in one,
<span style="color: #000000;background-color: #ffdddd">-so you can deliver each system as a single fasl.
-<code>monolithic-fasl-op</code> will create a single fasl file for target system
</span><span style="color: #000000;background-color: #ddffdd">+so you can deliver each system as a single fasl
+<code>monolithic-compile-bundle-op</code> will create a single fasl file for the target system
</span> and all its dependencies,
<span style="color: #000000;background-color: #ffdddd">-so you can deliver your entire application as a single fasl.
-<code>load-fasl-op</code> will load the output of <code>fasl-op</code>
-(though if it the output is not up-to-date,
-it will load the intermediate fasls indeed as part of building it);
-this matters a lot on ECL, where the dynamic linking involved in loading
-tens of individual fasls can be noticeably more expensive
-than loading a single one.
-
- <p>Once you have created a fasl with <code>fasl-op</code>,
</span><span style="color: #000000;background-color: #ddffdd">+so you can deliver your entire application as a single fasl.
+<code>load-bundle-op</code> will load the output of <code>compile-bundle-op</code>.
+Note that if it the output is not up-to-date,
+<code>compile-bundle-op</code> may load the intermediate fasls as a side-effect.
+Bundling fasls together matters a lot on ECL,
+where the dynamic linking involved in loading tens of individual fasls
+can be noticeably more expensive than loading a single one.
+</p>
+<p>NB: <code>compile-bundle-op</code>, <code>monolithic-compile-bundle-op</code>, <code>load-bundle-op</code>, <code>monolithic-load-bundle-op</code>, <code>deliver-asd-op</code>, <code>monolithic-deliver-asd-op</code> were respectively called
+<code>fasl-op</code>, <code>monolithic-fasl-op</code>, <code>load-fasl-op</code>, <code>monolithic-load-fasl-op</code>, <code>binary-op</code>, <code>monolithic-binary-op</code> before ASDF 3.1.
+The old names still exist for backward compatibility,
+though they poorly label what is going on.
+</p>
+<p>Once you have created a fasl with <code>compile-bundle-op</code>,
</span> you can use <code>precompiled-system</code> to deliver it in a way
that is compatible with clients having dependencies on your system,
whether it is distributed as source or as a single binary;
<span style="color: #000000;background-color: #ffdddd">-the <samp><span class="file">.asd</span></samp> file to be delivered with the fasl will look like this:
- <pre class="example"> (defsystem :mysystem :class :precompiled-system
- :fasl (some expression that will evaluate to a pathname))
-</pre>
- <p>Or you can use <code>binary-op</code> to let ASDF create such a system for you
-as well as the <code>fasl-op</code> output, or <code>monolithic-binary-op</code>.
</span><span style="color: #000000;background-color: #ddffdd">+the <samp>.asd</samp> file to be delivered with the fasl will look like this:
+</p><div class="example">
+<pre class="example">(defsystem :mysystem :class :precompiled-system
+ :fasl (some expression that will evaluate to a pathname))
+</pre></div>
+<p>Or you can use <code>deliver-asd-op</code> to let ASDF create such a system for you
+as well as the <code>compile-bundle-op</code> output,
+or <code>monolithic-deliver-asd-op</code>.
</span> This allows you to deliver code for your systems or applications
<span style="color: #000000;background-color: #ffdddd">-as a single file.
</span><span style="color: #000000;background-color: #ddffdd">+as a single file.
</span> Of course, if you want to test the result in the current image,
<span style="color: #000000;background-color: #ffdddd">-<em>before</em> you try to use any newly created <samp><span class="file">.asd</span></samp> files,
</span><span style="color: #000000;background-color: #ddffdd">+<em>before</em> you try to use any newly created <samp>.asd</samp> files,
</span> you should not forget to <code>(asdf:clear-configuration)</code>
or at least <code>(asdf:clear-source-registry)</code>,
so it re-populates the source-registry from the filesystem.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The <code>program-op</code> operation will create an executable program
-from the specified system and its dependencies.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The <code>program-op</code> operation will create an executable program
+from the specified system and its dependencies.
</span> You can use UIOP for its pre-image-dump hooks, its post-image-restore hooks,
<span style="color: #000000;background-color: #ffdddd">-and its access to command-line arguments.
</span><span style="color: #000000;background-color: #ddffdd">+and its access to command-line arguments.
</span> And you can specify an entry point <code>my-app:main</code>
by specifying in your <code>defsystem</code>
<span style="color: #000000;background-color: #ffdddd">-the option <code>:entry-point "my-app:main"</code>.
</span><span style="color: #000000;background-color: #ddffdd">+the option <code>:entry-point "my-app:main"</code>.
</span> Depending on your implementation,
running <code>(asdf:operate 'asdf:program-op :my-app)</code>
<span style="color: #000000;background-color: #ffdddd">-may quit the current Lisp image upon completion.
</span><span style="color: #000000;background-color: #ddffdd">+may quit the current Lisp image upon completion.
</span> See the example in
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">test/hello-world-example.asd</span></samp> and <samp><span class="file">test/hello.lisp</span></samp>,
</span><span style="color: #000000;background-color: #ddffdd">+<samp>test/hello-world-example.asd</samp> and <samp>test/hello.lisp</samp>,
</span> as built and tested by
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">test/test-program.script</span></samp> and <samp><span class="file">test/make-hello-world.lisp</span></samp>.
-
- <p>There is also <code>lib-op</code>
-for building a linkable <samp><span class="file">.a</span></samp> file (Windows: <samp><span class="file">.lib</span></samp>)
</span><span style="color: #000000;background-color: #ddffdd">+<samp>test/test-program.script</samp> and <samp>test/make-hello-world.lisp</samp>.
+<code>image-op</code> will dump an image that may not be standalone
+and does not start its own function,
+but follows the usual execution convention of the underlying Lisp,
+just with more code pre-loaded,
+for use as an intermediate build result or with a wrapper invocation script.
+</p>
+<p>There is also <code>lib-op</code>
+for building a linkable <samp>.a</samp> file (Windows: <samp>.lib</samp>)
</span> from all linkable object dependencies (FFI files, and on ECL, Lisp files too),
<span style="color: #000000;background-color: #ffdddd">-and its monolithic equivalent <code>monolithic-lib-op</code>.
</span><span style="color: #000000;background-color: #ddffdd">+and its monolithic equivalent <code>monolithic-lib-op</code>.
</span> And there is also <code>dll-op</code>
(respectively its monolithic equivalent <code>monolithic-lib-op</code>)
<span style="color: #000000;background-color: #ffdddd">-for building a linkable <samp><span class="file">.so</span></samp> file
-(Windows: <samp><span class="file">.dll</span></samp>, MacOS X: <samp><span class="file">.dynlib</span></samp>)
</span><span style="color: #000000;background-color: #ddffdd">+for building a linkable <samp>.so</samp> file
+(Windows: <samp>.dll</samp>, MacOS X: <samp>.dynlib</samp>)
</span> to create a single dynamic library
for all the extra FFI code to be linked into each of your systems
(respectively your entire application).
<span style="color: #000000;background-color: #ffdddd">-
- <p>All these “bundle” operations are available since ASDF 3
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>All these “bundle” operations are available since ASDF 3
</span> on all actively supported Lisp implementations,
<span style="color: #000000;background-color: #ffdddd">-but may be unavailable on unmaintained legacy implementations.
</span><span style="color: #000000;background-color: #ddffdd">+but may be unavailable on unmaintained legacy implementations.
</span> This functionality was previously available for select implementations,
as part of a separate system <code>asdf-bundle</code>,
itself descended from the ECL-only <code>asdf-ecl</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The pathname of the output of bundle operations
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The pathname of the output of bundle operations
</span> is subject to output-translation as usual,
unless the operation is equal to
<span style="color: #000000;background-color: #ffdddd">-the <code>:build-operation</code> argument to <code>defsystem</code>.
-This behavior is not very satisfactory and may change in the future.
-Maybe you have suggestions on how to better configure it?
-</p></blockquote></div>
-
-<div class="defun">
-— Operation: <code>concatenate-source-op</code><var>, </var><code>monolithic-concatenate-source-op</code><var>, </var><code>load-concatenated-source-op</code><var>, </var><code>compile-concatenated-source-op</code><var>, </var><code>load-compiled-concatenated-source-op</code><var>, </var><code>monolithic-load-concatenated-source-op</code><var>, </var><code>monolithic-compile-concatenated-source-op</code><var>, </var><code>monolithic-load-compiled-concatenated-source-op</code><var><a name="index-g_t_0040code_007bconcatenate_002dsource_002dop_007d-37"></a></var><br>
-<blockquote>
- <p>These operation, as their respective names indicate,
-consist in concatenating all <code>cl-source-file</code> source files in a system
</span><span style="color: #000000;background-color: #ddffdd">+the <code>:build-operation</code> argument to <code>defsystem</code>.
+This behaviour is not very satisfactory and may change in the future.
+Maybe you have suggestions on how to better configure it?
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-concatenate_002dsource_002dop"></a>Operation: <strong><code>concatenate-source-op</code></strong> <em>, <code>monolithic-concatenate-source-op</code>, <code>load-concatenated-source-op</code>, <code>compile-concatenated-source-op</code>, <code>load-compiled-concatenated-source-op</code>, <code>monolithic-load-concatenated-source-op</code>, <code>monolithic-compile-concatenated-source-op</code>, <code>monolithic-load-compiled-concatenated-source-op</code></em></dt>
+<dd>
+<p>These operations, as their respective names indicate,
+will concatenate all the <code>cl-source-file</code> source files in a system
</span> (or in a system and all its dependencies, if monolithic),
in the order defined by dependencies,
<span style="color: #000000;background-color: #ffdddd">-then loading the result, or compiling then loading the result.
-
- <p>These operations are useful to deliver a system or application
</span><span style="color: #000000;background-color: #ddffdd">+then load the result, or compile and then load the result.
+</p>
+<p>These operations are useful to deliver a system or application
</span> as a single source file,
<span style="color: #000000;background-color: #ffdddd">-and for testing that said file loads properly, or compiles then loads properly.
-
- <p>ASDF itself is notably delivered as a single source file this way
</span><span style="color: #000000;background-color: #ddffdd">+and for testing that said file loads properly, or compiles and then loads properly.
+</p>
+<p>ASDF itself is delivered as a single source file this way,
</span> using <code>monolithic-concatenate-source-op</code>,
<span style="color: #000000;background-color: #ffdddd">-transcluding a prelude and the <code>uiop</code> library
-before the <code>asdf/defsystem</code> system itself.
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+prepending a prelude and the <code>uiop</code> library
+before the <code>asdf/defsystem</code> system itself.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Creating-new-operations"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h4 class="subsection">6.1.2 Creating new operations</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Creating-new-operations"></a>
+<a name="Creating-new-operations-1"></a>
+<h4 class="subsection">7.1.2 Creating new operations</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>ASDF was designed to be extensible in an object-oriented fashion.
</span><span style="color: #000000;background-color: #ddffdd">+<p>ASDF was designed to be extensible in an object-oriented fashion.
</span> To teach ASDF new tricks, a programmer can implement the behaviour he wants
by creating a subclass of <code>operation</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>ASDF's pre-defined operations are in no way “privileged”,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>ASDF’s pre-defined operations are in no way “privileged”,
</span> but it is requested that developers never use the <code>asdf</code> package
<span style="color: #000000;background-color: #ffdddd">-for operations they develop themselves.
-The rationale for this rule is that we don't want to establish a
</span><span style="color: #000000;background-color: #ddffdd">+for operations they develop themselves.
+The rationale for this rule is that we don’t want to establish a
</span> “global asdf operation name registry”,
but also want to avoid name clashes.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Your operation <em>must</em> usually provide methods
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Your operation <em>must</em> usually provide methods
</span> for one or more of the following generic functions:
<span style="color: #000000;background-color: #ffdddd">-
- <ul>
-<li><code>perform</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<ul>
+<li> <a name="index-perform"></a>
+<code>perform</code>
</span> Unless your operation, like <code>prepare-op</code>,
is for dependency propagation only,
the most important function for which to define a method
<span style="color: #aaaaaa">@@ -1757,271 +2174,411 @@ is usually <code>perform</code>,
</span> which will be called to perform the operation on a specified component,
after all dependencies have been performed.
<span style="color: #000000;background-color: #ffdddd">- <p>The <code>perform</code> method must call <code>output-files</code> (see below)
-to find out where to put its files,
</span><span style="color: #000000;background-color: #ddffdd">+<p>The <code>perform</code> method must call <code>input-files</code> and <code>output-files</code> (see below)
+to locate its inputs and outputs,
</span> because the user is allowed to override the method
<span style="color: #000000;background-color: #ffdddd">-or tweak the output-translation mechanism.
-Perform should only use the primary value returned by <code>output-files</code>.
</span><span style="color: #000000;background-color: #ddffdd">+or tweak the output-translation mechanism.
+Perform should only use the primary value returned by <code>output-files</code>.
</span> If one and only one output file is expected,
it can call <code>output-file</code> that checks that this is the case
and returns the first and only list element.
<span style="color: #000000;background-color: #ffdddd">-
- <li><code>output-files</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+</li><li> <a name="index-output_002dfiles"></a>
+<code>output-files</code>
</span> If your perform method has any output,
<span style="color: #000000;background-color: #ffdddd">-you must define a method for this function.
</span><span style="color: #000000;background-color: #ddffdd">+you must define a method for this function.
</span> for ASDF to determine where the outputs of performing operation lie.
<span style="color: #000000;background-color: #ffdddd">- <p>Your method may return two values, a list of pathnames, and a boolean.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Your method may return two values, a list of pathnames, and a boolean.
</span> If the boolean is <code>nil</code> (or you fail to return multiple values),
then enclosing <code>:around</code> methods may translate these pathnames,
e.g. to ensure object files are somehow stored
<span style="color: #000000;background-color: #ffdddd">-in some implementation-dependent cache.
</span><span style="color: #000000;background-color: #ddffdd">+in some implementation-dependent cache.
</span> If the boolean is <code>t</code> then the pathnames are marked
not be translated by the enclosing <code>:around</code> method.
<span style="color: #000000;background-color: #ffdddd">-
- <li><code>component-depends-on</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+</li><li> <a name="index-component_002ddepends_002don"></a>
+<code>component-depends-on</code>
</span> If the action of performing the operation on a component has dependencies,
you must define a method on <code>component-depends-on</code>.
<span style="color: #000000;background-color: #ffdddd">- <p>Your method will take as specialized arguments
</span><span style="color: #000000;background-color: #ddffdd">+<p>Your method will take as specialized arguments
</span> an operation and a component which together identify an action,
<span style="color: #000000;background-color: #ffdddd">-and return a list of entries describing actions that this action depends on.
</span><span style="color: #000000;background-color: #ddffdd">+and return a list of entries describing actions that this action depends on.
</span> The format of entries is described below.
<span style="color: #000000;background-color: #ffdddd">-
- <p>It is <em>strongly</em> advised that
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>It is <em>strongly</em> advised that
</span> you should always append the results of <code>(call-next-method)</code>
to the results of your method,
or “interesting” failures will likely occur,
<span style="color: #000000;background-color: #ffdddd">-unless you're a true specialist of ASDF internals.
</span><span style="color: #000000;background-color: #ddffdd">+unless you’re a true specialist of ASDF internals.
</span> It is unhappily too late to compatibly use the <code>append</code> method combination,
<span style="color: #000000;background-color: #ffdddd">-but conceptually that's the protocol that is being manually implemented.
-
- <p>Each entry returned by <code>component-depends-on</code> is itself a list.
-
- <p>The first element of an entry is an operation designator:
</span><span style="color: #000000;background-color: #ddffdd">+but conceptually that’s the protocol that is being manually implemented.
+</p>
+<p>Each entry returned by <code>component-depends-on</code> is itself a list.
+</p>
+<p>The first element of an entry is an operation designator:
</span> either an operation object designating itself, or
a symbol that names an operation class
<span style="color: #000000;background-color: #ffdddd">-(that ASDF will instantiate using <code>make-operation</code>).
</span><span style="color: #000000;background-color: #ddffdd">+(that ASDF will instantiate using <code>make-operation</code>).
</span> For instance, <code>load-op</code>, <code>compile-op</code> and <code>prepare-op</code>
are common such names, denoting the respective operations.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The rest of each entry is a list of component designators:
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="index-coerce_002dname"></a>
+<a name="index-find_002dcomponent"></a>
+<p>The rest of each entry is a list of component designators:
</span> either a component object designating itself,
<span style="color: #000000;background-color: #ffdddd">-or an identifier to be used with <code>find-component</code>.
-<code>find-component</code> will be called with the current component's parent as parent,
-and the identifier as second argument.
</span><span style="color: #000000;background-color: #ddffdd">+or an identifier to be used with <code>find-component</code>.
+<code>find-component</code> will be called with the current component’s parent as parent,
+and the identifier as second argument.
</span> The identifier is typically a string,
a symbol (to be downcased as per <code>coerce-name</code>),
<span style="color: #000000;background-color: #ffdddd">-or a list of strings or symbols.
</span><span style="color: #000000;background-color: #ddffdd">+or a list of strings or symbols.
</span> In particular, the empty list <code>nil</code> denotes the parent itself.
<span style="color: #000000;background-color: #ddffdd">+</p>
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- </ul>
</span><span style="color: #000000;background-color: #ddffdd">+<p>An operation <em>may</em> provide methods for the following generic functions:
+</p>
+<ul>
+<li> <code>input-files</code>
+<a name="index-input_002dfiles"></a>
+A method for this function is often not needed,
+since ASDF has a pretty clever default <code>input-files</code> mechanism.
+You only need create a method if there are multiple ultimate input
+files.
+Most operations inherit from <code>selfward-operation</code>, which
+appropriately sets the input-files to include the source file itself.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>An operation <em>may</em> provide methods for the following generic functions:
</span>
<span style="color: #000000;background-color: #ffdddd">- <ul>
-<li><code>input-files</code>
-A method for this function is often not needed,
-since ASDF has a pretty clever default <code>input-files</code> mechanism.
-You only need create a method if there are multiple ultimate input files,
-and/or the bottom one doesn't depend
-on the <code>component-pathname</code> of the component.
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-input_002dfiles-1"></a>Function: <strong>input-files</strong> <em>operation component</em></dt>
+<dd><p>Return a list of pathnames that represent the input to <var>operation</var>
+performed on <var>component</var>.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- <li><code>operation-done-p</code>
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> <code>operation-done-p</code>
+<a name="index-operation_002ddone_002dp"></a>
</span> You only need to define a method on that function
if you can detect conditions that invalidate previous runs of the operation,
even though no filesystem timestamp has changed,
in which case you return <code>nil</code> (the default is <code>t</code>).
<span style="color: #000000;background-color: #ffdddd">- <p>For instance, the method for <code>test-op</code> always returns <code>nil</code>,
-so that tests are always run afresh.
</span><span style="color: #000000;background-color: #ddffdd">+<p>For instance, the method for <code>test-op</code> always returns <code>nil</code>,
+so that tests are always run afresh.
</span> Of course, the <code>test-op</code> for your system could depend
on a deterministically repeatable <code>test-report-op</code>,
and just read the results from the report files,
in which case you could have this method return <code>t</code>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- </ul>
-
- <p>Operations that print output should send that output to the standard
</span><span style="color: #000000;background-color: #ddffdd">+<p>Operations that print output should send that output to the standard
</span> CL stream <code>*standard-output*</code>, as the Lisp compiler and loader do.
<span style="color: #000000;background-color: #ffdddd">-
-<p><a name="Components"></a>
-
-<!-- node-name, next, previous, up -->
-<h3 class="section">6.2 Components</h3>
-
-<p><a name="index-component-38"></a><a name="index-system-39"></a><a name="index-system-designator-40"></a><a name="index-component-designator-41"></a><a name="index-g_t_002asystem_002ddefinition_002dsearch_002dfunctions_002a-42"></a>
-A <dfn>component</dfn> represents a source file or
-(recursively) a collection of components.
-A <dfn>system</dfn> is (roughly speaking) a top-level component
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Components"></a>
+<a name="Components-1"></a>
+<h3 class="section">7.2 Components</h3>
+<a name="index-component"></a>
+<a name="index-system"></a>
+<a name="index-system-designator"></a>
+<a name="index-component-designator"></a>
+<a name="index-_002asystem_002ddefinition_002dsearch_002dfunctions_002a"></a>
+
+<p>A <code>component</code> represents an individual source file or a group of source files,
+and the things that get transformed into.
+A <code>system</code> is a component at the top level of the component hierarchy,
</span> that can be found via <code>find-system</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>A <dfn>system designator</dfn> is a system itself,
</span><span style="color: #000000;background-color: #ddffdd">+A <code>source-file</code> is a component representing a single source-file
+and the successive output files into which it is transformed.
+A <code>module</code> is an intermediate component itself grouping several other components,
+themselves source-files or further modules.
+</p>
+<p>A <em>system designator</em> is a system itself,
</span> or a string or symbol that behaves just like any other component name
(including with regard to the case conversion rules for component names).
<span style="color: #000000;background-color: #ffdddd">-
- <p>A <dfn>component designator</dfn>, relative to a base component,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>A <em>component designator</em>, relative to a base component,
</span> is either a component itself,
or a string or symbol,
or a list of designators.
<span style="color: #000000;background-color: #ffdddd">-
-<div class="defun">
-— Function: <b>find-system</b><var> system-designator &optional </var>(<var>error-p t</var>)<var><a name="index-find_002dsystem-43"></a></var><br>
-<blockquote>
- <p>Given a system designator, <code>find-system</code> finds and returns a system.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<dl>
+<dt><a name="index-find_002dsystem"></a>Function: <strong>find-system</strong> <em>system-designator &optional (error-p t)</em></dt>
+<dd>
+<p>Given a system designator, <code>find-system</code> finds and returns a system.
</span> If no system is found, an error of type
<code>missing-component</code> is thrown,
or <code>nil</code> is returned if <code>error-p</code> is false.
<span style="color: #000000;background-color: #ffdddd">-
- <p>To find and update systems, <code>find-system</code> funcalls each element
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>To find and update systems, <code>find-system</code> funcalls each element
</span> in the <code>*system-definition-search-functions*</code> list,
expecting a pathname to be returned, or a system object,
<span style="color: #000000;background-color: #ffdddd">-from which a pathname may be extracted, and that will be registered.
</span><span style="color: #000000;background-color: #ddffdd">+from which a pathname may be extracted, and that will be registered.
</span> The resulting pathname (if any) is loaded
if one of the following conditions is true:
<span style="color: #000000;background-color: #ffdddd">-
- <ul>
-<li>there is no system of that name in memory
-<li>the pathname is different from that which was previously loaded
-<li>the file's <code>last-modified</code> time exceeds the <code>last-modified</code> time
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<ul>
+<li> there is no system of that name in memory
+</li><li> the pathname is different from that which was previously loaded
+</li><li> the file’s <code>last-modified</code> time exceeds the <code>last-modified</code> time
</span> of the system in memory
<span style="color: #000000;background-color: #ffdddd">-</ul>
-
- <p>When system definitions are loaded from <samp><span class="file">.asd</span></samp> files,
-a new scratch 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 <code>defpackage</code> and <code>in-package</code> forms
-in his system definition files, however,
-so that they can be loaded manually if need be.
</span><span style="color: #000000;background-color: #ddffdd">+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The default value of <code>*system-definition-search-functions*</code>
-is a list of two functions.
</span><span style="color: #000000;background-color: #ddffdd">+<a name="index-ASDF_002dUSER-package"></a>
+<p>When system definitions are loaded from <samp>.asd</samp> files,
+they are implicitly loaded into the <code>ASDF-USER</code> package,
+which uses <code>ASDF</code>, <code>UIOP</code> and <code>UIOP/COMMON-LISP</code><a name="DOCF12" href="#FOOT12"><sup>12</sup></a>
+Programmers who do anything non-trivial in a <samp>.asd</samp> file,
+such as defining new variables, functions or classes,
+should include <code>defpackage</code> and <code>in-package</code> forms in this file,
+so they will not overwrite each others’ extensions.
+Such forms might also help the files behave identically
+if loaded manually with <code>cl:load</code> for development or debugging,
+though we recommend you use the function <code>asdf::load-asd</code> instead,
+which the <code>slime-asdf</code> contrib knows about.
+</p>
+<p>The default value of <code>*system-definition-search-functions*</code>
+is a list of three functions.
</span> The first function looks in each of the directories given
by evaluating members of <code>*central-registry*</code>
<span style="color: #000000;background-color: #ffdddd">-for a file whose name is the name of the system and whose type is <samp><span class="file">asd</span></samp>.
-The first such file is returned,
-whether or not it turns out to actually define the appropriate system.
</span><span style="color: #000000;background-color: #ddffdd">+for a file whose name is the name of the system and whose type is <samp>asd</samp>;
+the first such file is returned,
+whether or not it turns out to actually define the appropriate system.
</span> The second function does something similar,
<span style="color: #000000;background-color: #ffdddd">-for the directories specified in the <code>source-registry</code>.
-Hence, it is strongly advised to define a system
-<var>foo</var> in the corresponding file <var>foo.asd</var>.
-</p></blockquote></div>
-
-<div class="defun">
-— Function: <b>find-component</b><var> base path<a name="index-find_002dcomponent-44"></a></var><br>
-<blockquote>
- <p>Given a <var>base</var> component (or designator for such),
</span><span style="color: #000000;background-color: #ddffdd">+for the directories specified in the <code>source-registry</code>,
+but searches the filesystem only once and caches its results.
+The third function makes the <code>package-inferred-system</code> extension work,
+see <a href="#The-package_002dinferred_002dsystem-extension">The package-inferred-system extension</a>.
+</p>
+<p>Because of the way these search functions are defined,
+you should put the definition for a system
+<var>foo</var> in a file named <samp>foo.asd</samp>,
+in a directory that is
+in the central registry or
+which can be found using the
+source registry configuration.
+</p>
+<a name="System-names"></a><a name="index-System-names"></a>
+<a name="index-Primary-system-name"></a>
+<a name="index-primary_002dsystem_002dname"></a>
+<p>It is often useful to define multiple systems in a same file,
+but ASDF can only locate a system’s definition file based on the system
+name.
+For this reason,
+ASDF 3’s system search algorithm has been extended to
+allow a file <samp>foo.asd</samp> to contain
+secondary systems named <var>foo/bar</var>, <var>foo/baz</var>, <var>foo/quux</var>, etc.,
+in addition to the primary system named <var>foo</var>.
+The first component of a system name,
+separated by the slash character, <code>/</code>,
+is called the primary name of a system.
+The primary name may be
+extracted by function <code>asdf::primary-system-name</code>;
+when ASDF 3 is told to find a system whose name has a slash,
+it will first attempt to load the corresponding primary system,
+and will thus see any such definitions, and/or any
+definition of a <code>package-inferred-system</code>.<a name="DOCF13" href="#FOOT13"><sup>13</sup></a>
+If your file <samp>foo.asd</samp> also defines systems
+that do not follow this convention, e.g., a system named <var>foo-test</var>,
+ASDF will not be able to automatically locate a definition for these systems,
+and will only see their definition
+if you explicitly find or load the primary system
+using e.g. <code>(asdf:find-system "foo")</code> before you try to use them.
+We strongly recommend against this practice,
+though it is currently supported for backward compatibility.
+</p>
+</dd></dl>
+
+<dl>
+<dt><a name="index-primary_002dsystem_002dname-1"></a>Function: <strong>primary-system-name</strong> <em>name</em></dt>
+<dd>
+<p>Internal (not exported) function, <code>asdf::primary-system-name</code>.
+Returns the primary system name (the portion before
+the slash, <code>/</code>, in a secondary system name) from <var>name</var>.
+</p>
+</dd></dl>
+
+<dl>
+<dt><a name="index-locate_002dsystem"></a>Function: <strong>locate-system</strong> <em>name</em></dt>
+<dd>
+<p>This function should typically <em>not</em> be invoked directly. It is
+exported as part of the API only for programmers who wish to provide
+their own <code>*system-definition-search-functions*</code>.
+</p>
+<p>Given a system <var>name</var> designator,
+try to locate where to load the system definition from.
+Returns five values: <var>foundp</var>, <var>found-system</var>, <var>pathname</var>,
+<var>previous</var>, and <var>previous-time</var>.
+<var>foundp</var> is true when a system was found,
+either a new as yet unregistered one, or a previously registered one.
+The <var>found-system</var> return value
+will be a <code>system</code> object, if a system definition is found in your
+source registry.
+The system definition will <em>not</em> be
+loaded if it hasn’t been loaded already.
+<var>pathname</var> when not null is a path from which to load the system,
+either associated with <var>found-system</var>, or with the <var>previous</var> system.
+If <var>previous</var> is not null, it will be a <em>previously loaded</em>
+<code>system</code> object of the same name (note that the system
+<em>definition</em> is previously-loaded: the system itself may or may not be).
+<var>previous-time</var> when not null is
+the timestamp of the previous system definition file, at the
+time when the <var>previous</var> system definition was loaded.
+</p>
+<p>For example, if your current registry has <samp>foo.asd</samp> in
+<samp>/current/path/to/foo.asd</samp>,
+but system <code>foo</code> was previously loaded from <samp>/previous/path/to/foo.asd</samp>
+then <var>locate-system</var> will return the following values:
+</p><ol>
+<li> <var>foundp</var> will be <code>T</code>,
+</li><li> <var>found-system</var> will be <code>NIL</code>,
+</li><li> <var>pathname</var> will be <code>#p"/current/path/to/foo.asd"</code>,
+</li><li> <var>previous</var> will be an object of type <code>SYSTEM</code> with
+<code>system-source-file</code> slot value of
+<code>#p"/previous/path/to/foo.asd"</code>
+</li><li> <var>previous-time</var> will be the timestamp of
+<code>#p"/previous/path/to/foo.asd"</code> at the time it was loaded.
+</li></ol>
+</dd></dl>
+
+<dl>
+<dt><a name="index-find_002dcomponent-1"></a>Function: <strong>find-component</strong> <em>base path</em></dt>
+<dd>
+<p>Given a <var>base</var> component (or designator for such),
</span> and a <var>path</var>, find the component designated by the <var>path</var>
starting from the <var>base</var>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>If <var>path</var> is a component object, it designates itself,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If <var>path</var> is a component object, it designates itself,
</span> independently from the base.
<span style="color: #000000;background-color: #ffdddd">-
- <p>If <var>path</var> is a string, or symbol denoting a string via <code>coerce-name</code>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="index-coerce_002dname-1"></a>
+<p>If <var>path</var> is a string, or symbol denoting a string via <code>coerce-name</code>,
</span> then <var>base</var> is resolved to a component object,
which must be a system or module,
and the designated component is the child named by the <var>path</var>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>If <var>path</var> is a <code>cons</code> cell,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If <var>path</var> is a <code>cons</code> cell,
</span> <code>find-component</code> with the base and the <code>car</code> of the <var>path</var>,
and the resulting object is used as the base for a tail call
<span style="color: #000000;background-color: #ffdddd">-to <code>find-component</code> with the <code>car</code> of the <var>path</var>.
-
- <p>If <var>base</var> is a component object, it designates itself.
-
- <p>If <var>base</var> is null, then <var>path</var> is used as the base, with <code>nil</code> as the path.
-
- <p>If <var>base</var> is a string, or symbol denoting a string via <code>coerce-name</code>,
</span><span style="color: #000000;background-color: #ddffdd">+to <code>find-component</code> with the <code>car</code> of the <var>path</var>.
+</p>
+<p>If <var>base</var> is a component object, it designates itself.
+</p>
+<p>If <var>base</var> is null, then <var>path</var> is used as the base, with <code>nil</code> as the path.
+</p>
+<p>If <var>base</var> is a string, or symbol denoting a string via <code>coerce-name</code>,
</span> it designates a system as per <code>find-system</code>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If <var>base</var> is a <code>cons</code> cell, it designates the component found by
+<code>find-component</code> with its <code>car</code> as base and <code>cdr</code> as path.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If <var>base</var> is a <code>cons</code> cell, it designates the component found by
-<code>find-component</code> with its <code>car</code> as base and <code>cdr</code> as path.
-</p></blockquote></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Common-attributes-of-components"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h4 class="subsection">6.2.1 Common attributes of components</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Common-attributes-of-components"></a>
+<a name="Common-attributes-of-components-1"></a>
+<h4 class="subsection">7.2.1 Common attributes of components</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>All components, regardless of type, have the following attributes.
</span><span style="color: #000000;background-color: #ddffdd">+<p>All components, regardless of type, have the following attributes.
</span> All attributes except <code>name</code> are optional.
<span style="color: #000000;background-color: #ffdddd">-
-<h5 class="subsubsection">6.2.1.1 Name</h5>
-
-<p>A component name is a string or a symbol.
-If a symbol, its name is taken and lowercased.
-
- <p>Unless overridden by a <code>:pathname</code> attribute,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="Name"></a>
+<h4 class="subsubsection">7.2.1.1 Name</h4>
+<a name="index-coerce_002dname-2"></a>
+<p>A component name is a string or a symbol.
+If a symbol, its name is taken and lowercased. This translation is
+performed by the exported function <code>coerce-name</code>.
+</p>
+<p>Unless overridden by a <code>:pathname</code> attribute,
</span> the name will be interpreted as a pathname specifier according
<span style="color: #000000;background-color: #ffdddd">-to a Unix-style syntax.
</span><span style="color: #000000;background-color: #ddffdd">+to a Unix-style syntax.
</span> See <a href="#The-defsystem-grammar">Pathname specifiers</a>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="Version-identifier"></a>
+<h4 class="subsubsection">7.2.1.2 Version identifier</h4>
+<a name="index-version_002dsatisfies"></a>
+<a name="index-_003aversion-2"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h5 class="subsubsection">6.2.1.2 Version identifier</h5>
-
-<p><a name="index-version_002dsatisfies-45"></a><a name="index-g_t_003aversion-46"></a>
-This optional attribute specifies a version for the current component.
</span><span style="color: #000000;background-color: #ddffdd">+<p>This optional attribute specifies a version for the current component.
</span> The version should typically be a string of integers separated by dots,
<span style="color: #000000;background-color: #ffdddd">-for example ‘<samp><span class="samp">1.0.11</span></samp>’.
</span><span style="color: #000000;background-color: #ddffdd">+for example ‘<samp>1.0.11</samp>’.
</span> For more information on version specifiers, see <a href="#The-defsystem-grammar">The defsystem grammar</a>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>A version may then be queried by the generic function <code>version-satisfies</code>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>A version may then be queried by the generic function <code>version-satisfies</code>,
</span> to see if <code>:version</code> dependencies are satisfied,
and when specifying dependencies, a constraint of minimal version to satisfy
<span style="color: #000000;background-color: #ffdddd">-can be specified using e.g. <code>(:version "mydepname" "1.0.11")</code>.
-
- <p>Note that in the wild, we typically see version numbering
-only on components of type <code>system</code>.
</span><span style="color: #000000;background-color: #ddffdd">+can be specified using e.g. <code>(:version "mydepname" "1.0.11")</code>.
+</p>
+<p>Note that in the wild, we typically see version numbering
+only on components of type <code>system</code>.
</span> Presumably it is much less useful within a given system,
wherein the library author is responsible to keep the various files in synch.
<span style="color: #000000;background-color: #ffdddd">-
-<h5 class="subsubsection">6.2.1.3 Required features</h5>
-
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="Required-features"></a>
+<h4 class="subsubsection">7.2.1.3 Required features</h4>
+<a name="required_002dfeatures"></a>
</span> <p>Traditionally defsystem users have used <code>#+</code> reader conditionals
<span style="color: #000000;background-color: #ffdddd">-to include or exclude specific per-implementation files.
-This means that any single implementation cannot read the entire system,
-which becomes a problem if it doesn't wish to compile it,
-but instead for example to create an archive file containing all the sources,
-as it will omit to process the system-dependent sources for other systems.
-
- <p>Each component in an asdf system may therefore specify using <code>:if-feature</code>
-a feature expression using the same syntax as <code>#+</code> does,
-such that any reference to the component will be ignored
-during compilation, loading and/or linking if the expression evaluates to false.
</span><span style="color: #000000;background-color: #ddffdd">+to include or exclude specific per-implementation files.
+For example, CFFI, the portable C foreign function interface contained
+lines like:
+</p><div class="lisp">
+<pre class="lisp"> #+sbcl (:file "cffi-sbcl")
+</pre></div>
+<p>An unfortunate side effect of this approach is that no single
+implementation can read the entire system.
+This causes problems if, for example, one wished to design an <code>archive-op</code>
+that would create an archive file containing all the sources, since
+for example the file <code>cffi-sbcl.lisp</code> above would be invisible when
+running the <code>archive-op</code> on any implementation other than SBCL.
+</p>
+<p>Starting with ASDF 3,
+components may therefore have an <code>:if-feature</code> option.
+The value of this option should be
+a feature expression using the same syntax as <code>#+</code> does.
+If that feature expression evaluates to false, any reference to the component will be ignored
+during compilation, loading and/or linking.
</span> Since the expression is read by the normal reader,
you must explicitly prefix your symbols with <code>:</code> so they be read as keywords;
this is as contrasted with the <code>#+</code> syntax
that implicitly reads symbols in the keyword package by default.
<span style="color: #000000;background-color: #ffdddd">-
- <p>For instance, <code>:if-feature (:and :x86 (:or :sbcl :cmu :scl))</code> specifies that
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>For instance, <code>:if-feature (:and :x86 (:or :sbcl :cmu :scl))</code> specifies that
</span> the given component is only to be compiled and loaded
<span style="color: #000000;background-color: #ffdddd">-when the implementation is SBCL, CMUCL or Scieneer CL on an x86 machine.
-You can not write it as <code>:if-feature (and x86 (or sbcl cmu scl))</code>
-since the symbols would presumably fail to be read as keywords.
-
-<h5 class="subsubsection">6.2.1.4 Dependencies</h5>
</span><span style="color: #000000;background-color: #ddffdd">+when the implementation is SBCL, CMUCL or Scieneer CL on an x86 machine.
+You cannot write it as <code>:if-feature (and x86 (or sbcl cmu scl))</code>
+since the symbols would not be read as keywords.
+</p>
+<p>See <a href="#if_002dfeature_002doption">if-feature-option</a>.
+</p>
+<a name="Dependencies-1"></a>
+<h4 class="subsubsection">7.2.1.4 Dependencies</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>This attribute specifies dependencies of the component on its siblings.
</span><span style="color: #000000;background-color: #ddffdd">+<p>This attribute specifies dependencies of the component on its siblings.
</span> It is optional but often necessary.
<span style="color: #000000;background-color: #ffdddd">-
- <p>There is an excitingly complicated relationship between the initarg
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>There is an excitingly complicated relationship between the initarg
</span> and the method that you use to ask about dependencies
<span style="color: #000000;background-color: #ffdddd">-
- <p>Dependencies are between (operation component) pairs.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Dependencies are between (operation component) pairs.
</span> In your initargs for the component, you can say
<span style="color: #000000;background-color: #ffdddd">-
-<pre class="lisp"> :in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))
- (load-op (load-op "foo")))
-</pre>
- <p>This means the following things:
- <ul>
-<li>before performing compile-op on this component, we must perform
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">:in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))
+ (load-op (load-op "foo")))
+</pre></div>
+
+<p>This means the following things:
+</p><ul>
+<li> before performing compile-op on this component, we must perform
</span> load-op on <var>a</var> and <var>b</var>, and compile-op on <var>c</var>,
<span style="color: #000000;background-color: #ffdddd">-<li>before performing <code>load-op</code>, we have to load <var>foo</var>
-</ul>
-
- <p>The syntax is approximately
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> before performing <code>load-op</code>, we have to load <var>foo</var>
+</li></ul>
</span>
<span style="color: #000000;background-color: #ddffdd">+<p>The syntax is approximately
+</p>
</span> <pre class="verbatim">(this-op @{(other-op required-components)@}+)
simple-component-name := string
<span style="color: #aaaaaa">@@ -2033,609 +2590,826 @@ required-components := simple-component-name
</span> component-name := simple-component-name
| (:version simple-component-name minimum-version-object)
</pre>
<span style="color: #000000;background-color: #ffdddd">-
- <p>Side note:
-
- <p>This is on a par with what ACL defsystem does.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Side note:
+</p>
+<p>This is on a par with what ACL defsystem does.
</span> mk-defsystem is less general: it has an implied dependency
<span style="color: #000000;background-color: #ffdddd">-
</span><span style="color: #000000;background-color: #ddffdd">+</p>
</span> <pre class="verbatim"> for all source file x, (load x) depends on (compile x)
</pre>
<span style="color: #000000;background-color: #ffdddd">-
- <p>and using a <code>:depends-on</code> argument to say that <var>b</var> depends on
</span><span style="color: #000000;background-color: #ddffdd">+<p>and using a <code>:depends-on</code> argument to say that <var>b</var> depends on
</span> <var>a</var> <em>actually</em> means that
<span style="color: #000000;background-color: #ffdddd">-
</span><span style="color: #000000;background-color: #ddffdd">+</p>
</span> <pre class="verbatim"> (compile b) depends on (load a)
</pre>
<span style="color: #000000;background-color: #ffdddd">-
- <p>This is insufficient for e.g. the McCLIM system, which requires that
</span><span style="color: #000000;background-color: #ddffdd">+<p>This is insufficient for e.g. the McCLIM system, which requires that
</span> all the files are loaded before any of them can be compiled ]
<span style="color: #000000;background-color: #ffdddd">-
- <p>End side note
-
- <p>In ASDF, the dependency information for a given component and operation
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>End side note
+</p>
+<p>In ASDF, the dependency information for a given component and operation
</span> can be queried using <code>(component-depends-on operation component)</code>,
which returns a list
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">((load-op "a") (load-op "b") (compile-op "c") ...)
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> ((load-op "a") (load-op "b") (compile-op "c") ...)
-</pre>
- <p><code>component-depends-on</code> can be subclassed for more specific
</span><span style="color: #000000;background-color: #ddffdd">+<p><code>component-depends-on</code> can be subclassed for more specific
</span> component/operation types: these need to <code>(call-next-method)</code>
and append the answer to their dependency, unless
they have a good reason for completely overriding the default dependencies.
<span style="color: #000000;background-color: #ffdddd">-
- <p>If it weren't for CLISP, we'd be using <code>LIST</code> method
-combination to do this transparently.
-But, we need to support CLISP.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If it weren’t for CLISP, we’d be using <code>LIST</code> method
+combination to do this transparently.
+But, we need to support CLISP.
</span> If you have the time for some CLISP hacking,
<span style="color: #000000;background-color: #ffdddd">-I'm sure they'd welcome your fixes.
-<!-- Doesn't CLISP now support LIST method combination? -->
-
- <p>A minimal version can be specified for a component you depend on
-(typically another system), by specifying <code>(:version "other-system" "1.2.3")</code>
-instead of simply <code>"other-system"</code> as the dependency.
</span><span style="color: #000000;background-color: #ddffdd">+I’m sure they’d welcome your fixes.
+</p>
+<p>A minimal version can be specified for a component you depend on
+(typically another system), by specifying <code>(:version "other-system" "1.2.3")</code>
+instead of simply <code>"other-system"</code> as the dependency.
</span> See the discussion of the semantics of <code>:version</code>
in the defsystem grammar.
<span style="color: #000000;background-color: #ddffdd">+</p>
+
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- FIXME: Should have cross-reference to "Version specifiers" in the -->
-<!-- defsystem grammar, but the cross-referencing is so broken by -->
-<!-- insufficient node breakdown that I have not put one in. -->
-<h5 class="subsubsection">6.2.1.5 pathname</h5>
</span><span style="color: #000000;background-color: #ddffdd">+<a name="pathname"></a>
+<h4 class="subsubsection">7.2.1.5 pathname</h4>
</span>
<p>This attribute is optional and if absent (which is the usual case),
the component name will be used.
<span style="color: #000000;background-color: #ffdddd">-
- <p>See <a href="#The-defsystem-grammar">Pathname specifiers</a>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>See <a href="#The-defsystem-grammar">Pathname specifiers</a>,
</span> for an explanation of how this attribute is interpreted.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Note that the <code>defsystem</code> macro (used to create a “top-level” system)
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that the <code>defsystem</code> macro (used to create a “top-level” system)
</span> does additional processing to set the filesystem location of
<span style="color: #000000;background-color: #ffdddd">-the top component in that system.
</span><span style="color: #000000;background-color: #ddffdd">+the top component in that system.
</span> This is detailed elsewhere. See <a href="#Defining-systems-with-defsystem">Defining systems with defsystem</a>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>To find the CL pathname corresponding to a component, use
+</p>
+<dl>
+<dt><a name="index-component_002dpathname"></a>Function: <strong>component-pathname</strong> <em>component</em></dt>
+<dd><p>Returns the pathname corresponding to <var>component</var>. For components
+such as source files, this will be a filename pathname. For example:
+</p>
+<div class="lisp">
+<pre class="lisp">CL-USER> (asdf:component-pathname (asdf:find-system "xmls"))
+#P"/Users/rpg/lisp/xmls/"
+</pre></div>
+
+<p>and
+</p>
+<div class="lisp">
+<pre class="lisp">CL-USER> (asdf:component-pathname
+ (asdf:find-component
+ (asdf:find-system "xmls") "xmls"))
+#P"/Users/rpg/lisp/xmls/xmls.lisp"
+</pre></div>
+</dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h5 class="subsubsection">6.2.1.6 properties</h5>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>This attribute is optional.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Packaging systems often require information about files or systems
-in addition to that specified by ASDF's pre-defined component attributes.
</span><span style="color: #000000;background-color: #ddffdd">+
+<a name="properties"></a>
+<h4 class="subsubsection">7.2.1.6 properties</h4>
+
+<p>This attribute is optional.
+</p>
+<p>Packaging systems often require information about files or systems
+in addition to that specified by ASDF’s pre-defined component attributes.
</span> Programs that create vendor packages out of ASDF systems therefore
<span style="color: #000000;background-color: #ffdddd">-have to create “placeholder” information to satisfy these systems.
</span><span style="color: #000000;background-color: #ddffdd">+have to create “placeholder” information to satisfy these systems.
</span> Sometimes the creator of an ASDF system may know the additional
information and wish to provide it directly.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>(component-property component property-name)</code> and
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>(component-property component property-name)</code> and
</span> associated <code>setf</code> method will allow
<span style="color: #000000;background-color: #ffdddd">-the programmatic update of this information.
</span><span style="color: #000000;background-color: #ddffdd">+the programmatic update of this information.
</span> Property names are compared as if by <code>EQL</code>,
so use symbols or keywords or something.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Pre-defined-subclasses-of-component"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
</span> <a name="Pre_002ddefined-subclasses-of-component"></a>
<span style="color: #000000;background-color: #ddffdd">+<a name="Pre_002ddefined-subclasses-of-component-1"></a>
+<h4 class="subsection">7.2.2 Pre-defined subclasses of component</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h4 class="subsection">6.2.2 Pre-defined subclasses of component</h4>
-
-<div class="defun">
-— Component: <b>source-file</b><var><a name="index-source_002dfile-47"></a></var><br>
-<blockquote>
- <p>A source file is any file that the system does not know how to
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-source_002dfile"></a>Component: <strong>source-file</strong></dt>
+<dd>
+<p>A source file is any file that the system does not know how to
</span> generate from other components of the system.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Note that this is not necessarily the same thing as
-“a file containing data that is typically fed to a compiler”.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that this is not necessarily the same thing as
+“a file containing data that is typically fed to a compiler”.
</span> If a file is generated by some pre-processor stage
<span style="color: #000000;background-color: #ffdddd">-(e.g. a <samp><span class="file">.h</span></samp> file from <samp><span class="file">.h.in</span></samp> by autoconf)
-then it is not, by this definition, a source file.
</span><span style="color: #000000;background-color: #ddffdd">+(e.g. a <samp>.h</samp> file from <samp>.h.in</samp> by autoconf)
+then it is not, by this definition, a source file.
</span> Conversely, we might have a graphic file
that cannot be automatically regenerated,
or a proprietary shared library that we received as a binary:
these do count as source files for our purposes.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Subclasses of source-file exist for various languages.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Subclasses of source-file exist for various languages.
</span> <em>FIXME: describe these.</em>
<span style="color: #000000;background-color: #ffdddd">-</p></blockquote></div>
-
-<div class="defun">
-— Component: <b>module</b><var><a name="index-module-48"></a></var><br>
-<blockquote>
- <p>A module is a collection of sub-components.
</span><span style="color: #000000;background-color: #ddffdd">+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>A module component has the following extra initargs:
-
- <ul>
-<li><code>:components</code> the components contained in this module
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-module"></a>Component: <strong>module</strong></dt>
+<dd>
+<p>A module is a collection of sub-components.
+</p>
+<p>A module component has the following extra initargs:
+</p>
+<ul>
+<li> <code>:components</code> the components contained in this module
</span>
<span style="color: #000000;background-color: #ffdddd">- <li><code>:default-component-class</code>
-All children components which don't specify their class explicitly
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> <code>:default-component-class</code>
+All children components which don’t specify their class explicitly
</span> are inferred to be of this type.
<span style="color: #000000;background-color: #ffdddd">- <li><code>:if-component-dep-fails</code>
-This attribute was removed in ASDF 3. Do not use it.
-Use <code>:if-feature</code> instead.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> <code>:if-component-dep-fails</code>
+This attribute was removed in ASDF 3. Do not use it.
+Use <code>:if-feature</code> instead (see <a href="#required_002dfeatures">required-features</a>, and see <a href="#if_002dfeature_002doption">if-feature-option</a>).
</span>
<span style="color: #000000;background-color: #ffdddd">- <li><code>:serial</code> When this attribute is set,
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> <code>:serial</code> When this attribute is set,
</span> each subcomponent of this component is assumed to depend on all subcomponents
<span style="color: #000000;background-color: #ffdddd">-before it in the list given to <code>:components</code>, i.e.
</span><span style="color: #000000;background-color: #ddffdd">+before it in the list given to <code>:components</code>, i.e.
</span> all of them are loaded before a compile or load operation is performed on it.
<span style="color: #000000;background-color: #ffdddd">- </ul>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The default operation knows how to traverse a module, so
</span><span style="color: #000000;background-color: #ddffdd">+<p>The default operation knows how to traverse a module, so
</span> most operations will not need to provide methods specialised on modules.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>module</code> may be subclassed to represent components such as
-foreign-language linked libraries or archive files.
-</p></blockquote></div>
-
-<div class="defun">
-— Component: <b>system</b><var><a name="index-system-49"></a></var><br>
-<blockquote>
- <p><code>system</code> is a subclass of <code>module</code>.
-
- <p>A system is a module with a few extra attributes for documentation
-purposes; these are given elsewhere.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>module</code> may be subclassed to represent components such as
+foreign-language linked libraries or archive files.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-system-1"></a>Component: <strong>system</strong></dt>
+<dd>
+<p><code>system</code> is a subclass of <code>module</code>.
+</p>
+<p>A system is a module with a few extra attributes for documentation
+purposes; these are given elsewhere.
</span> See <a href="#The-defsystem-grammar">The defsystem grammar</a>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Users can create new classes for their systems:
+the default <code>defsystem</code> macro takes a <code>:class</code> keyword argument.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Users can create new classes for their systems:
-the default <code>defsystem</code> macro takes a <code>:class</code> keyword argument.
-</p></blockquote></div>
-
-<p><a name="Creating-new-component-types"></a>
-
-<!-- node-name, next, previous, up -->
-<h4 class="subsection">6.2.3 Creating new component types</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Creating-new-component-types"></a>
+<a name="Creating-new-component-types-1"></a>
+<h4 class="subsection">7.2.3 Creating new component types</h4>
</span>
<p>New component types are defined by subclassing one of the existing
component classes and specializing methods on the new component class.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><em>FIXME: this should perhaps be explained more throughly,
-not only by example ...</em>
-
- <p>As an example, suppose we have some implementation-dependent
</span><span style="color: #000000;background-color: #ddffdd">+<p>As an example, suppose we have some implementation-dependent
</span> functionality that we want to isolate
<span style="color: #000000;background-color: #ffdddd">-in one subdirectory per Lisp implementation our system supports.
</span><span style="color: #000000;background-color: #ddffdd">+in one subdirectory per Lisp implementation our system supports.
</span> We create a subclass of
<code>cl-source-file</code>:
<span style="color: #000000;background-color: #ffdddd">-
-<pre class="lisp"> (defclass unportable-cl-source-file (cl-source-file)
- ())
-</pre>
- <p>Function <code>asdf:implementation-type</code> (exported since 2.014.14)
-gives us the name of the subdirectory.
-All that's left is to define how to calculate the pathname
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">(defclass unportable-cl-source-file (cl-source-file)
+ ())
+</pre></div>
+
+<p>Function <code>asdf:implementation-type</code> (exported since 2.014.14)
+gives us the name of the subdirectory.
+All that’s left is to define how to calculate the pathname
</span> of an <code>unportable-cl-source-file</code>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">(defmethod component-pathname ((component unportable-cl-source-file))
+ (merge-pathnames*
+ (parse-unix-namestring (format nil "~(~A~)/" (asdf:implementation-type)))
+ (call-next-method)))
+</pre></div>
+
+<p>The new component type is used in a <code>defsystem</code> form in this way:
+</p>
+<div class="lisp">
+<pre class="lisp">(defsystem :foo
+ :components
+ ((:file "packages")
+ ...
+ (:unportable-cl-source-file "threads"
+ :depends-on ("packages" ...))
+ ...
+ )
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (defmethod component-pathname ((component unportable-cl-source-file))
- (merge-pathnames*
- (parse-unix-namestring (format nil "~(~A~)/" (asdf:implementation-type)))
- (call-next-method)))
-</pre>
- <p>The new component type is used in a <code>defsystem</code> form in this way:
-
-<pre class="lisp"> (defsystem :foo
- :components
- ((:file "packages")
- ...
- (:unportable-cl-source-file "threads"
- :depends-on ("packages" ...))
- ...
- )
-</pre>
- <p><a name="Functions"></a>
-
-<!-- node-name, next, previous, up -->
-<h3 class="section">6.3 Functions</h3>
-
-<p><a name="index-version_002dsatisfies-50"></a>
-
-<div class="defun">
-— version-satisfies: <var>version</var><var> version-spec<a name="index-g_t_0040var_007bversion_007d-51"></a></var><br>
-<blockquote><p>Does <var>version</var> satisfy the <var>version-spec</var>. A generic function.
-ASDF provides built-in methods for <var>version</var> being a <code>component</code> or <code>string</code>.
-<var>version-spec</var> should be a string.
-If it's a component, its version is extracted as a string before further processing.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Dependencies"></a>
+<a name="Dependencies-2"></a>
+<h3 class="section">7.3 Dependencies</h3>
+
+<p>To be successfully build-able, this graph of actions must be acyclic.
+If, as a user, extender or implementer of ASDF, you introduce
+a cycle into the dependency graph,
+ASDF will fail loudly.
+To clearly distinguish the direction of dependencies,
+ASDF 3 uses the words <em>requiring</em> and <em>required</em>
+as applied to an action depending on the other:
+the requiring action <code>depends-on</code> the completion of all required actions
+before it may itself be <code>perform</code>ed.
+</p>
+<p>Using the <code>defsystem</code> syntax, users may easily express
+direct dependencies along the graph of the object hierarchy:
+between a component and its parent, its children, and its siblings.
+By defining custom CLOS methods, you can express more elaborate dependencies as you wish.
+Most common operations, such as <code>load-op</code>, <code>compile-op</code> or <code>load-source-op</code>
+are automatically propagate “downward” the component hierarchy and are “covariant” with it:
+to act the operation on the parent module, you must first act it on all the children components,
+with the action on the parent being parent of the action on each child.
+Other operations, such as <code>prepare-op</code> and <code>prepare-source-op</code>
+(introduced in ASDF 3) are automatically propagated “upward” the component hierarchy
+and are “contravariant” with it:
+to perform the operation of preparing for compilation of a child component,
+you must perform the operation of preparing for compilation of its parent component, and so on,
+ensuring that all the parent’s dependencies are (compiled and) loaded
+before the child component may be compiled and loaded.
+Yet other operations, such as <code>test-op</code> or <code>load-bundle-op</code>
+remain at the system level, and are not propagated along the hierarchy,
+but instead do something global on the system.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>A version string satisfies the version-spec if after parsing,
-the former is no older than the latter.
-Therefore <code>"1.9.1"</code>, <code>"1.9.2"</code> and <code>"1.10"</code> all satisfy <code>"1.9.1"</code>,
-but <code>"1.8.4"</code> or <code>"1.9"</code> do not.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Functions"></a>
+<a name="Functions-1"></a>
+<h3 class="section">7.4 Functions</h3>
+
+<dl>
+<dt><a name="index-version_002dsatisfies-1"></a>Function: <strong>version-satisfies</strong> <em><var>version</var> <var>version-spec</var></em></dt>
+<dd><p>Does <var>version</var> satisfy the <var>version-spec</var>. A generic function.
+ASDF provides built-in methods for <var>version</var> being a <code>component</code> or <code>string</code>.
+<var>version-spec</var> should be a string.
+If it’s a component, its version is extracted as a string before further processing.
+</p>
+<p>A version string satisfies the version-spec if after parsing,
+the former is no older than the latter.
+Therefore <code>"1.9.1"</code>, <code>"1.9.2"</code> and <code>"1.10"</code> all satisfy <code>"1.9.1"</code>,
+but <code>"1.8.4"</code> or <code>"1.9"</code> do not.
</span> For more information about how <code>version-satisfies</code> parses and interprets
version strings and specifications,
see <a href="#The-defsystem-grammar">The defsystem grammar</a> (version specifiers) and
<a href="#Common-attributes-of-components">Common attributes of components</a>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Note that in versions of ASDF prior to 3.0.1,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that in versions of ASDF prior to 3.0.1,
</span> including the entire ASDF 1 and ASDF 2 series,
<code>version-satisfies</code> would also require that the version and the version-spec
have the same major version number (the first integer in the list);
<span style="color: #000000;background-color: #ffdddd">-if the major version differed, the version would be considered as not matching the spec.
</span><span style="color: #000000;background-color: #ddffdd">+if the major version differed, the version would be considered as not matching the spec.
</span> But that feature was not documented, therefore presumably not relied upon,
<span style="color: #000000;background-color: #ffdddd">-whereas it was a nuisance to several users.
</span><span style="color: #000000;background-color: #ddffdd">+whereas it was a nuisance to several users.
</span> Starting with ASDF 3.0.1,
<code>version-satisfies</code> does not treat the major version number specially,
<span style="color: #000000;background-color: #ffdddd">-and returns T simply if the first argument designates a version that isn't older
-than the one specified as a second argument.
</span><span style="color: #000000;background-color: #ddffdd">+and returns T simply if the first argument designates a version that isn’t older
+than the one specified as a second argument.
</span> If needs be, the <code>(:version ...)</code> syntax for specifying dependencies
could be in the future extended to specify an exclusive upper bound for compatible versions
<span style="color: #000000;background-color: #ffdddd">-as well as an inclusive lower bound.
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+as well as an inclusive lower bound.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Controlling-where-ASDF-searches-for-systems"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Controlling-where-ASDF-searches-for-systems"></a>
+<a name="Controlling-where-ASDF-searches-for-systems-1"></a>
+<h2 class="chapter">8 Controlling where ASDF searches for systems</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h2 class="chapter">7 Controlling where ASDF searches for systems</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">7.1 Configurations</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Configurations specify paths where to find system files.
</span>
<span style="color: #000000;background-color: #ffdddd">- <ol type=1 start=1>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Configurations"></a>
+<a name="Configurations-1"></a>
+<h3 class="section">8.1 Configurations</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>The search registry may use some hardcoded wrapping registry specification.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Configurations specify paths where to find system files.
+</p>
+<ol>
+<li> The search registry may use some hardcoded wrapping registry specification.
</span> This allows some implementations (notably SBCL) to specify where to find
some special implementation-provided systems that
need to precisely match the version of the implementation itself.
<span style="color: #000000;background-color: #ffdddd">- <li>An application may explicitly initialize the source-registry configuration
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> An application may explicitly initialize the source-registry configuration
</span> using the configuration API
(see <a href="#Controlling-where-ASDF-searches-for-systems">Configuration API</a>, below)
<span style="color: #000000;background-color: #ffdddd">-in which case this takes precedence.
</span><span style="color: #000000;background-color: #ddffdd">+in which case this takes precedence.
</span> It may itself compute this configuration from the command-line,
from a script, from its own configuration file, etc.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> the environment variable <code>CL_SOURCE_REGISTRY</code> if it exists.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> user configuration file
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">$XDG_CONFIG_DIRS/common-lisp/source-registry.conf</span></samp>
</span><span style="color: #000000;background-color: #ddffdd">+<samp>$XDG_CONFIG_DIRS/common-lisp/source-registry.conf</samp>
</span> (which defaults to
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">~/.config/common-lisp/source-registry.conf</span></samp>)
</span><span style="color: #000000;background-color: #ddffdd">+<samp>~/.config/common-lisp/source-registry.conf</samp>)
</span> if it exists.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> user configuration directory
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/</span></samp>
</span><span style="color: #000000;background-color: #ddffdd">+<samp>$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/</samp>
</span> (which defaults to
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">~/.config/common-lisp/source-registry.conf.d/</span></samp>)
</span><span style="color: #000000;background-color: #ddffdd">+<samp>~/.config/common-lisp/source-registry.conf.d/</samp>)
</span> if it exists.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
+default user configuration trees
+<samp>~/common-lisp/</samp> (since ASDF 3.1.2 only),
+<samp>~/.sbcl/systems/</samp> (on SBCL only),
+<samp>$XDG_DATA_HOME/common-lisp/systems/</samp> (no recursion, link farm)
+<samp>$XDG_DATA_HOME/common-lisp/source/</samp>.
+The <code>XDG_DATA_HOME</code> directory defaults to <samp>~/.local/share/</samp>.
+On Windows, the <code>local-appdata</code> and <code>appdata</code> directories are used instead.
+
+</li><li> The source registry will be configured from
</span> system configuration file
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">/etc/common-lisp/source-registry.conf</span></samp>
-if it exists/
</span><span style="color: #000000;background-color: #ddffdd">+<samp>/etc/common-lisp/source-registry.conf</samp>
+if it exists.
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> system configuration directory
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">/etc/common-lisp/source-registry.conf.d/</span></samp>
</span><span style="color: #000000;background-color: #ddffdd">+<samp>/etc/common-lisp/source-registry.conf.d/</samp>
</span> if it exists.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from a default configuration.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from a default configuration.
</span> This configuration may allow for implementation-specific systems
to be found, for systems to be found the current directory
(at the time that the configuration is initialized) as well as
<span style="color: #000000;background-color: #ffdddd">-<code>:directory</code> entries for <samp><span class="file">$XDG_DATA_DIRS/common-lisp/systems/</span></samp> and
-<code>:tree</code> entries for <samp><span class="file">$XDG_DATA_DIRS/common-lisp/source/</span></samp>.
-For instance, SBCL will include directories for its contribs
-when it can find them; it will look for them where SBCL was installed,
-or at the location specified by the <code>SBCL_HOME</code> environment variable.
</span><span style="color: #000000;background-color: #ddffdd">+<code>:directory</code> entries for <samp>$XDG_DATA_DIRS/common-lisp/systems/</samp> and
+<code>:tree</code> entries for <samp>$XDG_DATA_DIRS/common-lisp/source/</samp>,
+where <code>XDG_DATA_DIRS</code> defaults to <samp>/usr/local/share</samp> and <samp>/usr/share</samp> on Unix,
+and the <code>common-appdata</code> directory on Windows.
+
+</li><li> The source registry may include implementation-dependent directories
+that correspond to implementation-provided extensions.
</span>
<span style="color: #000000;background-color: #ffdddd">- </ol>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ol>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Each of these configurations is specified as an s-expression
-in a trivial domain-specific language (defined below).
</span><span style="color: #000000;background-color: #ddffdd">+<p>Each of these configurations is specified as an s-expression
+in a trivial domain-specific language (defined below).
</span> Additionally, a more shell-friendly syntax is available
for the environment variable (defined yet below).
<span style="color: #000000;background-color: #ffdddd">-
- <p>Each of these configurations is only used if the previous
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Each of these configurations is only used if the previous
</span> configuration explicitly or implicitly specifies that it
includes its inherited configuration.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Additionally, some implementation-specific directories
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Additionally, some implementation-specific directories
</span> may be automatically prepended to whatever directories are specified
in configuration files, no matter if the last one inherits or not.
<span style="color: #000000;background-color: #ffdddd">-
-<h3 class="section">7.2 Truenames and other dangers</h3>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Truenames-and-other-dangers"></a>
+<a name="Truenames-and-other-dangers-1"></a>
+<h3 class="section">8.2 Truenames and other dangers</h3>
</span>
<p>One great innovation of the original ASDF was its ability to leverage
<code>CL:TRUENAME</code> to locate where your source code was and where to build it,
allowing for symlink farms as a simple but effective configuration mechanism
<span style="color: #000000;background-color: #ffdddd">-that is easy to control programmatically.
</span><span style="color: #000000;background-color: #ddffdd">+that is easy to control programmatically.
</span> ASDF 3 still supports this configuration style, and it is enabled by default;
however we recommend you instead use
our source-registry configuration mechanism described below,
because it is easier to setup in a portable way across users and implementations.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Addtionally, some people dislike truename,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Additionally, some people dislike truename,
</span> either because it is very slow on their system, or
because they are using content-addressed storage where the truename of a file
is related to a digest of its individual contents,
<span style="color: #000000;background-color: #ffdddd">-and not to other files in the same intended project.
</span><span style="color: #000000;background-color: #ddffdd">+and not to other files in the same intended project.
</span> For these people, ASDF 3 allows to eschew the <code>TRUENAME</code> mechanism,
by setting the variable <var>asdf:*resolve-symlinks*</var> to <code>nil</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>PS: Yes, if you haven't read Vernor Vinge's short but great classic
-“True Names... and Other Dangers” then you're in for a treat.
-
-<h3 class="section">7.3 XDG base directory</h3>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>PS: Yes, if you haven’t read Vernor Vinge’s short but great classic
+“True Names... and Other Dangers” then you’re in for a treat.
+</p>
+<hr>
+<a name="XDG-base-directory"></a>
+<a name="XDG-base-directory-1"></a>
+<h3 class="section">8.3 XDG base directory</h3>
</span>
<p>Note that we purport to respect the XDG base directory specification
as to where configuration files are located,
where data files are located,
<span style="color: #000000;background-color: #ffdddd">-where output file caches are located.
</span><span style="color: #000000;background-color: #ddffdd">+where output file caches are located.
</span> Mentions of XDG variables refer to that document.
<span style="color: #000000;background-color: #ffdddd">-
- <p><a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html</a>
-
- <p>This specification allows the user to specify some environment variables
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html</a>
+</p>
+<p>This specification allows the user to specify some environment variables
</span> to customize how applications behave to his preferences.
<span style="color: #000000;background-color: #ffdddd">-
- <p>On Windows platforms, when not using Cygwin,
-instead of the XDG base directory specification,
-we try to use folder configuration from the registry regarding
-<code>Common AppData</code> and similar directories.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>On Windows platforms, even when not using Cygwin, and starting with ASDF 3.1.5,
+we still do a best effort at following the XDG base directory specification,
+even though it doesn’t exactly fit common practice for Windows applications.
+However, we replace the fixed Unix paths <samp>~/.local</samp>, <samp>/usr/local</samp> and <samp>/usr</samp>
+with their rough Windows equivalent <samp>Local AppData</samp>, <samp>AppData</samp>, <samp>Common AppData</samp>, etc.
</span> Since support for querying the Windows registry
is not possible to do in reasonable amounts of portable Common Lisp code,
<span style="color: #000000;background-color: #ffdddd">-ASDF 3 relies on the environment variables that Windows usually exports.
-
-<h3 class="section">7.4 Backward Compatibility</h3>
</span><span style="color: #000000;background-color: #ddffdd">+ASDF 3 relies on the environment variables that Windows usually exports,
+and are hopefully in synch with the Windows registry.
+If you care about the details, see <samp>uiop/configuration.lisp</samp> and don’t hesitate to suggest improvements.
+</p>
+<hr>
+<a name="Backward-Compatibility"></a>
+<a name="Backward-Compatibility-1"></a>
+<h3 class="section">8.4 Backward Compatibility</h3>
</span>
<p>For backward compatibility as well as to provide a practical backdoor for hackers,
<span style="color: #000000;background-color: #ffdddd">-ASDF will first search for <code>.asd</code> files in the directories specified in
</span><span style="color: #000000;background-color: #ddffdd">+ASDF will first search for <samp>.asd</samp> files in the directories specified in
</span> <code>asdf:*central-registry*</code>
before it searches in the source registry above.
<span style="color: #000000;background-color: #ffdddd">-
- <p>See <a href="#Configuring-ASDF">Configuring ASDF to find your systems — old style</a>.
-
- <p>By default, <code>asdf:*central-registry*</code> will be empty.
-
- <p>This old mechanism will therefore not affect you if you don't use it,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>See <a href="#Configuring-ASDF">Configuring ASDF to find your systems — old style</a>.
+</p>
+<p>By default, <code>asdf:*central-registry*</code> will be empty.
+</p>
+<p>This old mechanism will therefore not affect you if you don’t use it,
</span> but will take precedence over the new mechanism if you do use it.
<span style="color: #000000;background-color: #ffdddd">-
-<h3 class="section">7.5 Configuration DSL</h3>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Configuration-DSL"></a>
+<a name="Configuration-DSL-1"></a>
+<h3 class="section">8.5 Configuration DSL</h3>
+<a name="index-_003ainherit_002dconfiguration-source-config-directive"></a>
+<a name="index-inherit_002dconfiguration-source-config-directive"></a>
+<a name="index-_003aignore_002dinvalid_002dentries-source-config-directive"></a>
+<a name="index-ignore_002dinvalid_002dentries-source-config-directive"></a>
+<a name="index-_003adirectory-source-config-directive"></a>
+<a name="index-directory-source-config-directive"></a>
+<a name="index-_003atree-source-config-directive"></a>
+<a name="index-tree-source-config-directive"></a>
+<a name="index-_003aexclude-source-config-directive"></a>
+<a name="index-exclude-source-config-directive"></a>
+<a name="index-_003aalso_002dexclude-source-config-directive"></a>
+<a name="index-also_002dexclude-source-config-directive"></a>
+<a name="index-_003ainclude-source-config-directive"></a>
+<a name="index-include-source-config-directive"></a>
+<a name="index-_003adefault_002dregistry-source-config-directive"></a>
+<a name="index-default_002dregistry-source-config-directive"></a>
</span>
<p>Here is the grammar of the s-expression (SEXP) DSL for source-registry
configuration:
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- FIXME: This is too wide for happy compilation into pdf. -->
-<pre class="example"> ;; A configuration is a single SEXP starting with keyword :source-registry
- ;; followed by a list of directives.
- CONFIGURATION := (:source-registry DIRECTIVE ...)
-
- ;; A directive is one of the following:
- DIRECTIVE :=
- ;; INHERITANCE DIRECTIVE:
- ;; Your configuration expression MUST contain
- ;; exactly one of either of these:
- :inherit-configuration | ; splices inherited configuration (often specified last)
- :ignore-inherited-configuration | ; drop inherited configuration (specified anywhere)
-
- ;; forward compatibility directive (since ASDF 2.011.4), useful when
- ;; you want to use new configuration features but have to bootstrap a
- ;; the newer required ASDF from an older release that doesn't sport said features:
- :ignore-invalid-entries | ; drops subsequent invalid entries instead of erroring out
-
- ;; add a single directory to be scanned (no recursion)
- (:directory DIRECTORY-PATHNAME-DESIGNATOR) |
-
- ;; add a directory hierarchy, recursing but excluding specified patterns
- (:tree DIRECTORY-PATHNAME-DESIGNATOR) |
-
- ;; override the defaults for exclusion patterns
- (:exclude EXCLUSION-PATTERN ...) |
- ;; augment the defaults for exclusion patterns
- (:also-exclude EXCLUSION-PATTERN ...) |
- ;; Note that the scope of a an exclude pattern specification is
- ;; the rest of the current configuration expression or file.
-
- ;; splice the parsed contents of another config file
- (:include REGULAR-FILE-PATHNAME-DESIGNATOR) |
-
- ;; This directive specifies that some default must be spliced.
- :default-registry
-
- REGULAR-FILE-PATHNAME-DESIGNATOR := PATHNAME-DESIGNATOR ;; interpreted as a file
- DIRECTORY-PATHNAME-DESIGNATOR := PATHNAME-DESIGNATOR ;; interpreted as a directory name
-
- PATHNAME-DESIGNATOR :=
- NIL | ;; Special: skip this entry.
- ABSOLUTE-COMPONENT-DESIGNATOR ;; see pathname DSL
-
- EXCLUSION-PATTERN := a string without wildcards, that will be matched exactly
- against the name of a any subdirectory in the directory component
- of a path. e.g. <code>"_darcs"</code> will match <samp><span class="file">#p"/foo/bar/_darcs/src/bar.asd"</span></samp>
-</pre>
- <p>Pathnames are designated using another DSL,
-shared with the output-translations configuration DSL below.
</span><span style="color: #000000;background-color: #ddffdd">+<div class="example">
+<pre class="example">;; A configuration is a single SEXP starting with the keyword
+;; :source-registry followed by a list of directives.
+CONFIGURATION := (:source-registry DIRECTIVE ...)
+
+;; A directive is one of the following:
+DIRECTIVE :=
+ ;; INHERITANCE DIRECTIVE:
+ ;; Your configuration expression MUST contain
+ ;; exactly one of the following:
+ :inherit-configuration |
+ ;; splices inherited configuration (often specified last) or
+ :ignore-inherited-configuration |
+ ;; drop inherited configuration (specified anywhere)
+
+ ;; forward compatibility directive (since ASDF 2.011.4), useful when
+ ;; you want to use new configuration features but have to bootstrap
+ ;; the newer required ASDF from an older release that doesn't
+ ;; support said features:
+ :ignore-invalid-entries |
+
+ ;; add a single directory to be scanned (no recursion)
+ (:directory DIRECTORY-PATHNAME-DESIGNATOR) |
+
+ ;; add a directory hierarchy, recursing but
+ ;; excluding specified patterns
+ (:tree DIRECTORY-PATHNAME-DESIGNATOR) |
+
+ ;; override the defaults for exclusion patterns
+ (:exclude EXCLUSION-PATTERN ...) |
+ ;; augment the defaults for exclusion patterns
+ (:also-exclude EXCLUSION-PATTERN ...) |
+ ;; Note that the scope of a an exclude pattern specification is
+ ;; the rest of the current configuration expression or file.
+
+ ;; splice the parsed contents of another config file
+ (:include REGULAR-FILE-PATHNAME-DESIGNATOR) |
+
+ ;; This directive specifies that some default must be spliced.
+ :default-registry
+
+REGULAR-FILE-PATHNAME-DESIGNATOR
+ := PATHNAME-DESIGNATOR ; interpreted as a file
+DIRECTORY-PATHNAME-DESIGNATOR
+ := PATHNAME-DESIGNATOR ; interpreted as a directory
+
+PATHNAME-DESIGNATOR :=
+ NIL | ;; Special: skip this entry.
+ ABSOLUTE-COMPONENT-DESIGNATOR ;; see pathname DSL
+
+EXCLUSION-PATTERN := a string without wildcards, that will be matched
+ exactly against the name of a any subdirectory in the directory
+ component of a path. e.g. <code>"_darcs"</code> will match
+ <samp>#p"/foo/bar/_darcs/src/bar.asd"</samp>
+</pre></div>
+
+<p>Pathnames are designated using another DSL,
+shared with the output-translations configuration DSL below.
</span> The DSL is resolved by the function <code>asdf::resolve-location</code>,
to be documented and exported at some point in the future.
<span style="color: #000000;background-color: #ffdddd">-
-<pre class="example"> ABSOLUTE-COMPONENT-DESIGNATOR :=
- (ABSOLUTE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
- STRING | ;; namestring (better be absolute or bust, directory assumed where applicable).
- ;; In output-translations, directory is assumed and **/*.*.* added if it's last.
- ;; On MCL, a MacOSX-style POSIX namestring (for MacOS9 style, use #p"...");
- ;; Note that none of the above applies to strings used in *central-registry*,
- ;; which doesn't use this DSL: they are processed as normal namestrings.
- ;; however, you can compute what you put in the *central-registry*
- ;; based on the results of say (asdf::resolve-location "/Users/fare/cl/cl-foo/")
- PATHNAME | ;; pathname (better be an absolute path, or bust)
- ;; In output-translations, unless followed by relative components,
- ;; it better have appropriate wildcards, as in **/*.*.*
- :HOME | ;; designates the user-homedir-pathname ~/
- :USER-CACHE | ;; designates the default location for the user cache
- :HERE | ;; designates the location of the configuration file
- ;; (or *default-pathname-defaults*, if invoked interactively)
- :ROOT ;; magic, for output-translations source only: paths that are relative
- ;; to the root of the source host and device
- ;; Not valid anymore: :SYSTEM-CACHE (was a security hazard)
-
- RELATIVE-COMPONENT-DESIGNATOR :=
- (RELATIVE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
- STRING | ;; relative directory pathname as interpreted by parse-unix-namestring.
- ;; In output translations, if last component, **/*.*.* is added
- PATHNAME | ;; pathname; unless last component, directory is assumed.
- :IMPLEMENTATION | ;; directory based on implementation, e.g. sbcl-1.0.45-linux-x64
- :IMPLEMENTATION-TYPE | ;; a directory based on lisp-implementation-type only, e.g. sbcl
- :DEFAULT-DIRECTORY | ;; a relativized version of the default directory
- :*/ | ;; any direct subdirectory (since ASDF 2.011.4)
- :**/ | ;; any recursively inferior subdirectory (since ASDF 2.011.4)
- :*.*.* | ;; any file (since ASDF 2.011.4)
- ;; Not supported (anymore): :UID and :USERNAME
-</pre>
- <p>For instance, as a simple case, my <samp><span class="file">~/.config/common-lisp/source-registry.conf</span></samp>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="example">
+<pre class="example">ABSOLUTE-COMPONENT-DESIGNATOR :=
+ (ABSOLUTE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
+ STRING |
+ ;; namestring (better be absolute or bust, directory assumed where
+ ;; applicable). In output-translations, directory is assumed and
+ ;; **/*.*.* added if it's last. On MCL, a MacOSX-style POSIX
+ ;; namestring (for MacOS9 style, use #p"..."); Note that none of the
+ ;; above applies to strings used in *central-registry*, which
+ ;; doesn't use this DSL: they are processed as normal namestrings.
+ ;; however, you can compute what you put in the *central-registry*
+ ;; based on the results of say
+ ;; (asdf::resolve-location "/Users/fare/cl/cl-foo/")
+ PATHNAME |
+ ;; pathname (better be an absolute path, or bust)
+ ;; In output-translations, unless followed by relative components,
+ ;; it better have appropriate wildcards, as in **/*.*.*
+ :HOME | ; designates the user-homedir-pathname ~/
+ :USER-CACHE | ; designates the default location for the user cache
+ :HERE |
+ ;; designates the location of the configuration file
+ ;; (or *default-pathname-defaults*, if invoked interactively)
+ :ROOT
+ ;; magic, for output-translations source only: paths that are relative
+ ;; to the root of the source host and device
+
+They keyword :SYSTEM-CACHE is not accepted in ASDF 3.1 and beyond: it
+was a security hazard.
+
+RELATIVE-COMPONENT-DESIGNATOR :=
+ (RELATIVE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
+ STRING |
+ ;; relative directory pathname as interpreted by
+ ;; parse-unix-namestring.
+ ;; In output translations, if last component, **/*.*.* is added
+ PATHNAME | ; pathname; unless last component, directory is assumed.
+ :IMPLEMENTATION |
+ ;; directory based on implementation, e.g. sbcl-1.0.45-linux-x64
+ :IMPLEMENTATION-TYPE |
+ ;; a directory based on lisp-implementation-type only, e.g. sbcl
+ :DEFAULT-DIRECTORY |
+ ;; a relativized version of the default directory
+ :*/ | ;; any direct subdirectory (since ASDF 2.011.4)
+ :**/ | ;; any recursively inferior subdirectory (since ASDF 2.011.4)
+ :*.*.* | ;; any file (since ASDF 2.011.4)
+
+The keywords :UID and :USERNAME are no longer supported.
+</pre></div>
+
+<p>For instance, as a simple case, my <samp>~/.config/common-lisp/source-registry.conf</samp>,
</span> which is the default place ASDF looks for this configuration, once contained:
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (:source-registry
- (:tree (:home "cl")) ;; will expand to e.g. "/home/joeluser/cl/"
- :inherit-configuration)
-</pre>
- <h3 class="section">7.6 Configuration Directories</h3>
</span><span style="color: #000000;background-color: #ddffdd">+</p><div class="example">
+<pre class="example">(:source-registry
+ (:tree (:home "cl")) ;; will expand to e.g. "/home/joeluser/cl/"
+ :inherit-configuration)
+</pre></div>
+
+<hr>
+<a name="Configuration-Directories"></a>
+<a name="Configuration-Directories-1"></a>
+<h3 class="section">8.6 Configuration Directories</h3>
</span>
<p>Configuration directories consist in files each containing
<span style="color: #000000;background-color: #ffdddd">-a list of directives without any enclosing <code>(:source-registry ...)</code> form.
</span><span style="color: #000000;background-color: #ddffdd">+a list of directives without any enclosing <code>(:source-registry ...)</code> form.
</span> The files will be sorted by namestring as if by <code>string<</code> and
<span style="color: #000000;background-color: #ffdddd">-the lists of directives of these files with be concatenated in order.
</span><span style="color: #000000;background-color: #ddffdd">+the lists of directives of these files with be concatenated in order.
</span> An implicit <code>:inherit-configuration</code> will be included
at the <em>end</em> of the list.
<span style="color: #000000;background-color: #ffdddd">-
- <p>This allows for packaging software that has file granularity
-(e.g. Debian's <code>dpkg</code> or some future version of <code>clbuild</code>)
-to easily include configuration information about distributed software.
-
- <p>The convention is that, for sorting purposes,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>System-wide or per-user Common Lisp software distributions
+such as Debian packages or some future version of <code>clbuild</code>
+may then include files such as
+<samp>/etc/common-lisp/source-registry.conf.d/10-foo.conf</samp> or
+<samp>~/.config/common-lisp/source-registry.conf.d/10-foo.conf</samp>
+to easily and modularly register configuration information
+about software being distributed.
+</p>
+<p>The convention is that, for sorting purposes,
</span> the names of files in such a directory begin with two digits
<span style="color: #000000;background-color: #ffdddd">-that determine the order in which these entries will be read.
-Also, the type of these files is conventionally <code>"conf"</code>
-and as a limitation to some implementations (e.g. GNU clisp),
-the type cannot be <code>nil</code>.
-
- <p>Directories may be included by specifying a directory pathname
</span><span style="color: #000000;background-color: #ddffdd">+that determine the order in which these entries will be read.
+Also, the type of these files must be <samp>.conf</samp>,
+which not only simplifies the implementation by allowing
+for more portable techniques in finding those files,
+but also makes it trivial to disable a file, by renaming it to a different file type.
+</p>
+<p>Directories may be included by specifying a directory pathname
</span> or namestring in an <code>:include</code> directive, e.g.:
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="example">
+<pre class="example"> (:include "/foo/bar/")
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (:include "/foo/bar/")
-</pre>
- <p>Hence, to achieve the same effect as
-my example <samp><span class="file">~/.config/common-lisp/source-registry.conf</span></samp> above,
</span><span style="color: #000000;background-color: #ddffdd">+<p>Hence, to achieve the same effect as
+my example <samp>~/.config/common-lisp/source-registry.conf</samp> above,
</span> I could simply create a file
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">~/.config/common-lisp/source-registry.conf.d/33-home-fare-cl.conf</span></samp>
</span><span style="color: #000000;background-color: #ddffdd">+<samp>~/.config/common-lisp/source-registry.conf.d/33-home-fare-cl.conf</samp>
</span> alone in its directory with the following contents:
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (:tree "/home/fare/cl/")
-</pre>
- <h4 class="subsection">7.6.1 The :here directive</h4>
</span><span style="color: #000000;background-color: #ddffdd">+</p><div class="example">
+<pre class="example">(:tree "/home/fare/cl/")
+</pre></div>
+
+
+<hr>
+<a name="The-here-directive"></a>
+<a name="The-_003ahere-directive"></a>
+<h4 class="subsection">8.6.1 The :here directive</h4>
</span>
<p>The <code>:here</code> directive is an absolute pathname designator that
refers to the directory containing the configuration file currently
being processed.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The <code>:here</code> directive is intended to simplify the delivery of
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The <code>:here</code> directive is intended to simplify the delivery of
</span> complex CL systems, and for easy configuration of projects shared through
revision control systems, in accordance with our design principle that
each participant should be able to provide all and only the information
available to him or her.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Consider a person X who has set up the source code repository for a
-complex project with a master directory <samp><span class="file">dir/</span></samp>. Ordinarily, one
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Consider a person X who has set up the source code repository for a
+complex project with a master directory <samp>dir/</samp>. Ordinarily, one
</span> might simply have the user add a directive that would look something
like this:
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (:tree "path/to/dir")
-</pre>
- <p>But what if X knows that there are very large subtrees
</span><span style="color: #000000;background-color: #ddffdd">+</p><div class="example">
+<pre class="example"> (:tree "path/to/dir")
+</pre></div>
+<p>But what if X knows that there are very large subtrees
</span> under dir that are filled with, e.g., Java source code, image files for
icons, etc.? All of the asdf system definitions are contained in the
<span style="color: #000000;background-color: #ffdddd">-subdirectories <samp><span class="file">dir/src/lisp/</span></samp> and <samp><span class="file">dir/extlib/lisp/</span></samp>, and
</span><span style="color: #000000;background-color: #ddffdd">+subdirectories <samp>dir/src/lisp/</samp> and <samp>dir/extlib/lisp/</samp>, and
</span> these are the only directories that should be searched.
<span style="color: #000000;background-color: #ffdddd">-
- <p>In this case, X can put into <samp><span class="file">dir/</span></samp> a file <samp><span class="file">asdf.conf</span></samp> that
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>In this case, X can put into <samp>dir/</samp> a file <samp>asdf.conf</samp> that
</span> contains the following:
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (:source-registry
- (:tree (:here "src/lisp/"))
- (:tree (:here "extlib/lisp"))
- (:directory (:here "outlier/")))
-</pre>
- <p>Then when someone else (call her Y) checks out a copy of this
</span><span style="color: #000000;background-color: #ddffdd">+</p><div class="example">
+<pre class="example">(:source-registry
+ (:tree (:here "src/lisp/"))
+ (:tree (:here "extlib/lisp"))
+ (:directory (:here "outlier/")))
+</pre></div>
+
+<p>Then when someone else (call her Y) checks out a copy of this
</span> repository, she need only add
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (:include "/path/to/my/checkout/directory/asdf.conf")
-</pre>
- <p>to one of her previously-existing asdf source location configuration
</span><span style="color: #000000;background-color: #ddffdd">+</p><div class="example">
+<pre class="example">(:include "/path/to/my/checkout/directory/asdf.conf")
+</pre></div>
+<p>to one of her previously-existing asdf source location configuration
</span> files, or invoke <code>initialize-source-registry</code> with a configuration
form containing that s-expression. ASDF will find the .conf file that X
has provided, and then set up source locations within the working
<span style="color: #000000;background-color: #ffdddd">-directory according to X's (relative) instructions.
-
-<h3 class="section">7.7 Shell-friendly syntax for configuration</h3>
</span><span style="color: #000000;background-color: #ddffdd">+directory according to X’s (relative) instructions.
+</p>
+<hr>
+<a name="Shell_002dfriendly-syntax-for-configuration"></a>
+<a name="Shell_002dfriendly-syntax-for-configuration-1"></a>
+<h3 class="section">8.7 Shell-friendly syntax for configuration</h3>
</span>
<p>When considering environment variable <code>CL_SOURCE_REGISTRY</code>
<span style="color: #000000;background-color: #ffdddd">-ASDF will skip to next configuration if it's an empty string.
</span><span style="color: #000000;background-color: #ddffdd">+ASDF will skip to next configuration if it’s an empty string.
</span> It will <code>READ</code> the string as a SEXP in the DSL
<span style="color: #000000;background-color: #ffdddd">-if it begins with a paren <code>(</code>
-and it will be interpreted much like <code>TEXINPUTS</code>
-list of paths, where
-
- <p>* paths are separated
</span><span style="color: #000000;background-color: #ddffdd">+if it begins with a paren <code>(</code>,
+otherwise it will be interpreted much like <code>TEXINPUTS</code>,
+as a list of paths, where
+</p>
+<p>* paths are separated
</span> by a <code>:</code> (colon) on Unix platforms (including cygwin),
by a <code>;</code> (semicolon) on other platforms (mainly, Windows).
<span style="color: #000000;background-color: #ffdddd">-
- <p>* each entry is a directory to add to the search path.
-
- <p>* if the entry ends with a double slash <code>//</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>* each entry is a directory to add to the search path.
+</p>
+<p>* if the entry ends with a double slash <code>//</code>
</span> then it instead indicates a tree in the subdirectories
of which to recurse.
<span style="color: #000000;background-color: #ffdddd">-
- <p>* if the entry is the empty string (which may only appear once),
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>* if the entry is the empty string (which may only appear once),
</span> then it indicates that the inherited configuration should be
spliced there.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Search-Algorithm"></a>
+<a name="Search-Algorithm-1"></a>
+<h3 class="section">8.8 Search Algorithm</h3>
+<a name="index-_002adefault_002dsource_002dregistry_002dexclusions_002a"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">7.8 Search Algorithm</h3>
-
-<p><a name="index-g_t_002adefault_002dsource_002dregistry_002dexclusions_002a-52"></a>
-In case that isn't clear, the semantics of the configuration is that
</span><span style="color: #000000;background-color: #ddffdd">+<p>In case that isn’t clear, the semantics of the configuration is that
</span> when searching for a system of a given name,
directives are processed in order.
<span style="color: #000000;background-color: #ffdddd">-
- <p>When looking in a directory, if the system is found, the search succeeds,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>When looking in a directory, if the system is found, the search succeeds,
</span> otherwise it continues.
<span style="color: #000000;background-color: #ffdddd">-
- <p>When looking in a tree, if one system is found, the search succeeds.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>When looking in a tree, if one system is found, the search succeeds.
</span> If multiple systems are found, the consequences are unspecified:
the search may succeed with any of the found systems,
<span style="color: #000000;background-color: #ffdddd">-or an error may be raised.
</span><span style="color: #000000;background-color: #ddffdd">+or an error may be raised.
</span> ASDF currently returns the first system found,
<span style="color: #000000;background-color: #ffdddd">-XCVB currently raised an error.
</span><span style="color: #000000;background-color: #ddffdd">+XCVB currently raised an error.
</span> If none is found, the search continues.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Exclude statements specify patterns of subdirectories
-the systems from which to ignore.
-Typically you don't want to use copies of files kept by such
-version control systems as Darcs.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Exclude statements specify patterns of subdirectories
+the systems from which to ignore.
+Typically you don’t want to use copies of files kept by such
+version control systems as Darcs.
</span> Exclude statements are not propagated to further included or inherited
configuration files or expressions;
instead the defaults are reset around every configuration statement
to the default defaults from <code>asdf::*default-source-registry-exclusions*</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Include statements cause the search to recurse with the path specifications
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Include statements cause the search to recurse with the path specifications
</span> from the file specified.
<span style="color: #000000;background-color: #ffdddd">-
- <p>An inherit-configuration statement cause the search to recurse with the path
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>An inherit-configuration statement cause the search to recurse with the path
</span> specifications from the next configuration
<span style="color: #000000;background-color: #ffdddd">-(see <a href="#Controlling-where-ASDF-searches-for-systems">Configurations</a> above).
</span><span style="color: #000000;background-color: #ddffdd">+(see <a href="#Configurations">Configurations</a> above).
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">7.9 Caching Results</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Caching-Results"></a>
+<a name="Caching-Results-1"></a>
+<h3 class="section">8.9 Caching Results</h3>
</span>
<p>The implementation is allowed to either eagerly compute the information
from the configurations and file system, or to lazily re-compute it
<span style="color: #000000;background-color: #ffdddd">-every time, or to cache any part of it as it goes.
-To explicitly flush any information cached by the system, use the API below.
</span><span style="color: #000000;background-color: #ddffdd">+every time, or to cache any part of it as it goes.
+In practice, the recommended <code>source-registry</code> eagerly collects and caches results
+and you need to explicitly flush the cache for change to be taken into account,
+whereas the old-style <code>*central-registry*</code> mechanism queries the filesystem every time.
+</p>
+<p>To explicitly flush any information cached by the system
+after a change was made in the filesystem, See <a href="#Configuration-API">Configuration API</a>,
+and e.g. call <code>asdf:clear-source-registry</code>.
+</p>
+<p>Starting with ASDF 3.1.4, you can also explicitly build a persistent cache
+of the <samp>.asd</samp> files found under a tree:
+when recursing into a directory declared by <code>:tree</code> and its transitive subdirectories,
+if a file <samp>.cl-source-registry.cache</samp> exists containing a form
+that is a list starting with <code>:source-registry-cache</code> followed by a list of strings,
+as in <code>(:source-registry-cache <em>"foo/bar.asd" "path/to/more.asd" ...</em>)</code>,
+then the strings are assumed to be <code>unix-namestring</code>s designating
+the available asd files under that tree, and the recursion otherwise stops.
+The list can also be empty, allowing to stop a costly recursion in a huge directory tree.
+</p>
+<p>To update such a cache after you install, update or remove source repositories,
+you can run a script distributed with ASDF:
+<code>tools/cl-source-registry-cache.lisp <em>/path/to/directory</em></code>.
+To wholly invalidate the cache, you can
+delete the file <samp>.cl-source-registry.cache</samp> in that directory.
+In either case, for an existing Lisp process to see this change,
+it needs to clear its own cache with e.g. <code>(asdf:clear-source-registry)</code>.
+</p>
+<p>Developers may safely create a cache in their development tree,
+and we recommend they do it at the top of their source tree if
+it contains more than a small number of files and directories;
+they only need update it when they create, remove or move <samp>.asd</samp> files.
+Software distribution managers may also safely create such a cache,
+but they must be careful to update it every time they install, update or remove
+a software source repository or installation package.
+Finally, advanced developers who juggle with a lot of code
+in their <code>source-registry</code> may manually manage such a cache,
+to allow for faster startup of Lisp programs.
+</p>
+<p>This persistence cache can help you reduce startup latency.
+For instance, on one machine with hundreds of source repositories,
+such a cache shaves half a second at the startup
+of every <code>#!/usr/bin/cl</code> script using SBCL, more on other implementations;
+this makes a notable difference as to
+their subjective interactivity and usability.
+The speedup will only happen if the implementation-provided ASDF is recent enough
+(3.1.3.7 or later); it is not enough for a recent ASDF upgrade to be present,
+since the upgrade will itself be found but
+after the old version has scanned the directories without heeding such a cache.
+To upgrade the implementation-provided ASDF,
+use our script <code>tools/install-asdf.lisp</code>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">7.10 Configuration API</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Configuration-API"></a>
+<a name="Configuration-API-1"></a>
+<h3 class="section">8.10 Configuration API</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>The specified functions are exported from your build system's package.
</span><span style="color: #000000;background-color: #ddffdd">+<p>The specified functions are exported from your build system’s package.
</span> Thus for ASDF the corresponding functions are in package ASDF,
and for XCVB the corresponding functions are in package XCVB.
<span style="color: #000000;background-color: #ffdddd">-
-<div class="defun">
-— Function: <b>initialize-source-registry</b><var> &optional PARAMETER<a name="index-initialize_002dsource_002dregistry-53"></a></var><br>
-<blockquote><p> will read the configuration and initialize all internal variables.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<dl>
+<dt><a name="index-initialize_002dsource_002dregistry"></a>Function: <strong>initialize-source-registry</strong> <em>&optional PARAMETER</em></dt>
+<dd><p>will read the configuration and initialize all internal variables.
</span> You may extend or override configuration
from the environment and configuration files
with the given <var>PARAMETER</var>, which can be
<span style="color: #aaaaaa">@@ -2643,256 +3417,338 @@ and for XCVB the corresponding functions are in package XCVB.
</span> or a SEXP (in the SEXP DSL),
a string (as in the string DSL),
a pathname (of a file or directory with configuration),
<span style="color: #000000;background-color: #ffdddd">- or a symbol (fbound to function that when called returns one of the above).
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+ or a symbol (fbound to function that when called returns one of the above).
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<div class="defun">
-— Function: <b>clear-source-registry</b><var><a name="index-clear_002dsource_002dregistry-54"></a></var><br>
-<blockquote><p> undoes any source registry configuration
- and clears any cache for the search algorithm.
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-clear_002dsource_002dregistry"></a>Function: <strong>clear-source-registry</strong></dt>
+<dd><p>undoes any source registry configuration
+ and clears any cache for the search algorithm.
</span> You might want to call this function
(or better, <code>clear-configuration</code>)
before you dump an image that would be resumed
with a different configuration,
<span style="color: #000000;background-color: #ffdddd">- and return an empty configuration.
</span><span style="color: #000000;background-color: #ddffdd">+ and return an empty configuration.
</span> Note that this does not include clearing information about
systems defined in the current image, only about
<span style="color: #000000;background-color: #ffdddd">- where to look for systems not yet defined.
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+ where to look for systems not yet defined.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<div class="defun">
-— Function: <b>ensure-source-registry</b><var> &optional PARAMETER<a name="index-ensure_002dsource_002dregistry-55"></a></var><br>
-<blockquote><p> checks whether a source registry has been initialized.
- If not, initialize it with the given <var>PARAMETER</var>.
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-ensure_002dsource_002dregistry"></a>Function: <strong>ensure-source-registry</strong> <em>&optional PARAMETER</em></dt>
+<dd><p>checks whether a source registry has been initialized.
+ If not, initialize it with the given <var>PARAMETER</var>.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Every time you use ASDF's <code>find-system</code>, or
</span><span style="color: #000000;background-color: #ddffdd">+<p>Every time you use ASDF’s <code>find-system</code>, or
</span> anything that uses it (such as <code>operate</code>, <code>load-system</code>, etc.),
<code>ensure-source-registry</code> is called with parameter <code>nil</code>,
<span style="color: #000000;background-color: #ffdddd">-which the first time around causes your configuration to be read.
</span><span style="color: #000000;background-color: #ddffdd">+which the first time around causes your configuration to be read.
</span> If you change a configuration file,
you need to explicitly <code>initialize-source-registry</code> again,
or maybe simply to <code>clear-source-registry</code> (or <code>clear-configuration</code>)
which will cause the initialization to happen next time around.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Introspection"></a>
+<a name="Introspection-1"></a>
+<h3 class="section">8.11 Introspection</h3>
+
+
+<hr>
+<a name="g_t_002asource_002dregistry_002dparameter_002a-variable"></a>
+<a name="g_t_002asource_002dregistry_002dparameter_002a-variable-1"></a>
+<h4 class="subsection">8.11.1 *source-registry-parameter* variable</h4>
+<a name="index-_002asource_002dregistry_002dparameter_002a"></a>
+
+<p>We have made available the variable <code>*source-registry-parameter*</code>
+that can be used by code that wishes to introspect about the (past)
+configuration of ASDF’s source registry. <strong>This variable should
+never be set!</strong> It will be set as a side-effect of calling
+<code>initialize-source-registry</code>; user code should treat it as
+read-only.
+</p>
+<hr>
+<a name="Information-about-system-dependencies"></a>
+<a name="Information-about-system-dependencies-1"></a>
+<h4 class="subsection">8.11.2 Information about system dependencies</h4>
+
+<p>ASDF makes available three functions to read system interdependencies.
+These are intended to aid programmers who wish to perform dependency
+analyses.
+</p>
+<dl>
+<dt><a name="index-system_002ddefsystem_002ddepends_002don"></a>Function: <strong>system-defsystem-depends-on</strong> <em>system</em></dt>
+</dl>
+
+<dl>
+<dt><a name="index-system_002ddepends_002don"></a>Function: <strong>system-depends-on</strong> <em>system</em></dt>
+</dl>
+
+<dl>
+<dt><a name="index-system_002dweakly_002ddepends_002don"></a>Function: <strong>system-weakly-depends-on</strong> <em>system</em></dt>
+<dd><p>Returns a list of names of systems that are weakly depended on by
+<var>system</var>. Weakly depended on systems are optionally loaded only if
+ASDF can find them; failure to find such systems does <em>not</em> cause an
+error in loading.
+</p>
+<p>Note that the return value for <code>system-weakly-depends-on</code> is simpler
+than the return values of the other two system dependency introspection
+functions.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">7.11 Status</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Status"></a>
+<a name="Status-1"></a>
+<h3 class="section">8.12 Status</h3>
</span>
<p>This mechanism is vastly successful, and we have declared
that <code>asdf:*central-registry*</code> is not recommended anymore,
<span style="color: #000000;background-color: #ffdddd">-though we will continue to support it.
</span><span style="color: #000000;background-color: #ddffdd">+though we will continue to support it.
</span> All hooks into implementation-specific search mechanisms
have been integrated in the <code>wrapping-source-registry</code>
that everyone uses implicitly.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Rejected-ideas"></a>
+<a name="Rejected-ideas-1"></a>
+<h3 class="section">8.13 Rejected ideas</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">7.12 Rejected ideas</h3>
-
-<p>Alternatives I considered and rejected included:
-
- <ol type=1 start=1>
-<li>Keep <code>asdf:*central-registry*</code> as the master with its current semantics,
</span><span style="color: #000000;background-color: #ddffdd">+<p>Alternatives I (FRR) considered and rejected while developing ASDF 2 included:
+</p>
+<ol>
+<li> Keep <code>asdf:*central-registry*</code> as the master with its current semantics,
</span> and somehow the configuration parser expands the new configuration
language into a expanded series of directories of subdirectories to
lookup, pre-recursing through specified hierarchies. This is kludgy,
and leaves little space of future cleanups and extensions.
<span style="color: #000000;background-color: #ffdddd">- <li>Keep <code>asdf:*central-registry*</code> remains the master but extend its semantics
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Keep <code>asdf:*central-registry*</code> as the master but extend its semantics
</span> in completely new ways, so that new kinds of entries may be implemented
as a recursive search, etc. This seems somewhat backwards.
<span style="color: #000000;background-color: #ffdddd">- <li>Completely remove <code>asdf:*central-registry*</code>
- and break backwards compatibility.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Completely remove <code>asdf:*central-registry*</code>
+ and break backwards compatibility.
</span> Hopefully this will happen in a few years after everyone migrate to
a better ASDF and/or to XCVB, but it would be very bad to do it now.
<span style="color: #000000;background-color: #ffdddd">- <li>Replace <code>asdf:*central-registry*</code> by a symbol-macro with appropriate magic
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Replace <code>asdf:*central-registry*</code> by a symbol-macro with appropriate magic
</span> when you dereference it or setf it. Only the new variable with new
<span style="color: #000000;background-color: #ffdddd">- semantics is handled by the new search procedure.
</span><span style="color: #000000;background-color: #ddffdd">+ semantics is handled by the new search procedure.
</span> Complex and still introduces subtle semantic issues.
<span style="color: #000000;background-color: #ffdddd">- </ol>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ol>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>I've been suggested the below features, but have rejected them,
-for the sake of keeping ASDF no more complex than strictly necessary.
</span>
<span style="color: #000000;background-color: #ffdddd">- <ul>
-<li> More syntactic sugar: synonyms for the configuration directives, such as
</span><span style="color: #000000;background-color: #ddffdd">+<p>I’ve been suggested the below features, but have rejected them,
+for the sake of keeping ASDF no more complex than strictly necessary.
+</p>
+<ul>
+<li> More syntactic sugar: synonyms for the configuration directives, such as
</span> <code>(:add-directory X)</code> for <code>(:directory X)</code>, or <code>(:add-directory-hierarchy X)</code>
or <code>(:add-directory X :recurse t)</code> for <code>(:tree X)</code>.
<span style="color: #000000;background-color: #ffdddd">- <li> The possibility to register individual files instead of directories.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The possibility to register individual files instead of directories.
</span>
<span style="color: #000000;background-color: #ffdddd">- <li> Integrate Xach Beane's tilde expander into the parser,
- or something similar that is shell-friendly or shell-compatible.
- I'd rather keep ASDF minimal. But maybe this precisely keeps it
- minimal by removing the need for evaluated entries that ASDF has?
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Integrate Xach Beane’s tilde expander into the parser,
+ or something similar that is shell-friendly or shell-compatible.
+ I’d rather keep ASDF minimal. But maybe this precisely keeps it
+ minimal by removing the need for evaluated entries that ASDF has?
</span> i.e. uses of <code>USER-HOMEDIR-PATHNAME</code> and <code>$SBCL_HOME</code>
Hopefully, these are already superseded by the <code>:default-registry</code>
<span style="color: #000000;background-color: #ffdddd">- <li> Using the shell-unfriendly syntax <code>/**</code> instead of <code>//</code> to specify recursion
- down a filesystem tree in the environment variable.
- It isn't that Lisp friendly either.
-</ul>
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Using the shell-unfriendly syntax <code>/**</code> instead of TEXINPUTS-like <code>//</code> to specify recursion
+ down a filesystem tree in the environment variable.
+ It isn’t that Lisp friendly either.
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">7.13 TODO</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="TODO"></a>
+<a name="TODO-1"></a>
+<h3 class="section">8.14 TODO</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">- <ul>
-<li>Add examples
-</ul>
</span><span style="color: #000000;background-color: #ddffdd">+<ul>
+<li> Add examples
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">7.14 Credits for the source-registry</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Credits-for-the-source_002dregistry"></a>
+<a name="Credits-for-the-source_002dregistry-1"></a>
+<h3 class="section">8.15 Credits for the source-registry</h3>
</span>
<p>Thanks a lot to Stelian Ionescu for the initial idea.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Thanks to Rommel Martinez for the initial implementation attempt.
-
- <p>All bad design ideas and implementation bugs are to mine, not theirs.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Thanks to Rommel Martinez for the initial implementation attempt.
+</p>
+<p>All bad design ideas and implementation bugs are mine, not theirs.
</span> But so are good design ideas and elegant implementation tricks.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>— Francois-Rene Rideau <a href="mailto:fare@tunes.org">fare@tunes.org</a>, Mon, 22 Feb 2010 00:07:33 -0500
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>— Francois-Rene Rideau <a href="mailto:fare@tunes.org">fare@tunes.org</a>, Mon, 22 Feb 2010 00:07:33 -0500
-
-<p><a name="Controlling-where-ASDF-saves-compiled-files"></a>
-
-<!-- node-name, next, previous, up -->
-<h2 class="chapter">8 Controlling where ASDF saves compiled files</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-asdf_002doutput_002dtranslations-56"></a><a name="index-ASDF_005fOUTPUT_005fTRANSLATIONS-57"></a>
-Each Common Lisp implementation has its own format
-for compiled files (fasls for short, short for “fast loading”).
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Controlling-where-ASDF-saves-compiled-files"></a>
+<a name="Controlling-where-ASDF-saves-compiled-files-1"></a>
+<h2 class="chapter">9 Controlling where ASDF saves compiled files</h2>
+<a name="index-asdf_002doutput_002dtranslations"></a>
+<a name="index-ASDF_005fOUTPUT_005fTRANSLATIONS"></a>
+
+<p>Each Common Lisp implementation has its own format
+for compiled files or fasls.<a name="DOCF14" href="#FOOT14"><sup>14</sup></a>
</span> If you use multiple implementations
(or multiple versions of the same implementation),
<span style="color: #000000;background-color: #ffdddd">-you'll soon find your source directories
-littered with various <samp><span class="file">fasl</span></samp>s, <samp><span class="file">dfsl</span></samp>s, <samp><span class="file">cfsl</span></samp>s and so on.
-Worse yet, some implementations use the same file extension
-while changing formats from version to version (or platform to platform)
-which means that you'll have to recompile binaries
</span><span style="color: #000000;background-color: #ddffdd">+you’ll soon find your source directories
+littered with various <samp>fasl</samp>s, <samp>dfsl</samp>s, <samp>cfsl</samp>s and so
+on.
+Worse yet, multiple implementations use the same file extension and
+some implementations maintain the same file extension
+while changing formats from version to version (or platform to
+platform).
+This can lead to many errors and much confusion
</span> as you switch from one implementation to the next.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Since ASDF 2, ASDF includes the <code>asdf-output-translations</code> facility
</span><span style="color: #000000;background-color: #ddffdd">+Finally, this requires write access to the source directory,
+and therefore precludes sharing of a same source code directory between multiple users.
+</p>
+<p>Since ASDF 2, ASDF includes the <code>asdf-output-translations</code> facility
</span> to mitigate the problem.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">8.1 Configurations</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Output-Configurations"></a>
+<a name="Configurations-2"></a>
+<h3 class="section">9.1 Configurations</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Configurations specify mappings from input locations to output locations.
-Once again we rely on the XDG base directory specification for configuration.
-See <a href="#Controlling-where-ASDF-searches-for-systems">XDG base directory</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <ol type=1 start=1>
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>Some hardcoded wrapping output translations configuration may be used.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Configurations specify mappings from input locations to output locations.
+Once again we rely on the XDG base directory specification for configuration.
+See <a href="#Controlling-where-ASDF-searches-for-systems">XDG base directory</a>.
+</p>
+<ol>
+<li> Some hardcoded wrapping output translations configuration may be used.
</span> This allows special output translations (or usually, invariant directories)
to be specified corresponding to the similar special entries in the source registry.
<span style="color: #000000;background-color: #ffdddd">- <li>An application may explicitly initialize the output-translations
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> An application may explicitly initialize the output-translations
</span> configuration using the Configuration API
<span style="color: #000000;background-color: #ffdddd">-in which case this takes precedence.
-(see <a href="#Controlling-where-ASDF-saves-compiled-files">Configuration API</a>.)
</span><span style="color: #000000;background-color: #ddffdd">+in which case this takes precedence.
+(see <a href="#Controlling-where-ASDF-saves-compiled-files">Configuration API</a>.)
</span> It may itself compute this configuration from the command-line,
from a script, from its own configuration file, etc.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> the environment variable <code>ASDF_OUTPUT_TRANSLATIONS</code> if it exists.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> user configuration file
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf</span></samp>
</span><span style="color: #000000;background-color: #ddffdd">+<samp>$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf</samp>
</span> (which defaults to
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">~/.config/common-lisp/asdf-output-translations.conf</span></samp>)
</span><span style="color: #000000;background-color: #ddffdd">+<samp>~/.config/common-lisp/asdf-output-translations.conf</samp>)
</span> if it exists.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> user configuration directory
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf.d/</span></samp>
</span><span style="color: #000000;background-color: #ddffdd">+<samp>$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf.d/</samp>
</span> (which defaults to
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">~/.config/common-lisp/asdf-output-translations.conf.d/</span></samp>)
</span><span style="color: #000000;background-color: #ddffdd">+<samp>~/.config/common-lisp/asdf-output-translations.conf.d/</samp>)
</span> if it exists.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> system configuration file
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">/etc/common-lisp/asdf-output-translations.conf</span></samp>
</span><span style="color: #000000;background-color: #ddffdd">+<samp>/etc/common-lisp/asdf-output-translations.conf</samp>
</span> if it exists.
<span style="color: #000000;background-color: #ffdddd">- <li>The source registry will be configured from
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The source registry will be configured from
</span> system configuration directory
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">/etc/common-lisp/asdf-output-translations.conf.d/</span></samp>
</span><span style="color: #000000;background-color: #ddffdd">+<samp>/etc/common-lisp/asdf-output-translations.conf.d/</samp>
</span> if it exists.
<span style="color: #000000;background-color: #ffdddd">- </ol>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ol>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Each of these configurations is specified as a SEXP
-in a trival domain-specific language (defined below).
</span><span style="color: #000000;background-color: #ddffdd">+<p>Each of these configurations is specified as a SEXP
+in a trivial domain-specific language (see <a href="#Configuration-DSL">Configuration DSL</a>).
</span> Additionally, a more shell-friendly syntax is available
<span style="color: #000000;background-color: #ffdddd">-for the environment variable (defined yet below).
-
- <p>Each of these configurations is only used if the previous
-configuration explicitly or implicitly specifies that it
</span><span style="color: #000000;background-color: #ddffdd">+for the environment variable (see <a href="#Shell_002dfriendly-syntax-for-configuration">Shell-friendly syntax for configuration</a>).
+</p>
+<p>When processing an entry in the above list of configuration methods,
+ASDF will stop unless that entry
+explicitly or implicitly specifies that it
</span> includes its inherited configuration.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Note that by default, a per-user cache is used for output files.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that by default, a per-user cache is used for output files.
</span> This allows the seamless use of shared installations of software
between several users, and takes files out of the way of the developers
when they browse source code,
at the expense of taking a small toll when developers have to clean up
<span style="color: #000000;background-color: #ffdddd">-output files and find they need to get familiar with output-translations first.
</span><span style="color: #000000;background-color: #ddffdd">+output files and find they need to get familiar with output-translations
+first.<a name="DOCF15" href="#FOOT15"><sup>15</sup></a>
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">8.2 Backward Compatibility</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Output-Backward-Compatibility"></a>
+<a name="Backward-Compatibility-2"></a>
+<h3 class="section">9.2 Backward Compatibility</h3>
+<a name="index-ASDF_002dBINARY_002dLOCATIONS-compatibility"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="index-ASDF_002dBINARY_002dLOCATIONS-compatibility-58"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>We purposefully do NOT provide backward compatibility with earlier versions of
</span><span style="color: #000000;background-color: #ddffdd">+<p>We purposely do <em>not</em> provide backward compatibility with earlier versions of
</span> <code>ASDF-Binary-Locations</code> (8 Sept 2009),
<code>common-lisp-controller</code> (7.0) or
<code>cl-launch</code> (2.35),
<span style="color: #000000;background-color: #ffdddd">-each of which had similar general capabilities.
-The previous APIs of these programs were not designed
-for configuration by the end-user
-in an easy way with configuration files.
-Recent versions of same packages use
-the new <code>asdf-output-translations</code> API as defined below:
-<code>common-lisp-controller</code> (7.2) and <code>cl-launch</code> (3.000).
</span><span style="color: #000000;background-color: #ddffdd">+each of which had similar general capabilities.
+The APIs of these programs were not designed
+for easy user configuration
+through configuration files.
+Recent versions of <code>common-lisp-controller</code> (7.2) and <code>cl-launch</code> (3.000)
+use the new <code>asdf-output-translations</code> API as defined below.
</span> <code>ASDF-Binary-Locations</code> is fully superseded and not to be used anymore.
<span style="color: #000000;background-color: #ffdddd">-
- <p>This incompatibility shouldn't inconvenience many people.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>This incompatibility shouldn’t inconvenience many people.
</span> Indeed, few people use and customize these packages;
<span style="color: #000000;background-color: #ffdddd">-these few people are experts who can trivially adapt to the new configuration.
</span><span style="color: #000000;background-color: #ddffdd">+these few people are experts who can trivially adapt to the new configuration.
</span> Most people are not experts, could not properly configure these features
(except inasmuch as the default configuration of
<code>common-lisp-controller</code> and/or <code>cl-launch</code>
might have been doing the right thing for some users),
and yet will experience software that “just works”,
as configured by the system distributor, or by default.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Nevertheless, if you are a fan of <code>ASDF-Binary-Locations</code>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Nevertheless, if you are a fan of <code>ASDF-Binary-Locations</code>,
</span> we provide a limited emulation mode:
<span style="color: #000000;background-color: #ffdddd">-
-<div class="defun">
-— Function: <b>enable-asdf-binary-locations-compatibility</b><var> &key centralize-lisp-binaries default-toplevel-directory include-per-user-information map-all-source-files source-to-target-mappings<a name="index-enable_002dasdf_002dbinary_002dlocations_002dcompatibility-59"></a></var><br>
-<blockquote><p>This function will initialize the new <code>asdf-output-translations</code> facility in a way
-that emulates the behavior of the old <code>ASDF-Binary-Locations</code> facility.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<dl>
+<dt><a name="index-enable_002dasdf_002dbinary_002dlocations_002dcompatibility"></a>Function: <strong>enable-asdf-binary-locations-compatibility</strong> <em>&key centralize-lisp-binaries default-toplevel-directory include-per-user-information map-all-source-files source-to-target-mappings</em></dt>
+<dd><p>This function will initialize the new <code>asdf-output-translations</code> facility in a way
+that emulates the behaviour of the old <code>ASDF-Binary-Locations</code> facility.
</span> Where you would previously set global variables
<var>*centralize-lisp-binaries*</var>,
<var>*default-toplevel-directory*</var>,
<var>*include-per-user-information*</var>,
<var>*map-all-source-files*</var> or <var>*source-to-target-mappings*</var>
<span style="color: #000000;background-color: #ffdddd">-you will now have to pass the same values as keyword arguments to this function.
</span><span style="color: #000000;background-color: #ddffdd">+you will now have to pass the same values as keyword arguments to this function.
</span> Note however that as an extension the <code>:source-to-target-mappings</code> keyword argument
will accept any valid pathname designator for <code>asdf-output-translations</code>
<span style="color: #000000;background-color: #ffdddd">-instead of just strings and pathnames.
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+instead of just strings and pathnames.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If you insist, you can also keep using the old <code>ASDF-Binary-Locations</code>
</span><span style="color: #000000;background-color: #ddffdd">+<p>If you insist, you can also keep using the old <code>ASDF-Binary-Locations</code>
</span> (the one available as an extension to load of top of ASDF,
not the one built into a few old versions of ASDF),
but first you must disable <code>asdf-output-translations</code>
with <code>(asdf:disable-output-translations)</code>,
or you might experience “interesting” issues.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Also, note that output translation is enabled by default.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Also, note that output translation is enabled by default.
</span> To disable it, use <code>(asdf:disable-output-translations)</code>.
<span style="color: #000000;background-color: #ffdddd">-
-<h3 class="section">8.3 Configuration DSL</h3>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Output-Configuration-DSL"></a>
+<a name="Configuration-DSL-2"></a>
+<h3 class="section">9.3 Configuration DSL</h3>
</span>
<p>Here is the grammar of the SEXP DSL
for <code>asdf-output-translations</code> configuration:
<span style="color: #000000;background-color: #ffdddd">-
</span><span style="color: #000000;background-color: #ddffdd">+</p>
</span> <pre class="verbatim">;; A configuration is single SEXP starting with keyword :source-registry
;; followed by a list of directives.
CONFIGURATION := (:output-translations DIRECTIVE ...)
<span style="color: #aaaaaa">@@ -2902,18 +3758,22 @@ DIRECTIVE :=
</span> ;; INHERITANCE DIRECTIVE:
;; Your configuration expression MUST contain
;; exactly one of either of these:
<span style="color: #000000;background-color: #ffdddd">- :inherit-configuration | ; splices inherited configuration (often specified last)
- :ignore-inherited-configuration | ; drop inherited configuration (specified anywhere)
</span><span style="color: #000000;background-color: #ddffdd">+ :inherit-configuration |
+ ;; splices inherited configuration (often specified last)
+ :ignore-inherited-configuration |
+ ;; drop inherited configuration (specified anywhere)
</span>
;; forward compatibility directive (since ASDF 2.011.4), useful when
;; you want to use new configuration features but have to bootstrap a
<span style="color: #000000;background-color: #ffdddd">- ;; the newer required ASDF from an older release that doesn't sport said features:
- :ignore-invalid-entries | ; drops subsequent invalid entries instead of erroring out
</span><span style="color: #000000;background-color: #ddffdd">+ ;; the newer required ASDF from an older release that doesn't have
+ ;; said features:
+ :ignore-invalid-entries |
</span>
;; include a configuration file or directory
(:include PATHNAME-DESIGNATOR) |
<span style="color: #000000;background-color: #ffdddd">- ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/ or something.
</span><span style="color: #000000;background-color: #ddffdd">+ ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/
+ ;; or something.
</span> :enable-user-cache |
;; Disable global cache. Map / to /
:disable-cache |
<span style="color: #aaaaaa">@@ -2925,178 +3785,210 @@ DIRECTIVE :=
</span> (DIRECTORY-DESIGNATOR (:function TRANSLATION-FUNCTION))
DIRECTORY-DESIGNATOR :=
<span style="color: #000000;background-color: #ffdddd">- NIL | ;; As source: skip this entry. As destination: same as source
- T | ;; as source matches anything, as destination leaves pathname unmapped.
- ABSOLUTE-COMPONENT-DESIGNATOR ;; same as in the source-registry language
</span><span style="color: #000000;background-color: #ddffdd">+ NIL | ; As source: skip this entry. As destination: same as source
+ T | ; as source matches anything, as destination
+ ; maps pathname to itself.
+ ABSOLUTE-COMPONENT-DESIGNATOR ; same as in the source-registry language
</span>
TRANSLATION-FUNCTION :=
<span style="color: #000000;background-color: #ffdddd">- SYMBOL | ;; symbol of a function that takes two arguments,
- ;; the pathname to be translated and the matching DIRECTORY-DESIGNATOR
- LAMBDA ;; A form which evalutates to a function taking two arguments consisting of
- ;; the pathname to be translated and the matching DIRECTORY-DESIGNATOR
</span><span style="color: #000000;background-color: #ddffdd">+ SYMBOL | ;; symbol naming a function that takes two arguments:
+ ;; the pathname to be translated and the matching
+ ;; DIRECTORY-DESIGNATOR
+ LAMBDA ;; A form which evaluates to a function taking two arguments:
+ ;; the pathname to be translated and the matching
+ ;; DIRECTORY-DESIGNATOR
</span>
</pre>
<span style="color: #000000;background-color: #ffdddd">-
- <p>Relative components better be either relative
</span><span style="color: #000000;background-color: #ddffdd">+<p>Relative components better be either relative
</span> or subdirectories of the path before them, or bust.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The last component, if not a pathname, is notionally completed by <samp><span class="file">/**/*.*</span></samp>.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The last component, if not a pathname, is notionally completed by <samp>/**/*.*</samp>.
</span> You can specify more fine-grained patterns
by using a pathname object as the last component
<span style="color: #000000;background-color: #ffdddd">-e.g. <samp><span class="file">#p"some/path/**/foo*/bar-*.fasl"</span></samp>
-
- <p>You may use <code>#+features</code> to customize the configuration file.
-
- <p>The second designator of a mapping may be <code>nil</code>, indicating that files are not mapped
</span><span style="color: #000000;background-color: #ddffdd">+e.g. <samp>#p"some/path/**/foo*/bar-*.fasl"</samp>
+</p>
+<p>You may use <code>#+features</code> to customize the configuration file.
+</p>
+<p>The second designator of a mapping may be <code>nil</code>, indicating that files are not mapped
</span> to anything but themselves (same as if the second designator was the same as the first).
<span style="color: #000000;background-color: #ffdddd">-
- <p>When the first designator is <code>t</code>,
-the mapping always matches.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>When the first designator is <code>t</code>,
+the mapping always matches.
</span> When the first designator starts with <code>:root</code>,
<span style="color: #000000;background-color: #ffdddd">-the mapping matches any host and device.
</span><span style="color: #000000;background-color: #ddffdd">+the mapping matches any host and device.
</span> In either of these cases, if the second designator
<span style="color: #000000;background-color: #ffdddd">-isn't <code>t</code> and doesn't start with <code>:root</code>,
</span><span style="color: #000000;background-color: #ddffdd">+isn’t <code>t</code> and doesn’t start with <code>:root</code>,
</span> then strings indicating the host and pathname are somehow copied
in the beginning of the directory component of the source pathname
before it is translated.
<span style="color: #000000;background-color: #ffdddd">-
- <p>When the second designator is <code>t</code>, the mapping is the identity.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>When the second designator is <code>t</code>, the mapping is the identity.
</span> When the second designator starts with <code>:root</code>,
<span style="color: #000000;background-color: #ffdddd">-the mapping preserves the host and device of the original pathname.
</span><span style="color: #000000;background-color: #ddffdd">+the mapping preserves the host and device of the original pathname.
</span> Notably, this allows you to map files
<span style="color: #000000;background-color: #ffdddd">-to a subdirectory of the whichever directory the file is in.
-Though the syntax is not quite as easy to use as we'd like,
</span><span style="color: #000000;background-color: #ddffdd">+to a subdirectory of the whichever directory the file is in.
+Though the syntax is not quite as easy to use as we’d like,
</span> you can have an (source destination) mapping entry such as follows
in your configuration file,
or you may use <code>enable-asdf-binary-locations-compatibility</code>
with <code>:centralize-lisp-binaries nil</code>
which will do the same thing internally for you:
<span style="color: #000000;background-color: #ffdddd">-<pre class="verbatim"> #.(let ((wild-subdir (make-pathname :directory '(:relative :wild-inferiors)))
- (wild-file (make-pathname :name :wild :version :wild :type :wild)))
- `((:root ,wild-subdir ,wild-file) ;; Or using the implicit wildcard, just :root
- (:root ,wild-subdir :implementation ,wild-file)))
-</pre>
-Starting with ASDF 2.011.4, you can use the simpler:
</span><span style="color: #000000;background-color: #ddffdd">+</p><div class="lisp">
+<pre class="lisp">#.(let ((wild-subdir
+ (make-pathname :directory '(:relative :wild-inferiors)))
+ (wild-file
+ (make-pathname :name :wild :version :wild :type :wild)))
+ `((:root ,wild-subdir ,wild-file)
+ (:root ,wild-subdir :implementation ,wild-file)))
+</pre></div>
+<p>Starting with ASDF 2.011.4, you can use the simpler:
</span> <code>`(:root (:root :**/ :implementation :*.*.*))</code>
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><code>:include</code> statements cause the search to recurse with the path specifications
-from the file specified.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If the <code>translate-pathname</code> mechanism cannot achieve a desired
</span><span style="color: #000000;background-color: #ddffdd">+<p><code>:include</code> statements cause the search to recurse with the path specifications
+from the file specified.
+</p>
+<p>If the <code>translate-pathname</code> mechanism cannot achieve a desired
</span> translation, the user may provide a function which provides the
<span style="color: #000000;background-color: #ffdddd">-required algorithim. Such a translation function is specified by
</span><span style="color: #000000;background-color: #ddffdd">+required algorithm. Such a translation function is specified by
</span> supplying a list as the second <code>directory-designator</code>
the first element of which is the keyword <code>:function</code>,
and the second element of which is
<span style="color: #000000;background-color: #ffdddd">-either a symbol which designates a function or a lambda expression.
</span><span style="color: #000000;background-color: #ddffdd">+either a symbol which designates a function or a lambda expression.
</span> The function designated by the second argument must take two arguments,
the first being the pathname of the source file,
<span style="color: #000000;background-color: #ffdddd">-the second being the wildcard that was matched.
-The result of the function invocation should be the translated pathname.
-
- <p>An <code>:inherit-configuration</code> statement cause the search to recurse with the path
-specifications from the next configuration.
</span><span style="color: #000000;background-color: #ddffdd">+the second being the wildcard that was matched.
+When invoked, the function should return the translated pathname.
+</p>
+<p>An <code>:inherit-configuration</code> statement causes the search to recurse with the path
+specifications from the next configuration in the bulleted list.
</span> See <a href="#Controlling-where-ASDF-saves-compiled-files">Configurations</a>, above.
<span style="color: #000000;background-color: #ffdddd">-
- <ul>
-<li><code>:enable-user-cache</code> is the same as <code>(t :user-cache)</code>.
-<li><code>:disable-cache</code> is the same as <code>(t t)</code>.
-<li><code>:user-cache</code> uses the contents of variable <code>asdf::*user-cache*</code>
-which by default is the same as using
-<code>(:home ".cache" "common-lisp" :implementation)</code>.
-<li><code>:system-cache</code> uses the contents of variable <code>asdf::*system-cache*</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="index-asdf_003a_003a_002auser_002dcache_002a"></a>
+<ul>
+<li> <code>:enable-user-cache</code> is the same as <code>(t :user-cache)</code>.
+</li><li> <code>:disable-cache</code> is the same as <code>(t t)</code>.
+</li><li> <code>:user-cache</code> uses the contents of variable <code>asdf::*user-cache*</code>
</span> which by default is the same as using
<span style="color: #000000;background-color: #ffdddd">-<code>("/var/cache/common-lisp" :uid :implementation-type)</code>
-(on Unix and cygwin), or something semi-sensible on Windows.
-</ul>
</span><span style="color: #000000;background-color: #ddffdd">+<code>(:home ".cache" "common-lisp" :implementation)</code>.
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">8.4 Configuration Directories</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Configuration directories consist in files each contains
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Output-Configuration-Directories"></a>
+<a name="Configuration-Directories-2"></a>
+<h3 class="section">9.4 Configuration Directories</h3>
+
+<p>Configuration directories consist of files, each of which contains
</span> a list of directives without any enclosing
<span style="color: #000000;background-color: #ffdddd">-<code>(:output-translations ...)</code> form.
</span><span style="color: #000000;background-color: #ddffdd">+<code>(:output-translations ...)</code> form.
</span> The files will be sorted by namestring as if by <code>string<</code> and
<span style="color: #000000;background-color: #ffdddd">-the lists of directives of these files with be concatenated in order.
</span><span style="color: #000000;background-color: #ddffdd">+the lists of directives of these files with be concatenated in order.
</span> An implicit <code>:inherit-configuration</code> will be included
at the <em>end</em> of the list.
<span style="color: #000000;background-color: #ffdddd">-
- <p>This allows for packaging software that has file granularity
-(e.g. Debian's <samp><span class="command">dpkg</span></samp> or some future version of <samp><span class="command">clbuild</span></samp>)
-to easily include configuration information about software being distributed.
-
- <p>The convention is that, for sorting purposes,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>System-wide or per-user Common Lisp software distributions
+such as Debian packages or some future version of <code>clbuild</code>
+may then include files such as
+<samp>/etc/common-lisp/asdf-output-translations.conf.d/10-foo.conf</samp> or
+<samp>~/.config/common-lisp/asdf-output-translations.conf.d/10-foo.conf</samp>
+to easily and modularly register configuration information
+about software being distributed.
+</p>
+<p>The convention is that, for sorting purposes,
</span> the names of files in such a directory begin with two digits
<span style="color: #000000;background-color: #ffdddd">-that determine the order in which these entries will be read.
-Also, the type of these files is conventionally <code>"conf"</code>
-and as a limitation of some implementations, the type cannot be <code>nil</code>.
-
- <p>Directories may be included by specifying a directory pathname
</span><span style="color: #000000;background-color: #ddffdd">+that determine the order in which these entries will be read.
+Also, the type of these files must be <samp>.conf</samp>,
+which not only simplifies the implementation by allowing
+for more portable techniques in finding those files,
+but also makes it trivial to disable a file, by renaming it to a different file type.
+</p>
+<p>Directories may be included by specifying a directory pathname
</span> or namestring in an <code>:include</code> directive, e.g.:
<span style="color: #000000;background-color: #ffdddd">-<pre class="verbatim"> (:include "/foo/bar/")
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<pre class="verbatim"> (:include "/foo/bar/")
</span> </pre>
<span style="color: #000000;background-color: #ffdddd">-
-<h3 class="section">8.5 Shell-friendly syntax for configuration</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Output-Shell_002dfriendly-syntax-for-configuration"></a>
+<a name="Shell_002dfriendly-syntax-for-configuration-2"></a>
+<h3 class="section">9.5 Shell-friendly syntax for configuration</h3>
</span>
<p>When considering environment variable <code>ASDF_OUTPUT_TRANSLATIONS</code>
<span style="color: #000000;background-color: #ffdddd">-ASDF will skip to next configuration if it's an empty string.
</span><span style="color: #000000;background-color: #ddffdd">+ASDF will skip to the next configuration if it’s an empty string.
</span> It will <code>READ</code> the string as an SEXP in the DSL
if it begins with a paren <code>(</code>
<span style="color: #000000;background-color: #ffdddd">-and it will be interpreted as a list of directories.
-Directories should come by pairs, indicating a mapping directive.
</span><span style="color: #000000;background-color: #ddffdd">+and it will be interpreted as a list of directories.
+Directories should come by pairs, indicating a mapping directive.
</span> Entries are separated
by a <code>:</code> (colon) on Unix platforms (including cygwin),
by a <code>;</code> (semicolon) on other platforms (mainly, Windows).
<span style="color: #000000;background-color: #ffdddd">-
- <p>The magic empty entry,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The magic empty entry,
</span> if it comes in what would otherwise be the first entry in a pair,
<span style="color: #000000;background-color: #ffdddd">-indicates the splicing of inherited configuration.
</span><span style="color: #000000;background-color: #ddffdd">+indicates the splicing of inherited configuration.
</span> If it comes as the second entry in a pair,
it indicates that the directory specified first is to be left untranslated
(which has the same effect as if the directory had been repeated).
<span style="color: #000000;background-color: #ffdddd">-
-<h3 class="section">8.6 Semantics of Output Translations</h3>
</span><span style="color: #000000;background-color: #ddffdd">+Thus <code>"/foo:/bar::/baz:"</code> means that
+things under directory <samp>/foo/</samp>
+are translated to be under <samp>/bar/</samp>,
+then include the inherited configuration,
+then specify that things under directory <samp>/baz/</samp> are not translated.
+</p>
+<hr>
+<a name="Semantics-of-Output-Translations"></a>
+<a name="Semantics-of-Output-Translations-1"></a>
+<h3 class="section">9.6 Semantics of Output Translations</h3>
</span>
<p>From the specified configuration,
a list of mappings is extracted in a straightforward way:
mappings are collected in order, recursing through
<span style="color: #000000;background-color: #ffdddd">-included or inherited configuration as specified.
</span><span style="color: #000000;background-color: #ddffdd">+included or inherited configuration as specified.
</span> To this list is prepended some implementation-specific mappings,
and is appended a global default.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The list is then compiled to a mapping table as follows:
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The list is then compiled to a mapping table as follows:
</span> for each entry, in order, resolve the first designated directory
<span style="color: #000000;background-color: #ffdddd">-into an actual directory pathname for source locations.
</span><span style="color: #000000;background-color: #ddffdd">+into an actual directory pathname for source locations.
</span> If no mapping was specified yet for that location,
resolve the second designated directory to an output location directory
add a mapping to the table mapping the source location to the output location,
and add another mapping from the output location to itself
(unless a mapping already exists for the output location).
<span style="color: #000000;background-color: #ffdddd">-
- <p>Based on the table, a mapping function is defined,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Based on the table, a mapping function is defined,
</span> mapping source pathnames to output pathnames:
given a source pathname, locate the longest matching prefix
<span style="color: #000000;background-color: #ffdddd">-in the source column of the mapping table.
</span><span style="color: #000000;background-color: #ddffdd">+in the source column of the mapping table.
</span> Replace that prefix by the corresponding output column
<span style="color: #000000;background-color: #ffdddd">-in the same row of the table, and return the result.
-If no match is found, return the source pathname.
</span><span style="color: #000000;background-color: #ddffdd">+in the same row of the table, and return the result.
+If no match is found, return the source pathname.
</span> (A global default mapping the filesystem root to itself
may ensure that there will always be a match,
with same fall-through semantics).
<span style="color: #000000;background-color: #ffdddd">-
-<h3 class="section">8.7 Caching Results</h3>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Output-Caching-Results"></a>
+<a name="Caching-Results-2"></a>
+<h3 class="section">9.7 Caching Results</h3>
</span>
<p>The implementation is allowed to either eagerly compute the information
from the configurations and file system, or to lazily re-compute it
<span style="color: #000000;background-color: #ffdddd">-every time, or to cache any part of it as it goes.
</span><span style="color: #000000;background-color: #ddffdd">+every time, or to cache any part of it as it goes.
</span> To explicitly flush any information cached by the system, use the API below.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">8.8 Output location API</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Output-location-API"></a>
+<a name="Output-location-API-1"></a>
+<h3 class="section">9.8 Output location API</h3>
</span>
<p>The specified functions are exported from package ASDF.
<span style="color: #000000;background-color: #ffdddd">-
-<div class="defun">
-— Function: <b>initialize-output-translations</b><var> &optional PARAMETER<a name="index-initialize_002doutput_002dtranslations-60"></a></var><br>
-<blockquote><p> will read the configuration and initialize all internal variables.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<dl>
+<dt><a name="index-initialize_002doutput_002dtranslations"></a>Function: <strong>initialize-output-translations</strong> <em>&optional PARAMETER</em></dt>
+<dd><p>will read the configuration and initialize all internal variables.
</span> You may extend or override configuration
from the environment and configuration files
with the given <var>PARAMETER</var>, which can be
<span style="color: #aaaaaa">@@ -3104,159 +3996,162 @@ To explicitly flush any information cached by the system, use the API below.
</span> or a SEXP (in the SEXP DSL),
a string (as in the string DSL),
a pathname (of a file or directory with configuration),
<span style="color: #000000;background-color: #ffdddd">- or a symbol (fbound to function that when called returns one of the above).
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+ or a symbol (fbound to function that when called returns one of the above).
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<div class="defun">
-— Function: <b>disable-output-translations</b><var><a name="index-disable_002doutput_002dtranslations-61"></a></var><br>
-<blockquote><p> will initialize output translations in a way
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-disable_002doutput_002dtranslations"></a>Function: <strong>disable-output-translations</strong></dt>
+<dd><p>will initialize output translations in a way
</span> that maps every pathname to itself,
<span style="color: #000000;background-color: #ffdddd">- effectively disabling the output translation facility.
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+ effectively disabling the output translation facility.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<div class="defun">
-— Function: <b>clear-output-translations</b><var><a name="index-clear_002doutput_002dtranslations-62"></a></var><br>
-<blockquote><p> undoes any output translation configuration
- and clears any cache for the mapping algorithm.
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-clear_002doutput_002dtranslations-1"></a>Function: <strong>clear-output-translations</strong></dt>
+<dd><p>undoes any output translation configuration
+ and clears any cache for the mapping algorithm.
</span> You might want to call this function
(or better, <code>clear-configuration</code>)
before you dump an image that would be resumed
with a different configuration,
<span style="color: #000000;background-color: #ffdddd">- and return an empty configuration.
</span><span style="color: #000000;background-color: #ddffdd">+ and return an empty configuration.
</span> Note that this does not include clearing information about
systems defined in the current image, only about
<span style="color: #000000;background-color: #ffdddd">- where to look for systems not yet defined.
-</p></blockquote></div>
-
-<div class="defun">
-— Function: <b>ensure-output-translations</b><var> &optional PARAMETER<a name="index-ensure_002doutput_002dtranslations-63"></a></var><br>
-<blockquote><p> checks whether output translations have been initialized.
- If not, initialize them with the given <var>PARAMETER</var>.
- This function will be called before any attempt to operate on a system.
-</p></blockquote></div>
-
-<div class="defun">
-— Function: <b>apply-output-translations</b><var> PATHNAME<a name="index-apply_002doutput_002dtranslations-64"></a></var><br>
-<blockquote><p> Applies the configured output location translations to <var>PATHNAME</var>
- (calls <code>ensure-output-translations</code> for the translations).
-</p></blockquote></div>
-
- <p>Every time you use ASDF's <code>output-files</code>, or
</span><span style="color: #000000;background-color: #ddffdd">+ where to look for systems not yet defined.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-ensure_002doutput_002dtranslations"></a>Function: <strong>ensure-output-translations</strong> <em>&optional PARAMETER</em></dt>
+<dd><p>checks whether output translations have been initialized.
+ If not, initialize them with the given <var>PARAMETER</var>.
+ This function will be called before any attempt to operate on a system.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-apply_002doutput_002dtranslations"></a>Function: <strong>apply-output-translations</strong> <em>PATHNAME</em></dt>
+<dd><p>Applies the configured output location translations to <var>PATHNAME</var>
+ (calls <code>ensure-output-translations</code> for the translations).
+</p></dd></dl>
+
+<p>Every time you use ASDF’s <code>output-files</code>, or
</span> anything that uses it (that may compile, such as <code>operate</code>, <code>perform</code>, etc.),
<code>ensure-output-translations</code> is called with parameter <code>nil</code>,
<span style="color: #000000;background-color: #ffdddd">-which the first time around causes your configuration to be read.
</span><span style="color: #000000;background-color: #ddffdd">+which the first time around causes your configuration to be read.
</span> If you change a configuration file,
you need to explicitly <code>initialize-output-translations</code> again,
or maybe <code>clear-output-translations</code> (or <code>clear-configuration</code>),
which will cause the initialization to happen next time around.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">8.9 Credits for output translations</h3>
-
-<p>Thanks a lot to Bjorn Lindberg and Gary King for <code>ASDF-Binary-Locations</code>,
-and to Peter van Eynde for <code>Common Lisp Controller</code>.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Credits-for-output-translations"></a>
+<a name="Credits-for-output-translations-1"></a>
+<h3 class="section">9.9 Credits for output translations</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>All bad design ideas and implementation bugs are to mine, not theirs.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Thanks a lot to Peter van Eynde for <code>Common Lisp Controller</code>
+and to Bjorn Lindberg and Gary King for <code>ASDF-Binary-Locations</code>.
+</p>
+<p>All bad design ideas and implementation bugs are to mine, not theirs.
</span> But so are good design ideas and elegant implementation tricks.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>— Francois-Rene Rideau <a href="mailto:fare@tunes.org">fare@tunes.org</a>
+</p>
+
+
+
+
+
+
+
+<hr>
+<a name="Error-handling"></a>
+<a name="Error-handling-1"></a>
+<h2 class="chapter">10 Error handling</h2>
+<a name="index-SYSTEM_002dDEFINITION_002dERROR"></a>
+<a name="index-OPERATION_002dERROR"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>— Francois-Rene Rideau <a href="mailto:fare@tunes.org">fare@tunes.org</a>
-
-<!-- @section Default locations -->
-<!-- @findex output-files-for-system-and-operation -->
-<!-- The default binary location for each Lisp implementation -->
-<!-- is a subdirectory of each source directory. -->
-<!-- To account for different Lisps, Operating Systems, Implementation versions, -->
-<!-- and so on, ASDF borrows code from SLIME -->
-<!-- to create reasonable custom directory names. -->
-<!-- Here are some examples: -->
-<!-- @itemize -->
-<!-- @item -->
-<!-- SBCL, version 1.0.45 on Mac OS X for Intel: @code{sbcl-1.0.45-darwin-x86} -->
-<!-- @item -->
-<!-- Franz Allegro, version 8.0, ANSI Common Lisp: @code{allegro-8.0a-macosx-x86} -->
-<!-- @item -->
-<!-- Franz Allegro, version 8.1, Modern (case sensitive) Common Lisp: @code{allegro-8.1m-macosx-x86} -->
-<!-- @end itemize -->
-<!-- By default, all output file pathnames will be relocated -->
-<!-- to some thus-named subdirectory of @file{~/.cache/common-lisp/}. -->
-<!-- See the document @file{README.asdf-output-translations} -->
-<!-- for a full specification on how to configure @code{asdf-output-translations}. -->
-<p><a name="Error-handling"></a>
-
-<!-- node-name, next, previous, up -->
-<h2 class="chapter">9 Error handling</h2>
-
-<p><a name="index-SYSTEM_002dDEFINITION_002dERROR-65"></a><a name="index-OPERATION_002dERROR-66"></a>
-
-<h3 class="section">9.1 ASDF errors</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<a name="ASDF-errors"></a>
+<h3 class="section">10.1 ASDF errors</h3>
</span>
<p>If ASDF detects an incorrect system definition, it will signal a generalised instance of
<code>SYSTEM-DEFINITION-ERROR</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Operations may go wrong (for example when source files contain errors).
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Operations may go wrong (for example when source files contain errors).
</span> These are signalled using generalised instances of
<code>OPERATION-ERROR</code>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="Compilation-error-and-warning-handling"></a>
+<h3 class="section">10.2 Compilation error and warning handling</h3>
+<a name="index-_002acompile_002dfile_002dwarnings_002dbehaviour_002a"></a>
+<a name="index-_002acompile_002dfile_002dfailure_002dbehaviour_002a"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">9.2 Compilation error and warning handling</h3>
-
-<p><a name="index-g_t_002acompile_002dfile_002dwarnings_002dbehaviour_002a-67"></a><a name="index-g_t_002acompile_002dfile_002derrors_002dbehavior_002a-68"></a>
-ASDF checks for warnings and errors when a file is compiled.
</span><span style="color: #000000;background-color: #ddffdd">+<p>ASDF checks for warnings and errors when a file is compiled.
</span> The variables <var>*compile-file-warnings-behaviour*</var> and
<span style="color: #000000;background-color: #ffdddd">-<var>*compile-file-errors-behavior*</var>
-control the handling of any such events.
</span><span style="color: #000000;background-color: #ddffdd">+<var>*compile-file-failure-behaviour*</var>
+control the handling of any such events.
</span> The valid values for these variables are
<code>:error</code>, <code>:warn</code>, and <code>:ignore</code>.
<span style="color: #000000;background-color: #ffdddd">-
-<p><a name="Miscellaneous-additional-functionality"></a>
-
-<!-- node-name, next, previous, up -->
-<h2 class="chapter">10 Miscellaneous additional functionality</h2>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Miscellaneous-additional-functionality"></a>
+<a name="Miscellaneous-additional-functionality-1"></a>
+<h2 class="chapter">11 Miscellaneous additional functionality</h2>
</span>
<p>ASDF includes several additional features that are generally
useful for system definition and development.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">10.1 Controlling file compilation</h3>
-
-<p><a name="index-g_t_003aaround_002dcompile-69"></a><a name="index-around_002dcompile-keyword-70"></a><a name="index-compile_002dcheck-keyword-71"></a><a name="index-g_t_003acompile_002dcheck-72"></a><a name="index-compile_002dfile_002a-73"></a>
-When declaring a component (system, module, file),
-you can specify a keyword argument <code>:around-compile function</code>.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Controlling-file-compilation"></a>
+<a name="Controlling-file-compilation-1"></a>
+<h3 class="section">11.1 Controlling file compilation</h3>
+<a name="index-_003aaround_002dcompile"></a>
+<a name="index-around_002dcompile-keyword"></a>
+<a name="index-compile_002dcheck-keyword"></a>
+<a name="index-_003acompile_002dcheck"></a>
+<a name="index-compile_002dfile_002a"></a>
+
+
+<p>When declaring a component (system, module, file),
+you can specify a keyword argument <code>:around-compile function</code>.
</span> If left unspecified (and therefore unbound),
the value will be inherited from the parent component if any,
or with a default of <code>nil</code>
if no value is specified in any transitive parent.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The argument must be a either <code>nil</code>, a fbound symbol,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The argument must be either <code>nil</code>, an fbound symbol,
</span> a lambda-expression (e.g. <code>(lambda (thunk) ...(funcall thunk ...) ...)</code>)
<span style="color: #000000;background-color: #ffdddd">-a function object (e.g. using <code>#.#'</code> but that's discouraged
</span><span style="color: #000000;background-color: #ddffdd">+a function object (e.g. using <code>#.#'</code> but that’s discouraged
</span> because it prevents the introspection done by e.g. asdf-dependency-grovel),
<span style="color: #000000;background-color: #ffdddd">-or a string that when <code>read</code> yields a symbol or a lambda-expression.
-<code>nil</code> means the normal compile-file function will be called.
</span><span style="color: #000000;background-color: #ddffdd">+or a string that when <code>read</code> yields a symbol or a lambda-expression.
+<code>nil</code> means the normal compile-file function will be called.
</span> A non-nil value designates a function of one argument
that will be called with a function that will
invoke <code>compile-file*</code> with various arguments;
the around-compile hook may supply additional keyword arguments
to pass to that call to <code>compile-file*</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>One notable argument that is heeded by <code>compile-file*</code> is
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>One notable argument that is heeded by <code>compile-file*</code> is
</span> <code>:compile-check</code>,
a function called when the compilation was otherwise a success,
with the same arguments as <code>compile-file</code>;
the function shall return true if the compilation
and its resulting compiled file respected all system-specific invariants,
and false (<code>nil</code>) if it broke any of those invariants;
<span style="color: #000000;background-color: #ffdddd">-it may issue warnings or errors before it returns <code>nil</code>.
</span><span style="color: #000000;background-color: #ddffdd">+it may issue warnings or errors before it returns <code>nil</code>.
</span> (NB: The ability to pass such extra flags
<span style="color: #000000;background-color: #ffdddd">-is only available starting with ASDF 2.22.3.)
</span><span style="color: #000000;background-color: #ddffdd">+is only available starting with ASDF 2.22.3.)
</span> This feature is notably exercised by asdf-finalizers.
<span style="color: #000000;background-color: #ffdddd">-
- <p>By using a string, you may reference
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>By using a string, you may reference
</span> a function, symbol and/or package
that will only be created later during the build, but
<span style="color: #000000;background-color: #ffdddd">-isn't yet present at the time the defsystem form is evaluated.
</span><span style="color: #000000;background-color: #ddffdd">+isn’t yet present at the time the defsystem form is evaluated.
</span> However, if your entire system is using such a hook, you may have to
explicitly override the hook with <code>nil</code> for all the modules and files
that are compiled before the hook is defined.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Using this hook, you may achieve such effects as:
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Using this hook, you may achieve such effects as:
</span> locally renaming packages,
binding <var>*readtables*</var> and other syntax-controlling variables,
handling warnings and other conditions,
<span style="color: #aaaaaa">@@ -3267,1395 +4162,2201 @@ setting gensym counters and PRNG seeds and other sources of non-determinism,
</span> overriding the source-location and/or timestamping systems,
checking that some compile-time side-effects were properly balanced,
etc.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Note that there is no around-load hook. This is on purpose.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that there is no around-load hook. This is on purpose.
</span> Some implementations such as ECL, GCL or MKCL link object files,
<span style="color: #000000;background-color: #ffdddd">-which allows for no such hook.
</span><span style="color: #000000;background-color: #ddffdd">+which allows for no such hook.
</span> Other implementations allow for concatenating FASL files,
<span style="color: #000000;background-color: #ffdddd">-which doesn't allow for such a hook either.
-We aim to discourage something that's not portable,
</span><span style="color: #000000;background-color: #ddffdd">+which doesn’t allow for such a hook either.
+We aim to discourage something that’s not portable,
</span> and has some dubious impact on performance and semantics
<span style="color: #000000;background-color: #ffdddd">-even when it is possible.
</span><span style="color: #000000;background-color: #ddffdd">+even when it is possible.
</span> Things you might want to do with an around-load hook
are better done around-compile,
though it may at times require some creativity
(see e.g. the <code>package-renaming</code> system).
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">10.2 Controlling source file character encoding</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Controlling-source-file-character-encoding"></a>
+<a name="Controlling-source-file-character-encoding-1"></a>
+<h3 class="section">11.2 Controlling source file character encoding</h3>
</span>
<p>Starting with ASDF 2.21, components accept a <code>:encoding</code> option
so authors may specify which character encoding should be used
<span style="color: #000000;background-color: #ffdddd">-to read and evaluate their source code.
</span><span style="color: #000000;background-color: #ddffdd">+to read and evaluate their source code.
</span> When left unspecified, the encoding is inherited
from the parent module or system;
if no encoding is specified at any point,
<span style="color: #000000;background-color: #ffdddd">-the default <code>:autodetect</code> is assumed.
-By default, only <code>:default</code>, <code>:utf-8</code>
-and <code>:autodetect</code> are accepted.
-<code>:autodetect</code>, the default, calls
-<code>*encoding-detection-hook*</code> which by default always returns
-<code>*default-encoding*</code> which itself defaults to <code>:default</code>.
-
- <p>In other words, there now are plenty of extension hooks, but
-by default ASDF follows the backwards compatible behavior
-of using whichever <code>:default</code> encoding your implementation uses,
-which itself may or may not vary based on environment variables
-and other locale settings.
-In practice this means that only source code that only uses ASCII
-is guaranteed to be read the same on all implementations
-independently from any user setting.
-
- <p>Additionally, for backward-compatibility with older versions of ASDF
-and/or with implementations that do not support unicode and its many encodings,
-you may want to use
-the reader conditionals <code>#+asdf-unicode #+asdf-unicode</code>
-to protect any <code>:encoding </code><em>encoding</em> statement
-as <code>:asdf-unicode</code> will be present in <code>*features*</code>
-only if you're using a recent ASDF
-on an implementation that supports unicode.
</span><span style="color: #000000;background-color: #ddffdd">+or if <code>nil</code> is explicitly specified,
+an extensible protocol described below is followed,
+that ultimately defaults to <code>:utf-8</code> since ASDF 3.
+</p>
+<p>The protocol to determine the encoding is
+to call the function <code>detect-encoding</code>,
+which itself, if provided a valid file,
+calls the function specified by <var>*encoding-detection-hook*</var>,
+or else defaults to the <var>*default-encoding*</var>.
+The <var>*encoding-detection-hook*</var> is by default bound
+to function <code>always-default-encoding</code>,
+that always returns the contents of <var>*default-encoding*</var>.
+<var>*default-encoding*</var> is bound to <code>:utf-8</code> by default
+(before ASDF 3, the default was <code>:default</code>).
+</p>
+<p>Whichever encoding is returned must be a portable keyword,
+that will be translated to an implementation-specific external-format designator
+by function <code>encoding-external-format</code>,
+which itself simply calls the function specified <var>*encoding-external-format-hook*</var>;
+that function by default is <code>default-encoding-external-format</code>,
+that only recognizes <code>:utf-8</code> and <code>:default</code>,
+and translates the former to the implementation-dependent <var>*utf-8-external-format*</var>,
+and the latter to itself (that itself is portable but has an implementation-dependent meaning).
+</p>
+<p>In other words, there now are plenty of extension hooks, but
+by default ASDF enforces the previous <em>de facto</em> standard behaviour
+of using <code>:utf-8</code>, independently from
+whatever configuration the user may be using.
+Thus, system authors can now rely on <code>:utf-8</code>
+being used while compiling their files,
+even if the user is currently using <code>:koi8-r</code> or <code>:euc-jp</code>
+as their interactive encoding.
+(Before ASDF 3, there was no such guarantee, <code>:default</code> was used,
+and only plain ASCII was safe to include in source code.)
+</p>
+<p>Some legacy implementations only support 8-bit characters,
+and some implementations provide 8-bit only variants.
+On these implementations, the <var>*utf-8-external-format*</var>
+gracefully falls back to <code>:default</code>,
+and Unicode characters will be read as multi-character mojibake.
+To detect such situations, UIOP will push the <code>:asdf-unicode</code> feature
+on implementations that support Unicode, and you can use reader-conditionalization
+to protect any <code>:encoding <em>encoding</em></code> statement, as in
+<code>#+asdf-unicode :encoding #+asdf-unicode :utf-8</code>.
</span> We recommend that you avoid using unprotected <code>:encoding</code> specifications
<span style="color: #000000;background-color: #ffdddd">-until after ASDF 2.21 or later becomes widespread, hopefully by the end of 2012.
-
- <p>While it offers plenty of hooks for extension,
-and one such extension is being developed (see below),
</span><span style="color: #000000;background-color: #ddffdd">+until after ASDF 2.21 or later becomes widespread.
+As of May 2015, all maintained implementations provide ASDF 3,
+so you may prudently start using this and other features without such protection.
+</p>
+<p>While it offers plenty of hooks for extension,
+and one such extension is available (see <code>asdf-encodings</code> below),
</span> ASDF itself only recognizes one encoding beside <code>:default</code>,
and that is <code>:utf-8</code>, which is the <em>de facto</em> standard,
<span style="color: #000000;background-color: #ffdddd">-already used by the vast majority of libraries that use more than ASCII.
</span><span style="color: #000000;background-color: #ddffdd">+already used by the vast majority of libraries that use more than ASCII.
</span> On implementations that do not support unicode,
the feature <code>:asdf-unicode</code> is absent, and
the <code>:default</code> external-format is used
<span style="color: #000000;background-color: #ffdddd">-to read even source files declared as <code>:utf-8</code>.
</span><span style="color: #000000;background-color: #ddffdd">+to read even source files declared as <code>:utf-8</code>.
</span> On these implementations, non-ASCII characters
intended to be read as one CL character
<span style="color: #000000;background-color: #ffdddd">-may thus end up being read as multiple CL characters.
-In most cases, this shouldn't affect the software's semantics:
</span><span style="color: #000000;background-color: #ddffdd">+may thus end up being read as multiple CL characters.
+In most cases, this shouldn’t affect the software’s semantics:
</span> comments will be skipped just the same, strings with be read and printed
with slightly different lengths, symbol names will be accordingly longer,
<span style="color: #000000;background-color: #ffdddd">-but none of it should matter.
</span><span style="color: #000000;background-color: #ddffdd">+but none of it should matter.
</span> But a few systems that actually depend on unicode characters
<span style="color: #000000;background-color: #ffdddd">-may fail to work properly, or may work in a subtly different way.
</span><span style="color: #000000;background-color: #ddffdd">+may fail to work properly, or may work in a subtly different way.
</span> See for instance <code>lambda-reader</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>We invite you to embrace UTF-8
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>We invite you to embrace UTF-8
</span> as the encoding for non-ASCII characters starting today,
<span style="color: #000000;background-color: #ffdddd">-even without any explicit specification in your <code>.asd</code> files.
</span><span style="color: #000000;background-color: #ddffdd">+even without any explicit specification in your <samp>.asd</samp> files.
</span> Indeed, on some implementations and configurations,
UTF-8 is already the <code>:default</code>,
<span style="color: #000000;background-color: #ffdddd">-and loading your code may cause errors if it is encoded in anything but UTF-8.
-Therefore, even with the legacy behavior,
</span><span style="color: #000000;background-color: #ddffdd">+and loading your code may cause errors if it is encoded in anything but UTF-8.
+Therefore, even with the legacy behaviour,
</span> non-UTF-8 is guaranteed to break for some users,
whereas UTF-8 is pretty much guaranteed not to break anywhere
(provided you do <em>not</em> use a BOM),
<span style="color: #000000;background-color: #ffdddd">-although it might be read incorrectly on some implementations.
-In the future, we intend to make <code>:utf-8</code>
-the default value of <code>*default-encoding*</code>,
-to be enforced everywhere, so at least the code is guaranteed
-to be read correctly everywhere it can be.
-
- <p>If you need non-standard character encodings for your source code,
</span><span style="color: #000000;background-color: #ddffdd">+although it might be read incorrectly on some implementations.
+<code>:utf-8</code> has been the default value of <code>*default-encoding*</code> since ASDF 3.
+</p>
+<p>If you need non-standard character encodings for your source code,
</span> use the extension system <code>asdf-encodings</code>, by specifying
<span style="color: #000000;background-color: #ffdddd">-<code>:defsystem-depends-on (:asdf-encodings)</code> in your <code>defsystem</code>.
</span><span style="color: #000000;background-color: #ddffdd">+<code>:defsystem-depends-on ("asdf-encodings")</code> in your <code>defsystem</code>.
</span> This extension system will register support for more encodings using the
<code>*encoding-external-format-hook*</code> facility,
so you can explicitly specify <code>:encoding :latin1</code>
<span style="color: #000000;background-color: #ffdddd">-in your <code>.asd</code> file.
</span><span style="color: #000000;background-color: #ddffdd">+in your <samp>.asd</samp> file.
</span> Using the <code>*encoding-detection-hook*</code> it will also
<span style="color: #000000;background-color: #ffdddd">-eventually implement some autodetection of a file's encoding
</span><span style="color: #000000;background-color: #ddffdd">+eventually implement some autodetection of a file’s encoding
</span> from an emacs-style <code>-*- mode: lisp ; coding: latin1 -*-</code> declaration,
<span style="color: #000000;background-color: #ffdddd">-or otherwise based on an analysis of octet patterns in the file.
-At this point, asdf-encoding only supports the encodings
-that are supported as part of your implementation.
</span><span style="color: #000000;background-color: #ddffdd">+or otherwise based on an analysis of octet patterns in the file.
+At this point, <code>asdf-encoding</code> only supports the encodings
+that are supported as part of your implementation.
</span> Since the list varies depending on implementations,
<span style="color: #000000;background-color: #ffdddd">-we once again recommend you use <code>:utf-8</code> everywhere,
-which is the most portable (next is <code>:latin1</code>).
-
- <p>If you're not using a version of Quicklisp that has it,
-you may get the source for <code>asdf-encodings</code> using git:
-<kbd>git clone git://common-lisp.net/projects/asdf/asdf-encodings.git</kbd>
</span><span style="color: #000000;background-color: #ddffdd">+we still recommend you use <code>:utf-8</code> everywhere,
+which is the most portable (next to it is <code>:latin1</code>).
+</p>
+<p>Recent versions of Quicklisp include <code>asdf-encodings</code>;
+if you’re not using it, you may get this extension using git:
+<kbd>git clone https://gitlab.common-lisp.net/asdf/asdf-encodings.git</kbd>
</span> or
<span style="color: #000000;background-color: #ffdddd">-<kbd>git clone ssh://common-lisp.net/project/asdf/git/asdf-encodings.git</kbd>.
</span><span style="color: #000000;background-color: #ddffdd">+<kbd>git clone git@gitlab.common-lisp.net:asdf/asdf-encodings.git</kbd>.
</span> You can also browse the repository on
<span style="color: #000000;background-color: #ffdddd">-<a href="http://common-lisp.net/gitweb?p=projects/asdf/asdf-encodings.git">http://common-lisp.net/gitweb?p=projects/asdf/asdf-encodings.git</a>.
-
- <p>In the future, we intend to change the default <code>*default-encoding*</code>
-to <code>:utf-8</code>, which is already the de facto standard
-for most libraries that use non-ASCII characters:
-utf-8 works everywhere and was backhandedly enforced by
-a lot of people using SBCL and utf-8 and sending reports to authors
-so they make their packages compatible.
-A survey showed only about a handful few libraries
-are incompatible with non-UTF-8, and then, only in comments,
-and we believe that authors will adopt UTF-8 when prompted.
-See the April 2012 discussion on the asdf-devel mailing-list.
-For backwards compatibility with users who insist on a non-UTF-8 encoding,
-but cannot immediately transition to using <code>asdf-encodings</code>
-(maybe because it isn't ready), it will still be possible to use
-the <code>:encoding :default</code> option in your <code>defsystem</code> form
-to restore the behavior of ASDF 2.20 and earlier.
-This shouldn't be required in libraries,
-because user pressure as mentioned above will already have pushed
-library authors towards using UTF-8;
-but authors of end-user programs might care.
-
- <p>When you use <code>asdf-encodings</code>, any further loaded <code>.asd</code> file
-will use the autodetection algorithm to determine its encoding;
-yet if you depend on this detection happening,
-you may want to explicitly load <code>asdf-encodings</code> early in your build,
-for by the time you can use <code>:defsystem-depends-on</code>,
-it is already too late to load it.
-In practice, this means that the <code>*default-encoding*</code>
-is usually used for <code>.asd</code> files.
-Currently, this defaults to <code>:default</code> for backwards compatibility,
-and that means that you shouldn't rely on non-ASCII characters in a .asd file.
-Since component (path)names are the only real data in these files,
-and non-ASCII characters are not very portable for file names,
-this isn't too much of an issue.
-We still encourage you to use either plain ASCII or UTF-8
-in <code>.asd</code> files,
-as we intend to make <code>:utf-8</code> the default encoding in the future.
-This might matter, for instance, in meta-data about author's names.
-
-<h3 class="section">10.3 Miscellaneous Functions</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<a href="https://gitlab.common-lisp.net/asdf/asdf-encodings">https://gitlab.common-lisp.net/asdf/asdf-encodings</a>.
+</p>
+<p>When you use <code>asdf-encodings</code>,
+any <samp>.asd</samp> file loaded
+will use the autodetection algorithm to determine its encoding.
+If you depend on this detection happening,
+you should explicitly load <code>asdf-encodings</code> early in your build.
+Note that <code>:defsystem-depends-on</code> cannot be used here: by the time
+the <code>:defsystem-depends-on</code> is loaded, the enclosing
+<code>defsystem</code> form has already been read.
+</p>
+<p>In practice, this means that the <code>*default-encoding*</code>
+is usually used for <samp>.asd</samp> files.
+Currently, this defaults to <code>:utf-8</code>, and
+you should be safe using Unicode characters in those files.
+This might matter, for instance, in meta-data about author’s names.
+Otherwise, the main data in these files is component (path)names,
+and we don’t recommend using non-ASCII characters for these,
+for the result probably isn’t very portable.
+</p>
+<hr>
+<a name="Miscellaneous-Functions"></a>
+<a name="Miscellaneous-Functions-1"></a>
+<h3 class="section">11.3 Miscellaneous Functions</h3>
</span>
<p>These functions are exported by ASDF for your convenience.
<span style="color: #000000;background-color: #ffdddd">-
-<div class="defun">
-— Function: <b>system-relative-pathname</b><var> system name &key type<a name="index-system_002drelative_002dpathname-74"></a></var><br>
-<blockquote>
- <p>It's often handy to locate a file relative to some system.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="system_002drelative_002dpathname"></a><dl>
+<dt><a name="index-system_002drelative_002dpathname"></a>Function: <strong>system-relative-pathname</strong> <em>system name &key type</em></dt>
+<dd>
+<p>It’s often handy to locate a file relative to some system.
</span> The <code>system-relative-pathname</code> function meets this need.
<span style="color: #000000;background-color: #ffdddd">-
- <p>It takes two mandatory arguments <var>system</var> and <var>name</var>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>It takes two mandatory arguments <var>system</var> and <var>name</var>
</span> and a keyword argument <var>type</var>:
<var>system</var> is name of a system, whereas <var>name</var> and optionally <var>type</var>
specify a relative pathname, interpreted like a component pathname specifier
by <code>coerce-pathname</code>. See <a href="#The-defsystem-grammar">Pathname specifiers</a>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>It returns a pathname built from the location of the system's
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>It returns a pathname built from the location of the system’s
</span> source directory and the relative pathname. For example:
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">> (asdf:system-relative-pathname 'cl-ppcre "regex.data")
+#P"/repository/other/cl-ppcre/regex.data"
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">- <pre class="lisp"> > (asdf:system-relative-pathname 'cl-ppcre "regex.data")
- #P"/repository/other/cl-ppcre/regex.data"
-</pre>
- </blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+</dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<div class="defun">
-— Function: <b>system-source-directory</b><var> system-designator<a name="index-system_002dsource_002ddirectory-75"></a></var><br>
-<blockquote>
- <p>ASDF does not provide a turnkey solution for locating
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-system_002dsource_002ddirectory"></a>Function: <strong>system-source-directory</strong> <em>system-designator</em></dt>
+<dd>
+<p>ASDF does not provide a turnkey solution for locating
</span> data (or other miscellaneous) files
<span style="color: #000000;background-color: #ffdddd">-that are distributed together with the source code of a system.
-Programmers can use <code>system-source-directory</code> to find such files.
-Returns a pathname object.
-The <var>system-designator</var> may be a string, symbol, or ASDF system object.
-</p></blockquote></div>
-
-<div class="defun">
-— Function: <b>clear-system</b><var> system-designator<a name="index-clear_002dsystem-76"></a></var><br>
-<blockquote>
- <p>It is sometimes useful to force recompilation of a previously loaded system.
-In these cases, it may be useful to <code>(asdf:clear-system :foo)</code>
-to remove the system from the table of currently loaded systems;
</span><span style="color: #000000;background-color: #ddffdd">+that are distributed together with the source code of a system.
+Programmers can use <code>system-source-directory</code> to find such files.
+Returns a pathname object.
+The <var>system-designator</var> may be a string, symbol, or ASDF system object.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-clear_002dsystem"></a>Function: <strong>clear-system</strong> <em>system-designator</em></dt>
+<dd>
+<p>It is sometimes useful to force recompilation of a previously loaded system.
+For these cases, <code>(asdf:clear-system :foo)</code>
+will remove the system from the table of currently loaded systems:
</span> the next time the system <code>foo</code> or one that depends on it is re-loaded,
<span style="color: #000000;background-color: #ffdddd">-<code>foo</code> will then be loaded again.
-Alternatively, you could touch <code>foo.asd</code> or
-remove the corresponding fasls from the output file cache.
-(It was once conceived that one should provide
-a list of systems the recompilation of which to force
-as the <code>:force</code> keyword argument to <code>load-system</code>;
-but this has never worked, and though the feature was fixed in ASDF 2.000,
-it remains <code>cerror</code>'ed out as nobody ever used it.)
-
- <p>Note that this does not and cannot by itself undo the previous loading
-of the system. Common Lisp has no provision for such an operation,
-and its reliance on irreversible side-effects to global datastructures
-makes such a thing impossible in the general case.
</span><span style="color: #000000;background-color: #ddffdd">+<code>foo</code> will be loaded again.<a name="DOCF16" href="#FOOT16"><sup>16</sup></a>
+</p>
+<p>Note that this does not and cannot undo
+the previous loading of the system.
+Common Lisp has no provision for such an operation,
+and its reliance on irreversible side-effects to global data structures
+makes such a thing impossible in the general case.
</span> If the software being re-loaded is not conceived with hot upgrade in mind,
<span style="color: #000000;background-color: #ffdddd">-this re-loading may cause many errors, warnings or subtle silent problems,
-as packages, generic function signatures, structures, types, macros, constants, etc.
-are being redefined incompatibly.
-It is up to the user to make sure that reloading is possible and has the desired effect.
</span><span style="color: #000000;background-color: #ddffdd">+re-loading may cause many errors, warnings or subtle silent problems,
+as packages, generic function signatures, structures, types, macros, constants, etc.
+are being redefined incompatibly.
+It is up to the user to make sure that reloading is possible and has the desired effect.
</span> In some cases, extreme measures such as recursively deleting packages,
unregistering symbols, defining methods on <code>update-instance-for-redefined-class</code>
<span style="color: #000000;background-color: #ffdddd">-and much more are necessary for reloading to happen smoothly.
-ASDF itself goes through notable pains to make such a hot upgrade possible
-with respect to its own code, and what it does is ridiculously complex;
-look at the beginning of <samp><span class="file">asdf.lisp</span></samp> to see what it does.
-</p></blockquote></div>
-
-<div class="defun">
-— Function: <b>register-preloaded-system</b><var> name &rest keys<a name="index-register_002dpreloaded_002dsystem-77"></a></var><br>
-<blockquote><p>A system with name <var>name</var>,
</span><span style="color: #000000;background-color: #ddffdd">+and much more are necessary for reloading to happen smoothly.
+ASDF itself goes to extensive effort to make a hot upgrade possible
+with respect to its own code.
+If you want, you can reuse some of its utilities such as
+<code>uiop:define-package</code> and <code>uiop:with-upgradability</code>,
+and get inspiration (or disinspiration)
+from what it does in <samp>header.lisp</samp> and <samp>upgrade.lisp</samp>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-register_002dpreloaded_002dsystem"></a>Function: <strong>register-preloaded-system</strong> <em>name &rest keys</em></dt>
+<dd><p>A system with name <var>name</var>,
</span> created by <code>make-instance</code> with extra keys <var>keys</var>
(e.g. <code>:version</code>),
<span style="color: #000000;background-color: #ffdddd">-is registered as <em>preloaded</em>.
</span><span style="color: #000000;background-color: #ddffdd">+is registered as <em>preloaded</em>.
</span> That is, its code has already been loaded into the current image,
and if at some point some other system <code>:depends-on</code> it yet no source code is found,
it is considered as already provided,
and ASDF will not raise a <code>missing-component</code> error.
<span style="color: #000000;background-color: #ffdddd">-
- <p>This function is particularly useful if you distribute your code
-as fasls with either <code>fasl-op</code> or <code>monolithic-fasl-op</code>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>This function is particularly useful if you distribute your code
+as fasls with either <code>compile-bundle-op</code> or <code>monolithic-compile-bundle-op</code>,
</span> and want to register systems so that dependencies will work uniformly
<span style="color: #000000;background-color: #ffdddd">-whether you're using your software from source or from fasl.
-</p></blockquote></div>
-
-<div class="defun">
-— Function: <b>run-shell-command</b><var> control-string &rest args<a name="index-run_002dshell_002dcommand-78"></a></var><br>
-<blockquote>
- <p>This function is obsolete and present only for the sake of backwards-compatibility:
-“If it's not backwards, it's not compatible”. We <em>strongly</em> discourage its use.
-Its current behavior is only well-defined on Unix platforms
-(which include MacOS X and cygwin). On Windows, anything goes.
</span><span style="color: #000000;background-color: #ddffdd">+whether you’re using your software from source or from fasl.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-register_002dimmutable_002dsystem-1"></a>Function: <strong>register-immutable-system</strong> <em>name &rest keys</em></dt>
+<dd><p>A system with name <var>name</var>,
+created by <code>make-instance</code> with extra keys <var>keys</var>
+(e.g. <code>:version</code>),
+is registered as <em>immutable</em>.
+That is, its code has already been loaded into the current image,
+and if at some point some other system <code>:depends-on</code> it,
+it is considered as already provided, and
+no attempt will be made to search for an updated version from the source-registry
+or any other method.
+There will be no search for an <samp>.asd</samp> file, and no <code>missing-component</code> error.
+</p>
+<p>This function (available since ASDF 3.1.5) is particularly useful if
+you distribute a large body of code as a precompiled image,
+and want to allow users to extend the image with further extension systems,
+but without making thousands of filesystem requests looking for inexistent (or worse, out of date) source code
+for all the systems that came bundled with the image but aren’t
+distributed as source code to regular users.
+<a name="index-immutable-systems-1"></a>
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-run_002dshell_002dcommand"></a>Function: <strong>run-shell-command</strong> <em>control-string &rest args</em></dt>
+<dd>
+<p>This function is obsolete and present only for the sake of backwards-compatibility:
+“If it’s not backwards, it’s not compatible”. We <em>strongly</em> discourage its use.
+Its current behaviour is only well-defined on Unix platforms
+(which include MacOS X and cygwin). On Windows, anything goes.
</span> The following documentation is only for the purpose of your migrating away from it
in a way that preserves semantics.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Instead we recommend the use <code>run-program</code>, described in the next section, and
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Instead we recommend the use <code>run-program</code>, described in the next section, and
</span> available as part of ASDF since ASDF 3.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>run-shell-command</code> takes as arguments a format <code>control-string</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>run-shell-command</code> takes as arguments a format <code>control-string</code>
</span> and arguments to be passed to <code>format</code> after this control-string
<span style="color: #000000;background-color: #ffdddd">-to produce a string.
</span><span style="color: #000000;background-color: #ddffdd">+to produce a string.
</span> This string is a command that will be evaluated with a POSIX shell if possible;
yet, on Windows, some implementations will use CMD.EXE,
while others (like SBCL) will make an attempt at invoking a POSIX shell
<span style="color: #000000;background-color: #ffdddd">-(and fail if it is not present).
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+(and fail if it is not present).
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">10.4 Some Utility Functions</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Some-Utility-Functions"></a>
+<a name="Some-Utility-Functions-1"></a>
+<h3 class="section">11.4 Some Utility Functions</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>The below functions are not exported by ASDF itself, but by UIOP, available since ASDF 3.
</span><span style="color: #000000;background-color: #ddffdd">+<p>The below functions are not exported by ASDF itself, but by UIOP, available since ASDF 3.
</span> Some of them have precursors in ASDF 2, but we recommend
<span style="color: #000000;background-color: #ffdddd">-you rely on ASDF 3 for active developments.
</span><span style="color: #000000;background-color: #ddffdd">+you rely on ASDF 3 for active developments.
</span> UIOP provides many, many more utility functions, and we recommend
you read its README and sources for more information.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<div class="defun">
-— Function: <b>parse-unix-namestring</b><var> name &key type defaults dot-dot ensure-directory &allow-other-keys<a name="index-parse_002dunix_002dnamestring-79"></a></var><br>
-<blockquote><p>Coerce NAME into a PATHNAME using standard Unix syntax.
-
- <p>Unix syntax is used whether or not the underlying system is Unix;
-on such non-Unix systems it is only usable but for relative pathnames;
-but especially to manipulate relative pathnames portably, it is of crucial
-to possess a portable pathname syntax independent of the underlying OS.
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-parse_002dunix_002dnamestring"></a>Function: <strong>parse-unix-namestring</strong> <em>name &key type defaults dot-dot ensure-directory &allow-other-keys</em></dt>
+<dd><p>Coerce NAME into a PATHNAME using standard Unix syntax.
+</p>
+<p>Unix syntax is used whether or not the underlying system is Unix;
+on non-Unix systems it is only usable for relative pathnames.
+In order to manipulate relative pathnames portably, it is crucial
+to possess a portable pathname syntax independent of the underlying OS.
</span> This is what <code>parse-unix-namestring</code> provides, and why we use it in ASDF.
<span style="color: #000000;background-color: #ffdddd">-
- <p>When given a <code>pathname</code> object, just return it untouched.
-When given <code>nil</code>, just return <code>nil</code>.
-When given a non-null <code>symbol</code>, first downcase its name and treat it as a string.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>When given a <code>pathname</code> object, just return it untouched.
+When given <code>nil</code>, just return <code>nil</code>.
+When given a non-null <code>symbol</code>, first downcase its name and treat it as a string.
</span> When given a <code>string</code>, portably decompose it into a pathname as below.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>#\/</code> separates directory components.
-
- <p>The last <code>#\/</code>-separated substring is interpreted as follows:
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>#\/</code> separates directory components.
+</p>
+<p>The last <code>#\/</code>-separated substring is interpreted as follows:
</span> 1- If <var>type</var> is <code>:directory</code> or <var>ensure-directory</var> is true,
<span style="color: #000000;background-color: #ffdddd">- the string is made the last directory component, and its <code>name</code> and <code>type</code> are <code>nil</code>.
- if the string is empty, it's the empty pathname with all slots <code>nil</code>.
</span><span style="color: #000000;background-color: #ddffdd">+ the string is made the last directory component, and its <code>name</code> and <code>type</code> are <code>nil</code>.
+ if the string is empty, it’s the empty pathname with all slots <code>nil</code>.
</span> 2- If <var>type</var> is <code>nil</code>, the substring is a file-namestring,
<span style="color: #000000;background-color: #ffdddd">- and its <code>name</code> and <code>type</code> are separated by <code>split-name-type</code>.
</span><span style="color: #000000;background-color: #ddffdd">+ and its <code>name</code> and <code>type</code> are separated by <code>split-name-type</code>.
</span> 3- If <var>type</var> is a string, it is the given <code>type</code>, and the whole string is the <code>name</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Directory components with an empty name the name <code>.</code> are removed.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Directory components with an empty name the name <code>.</code> are removed.
</span> Any directory named <code>..</code> is read as <var>dot-dot</var>,
which must be one of <code>:back</code> or <code>:up</code> and defaults to <code>:back</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>host</code>, <code>device</code> and <code>version</code> components are taken from <var>defaults</var>,
-which itself defaults to <code>*nil-pathname*</code>, also used if <var>defaults</var> is <code>nil</code>.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<a name="index-_002anil_002dpathname_002a"></a>
+<p><code>host</code>, <code>device</code> and <code>version</code> components are taken from <var>defaults</var>,
+which itself defaults to <code>*nil-pathname*</code>.
+<code>*nil-pathname*</code> is also used if <var>defaults</var> is <code>nil</code>.
</span> No host or device can be specified in the string itself,
which makes it unsuitable for absolute pathnames outside Unix.
<span style="color: #000000;background-color: #ffdddd">-
- <p>For relative pathnames, these components (and hence the defaults) won't matter
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>For relative pathnames, these components (and hence the defaults) won’t matter
</span> if you use <code>merge-pathnames*</code> but will matter if you use <code>merge-pathnames</code>,
which is an important reason to always use <code>merge-pathnames*</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Arbitrary keys are accepted, and the parse result is passed to <code>ensure-pathname</code>
-with those keys, removing <var>type</var>, <var>defaults</var> and <var>dot-dot</var>.
-When you're manipulating pathnames that are supposed to make sense portably
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Arbitrary keys are accepted, and the parse result is passed to <code>ensure-pathname</code>
+with those keys, removing <var>type</var>, <var>defaults</var> and <var>dot-dot</var>.
+When you’re manipulating pathnames that are supposed to make sense portably
</span> even though the OS may not be Unixish, we recommend you use <code>:want-relative t</code>
<span style="color: #000000;background-color: #ffdddd">-to throw an error if the pathname is absolute
-</p></blockquote></div>
</span><span style="color: #000000;background-color: #ddffdd">+so that <code>parse-unix-namestring</code> will throw an error if the pathname is absolute.
+</p></dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">-<div class="defun">
-— Function: <b>merge-pathnames*</b><var> specified &optional defaults<a name="index-merge_002dpathnames_002a-80"></a></var><br>
-<blockquote>
- <p>This function is a replacement for <code>merge-pathnames</code> that uses the host and device
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-merge_002dpathnames_002a"></a>Function: <strong>merge-pathnames*</strong> <em>specified &optional defaults</em></dt>
+<dd>
+<p>This function is a replacement for <code>merge-pathnames</code> that uses the host and device
</span> from the <var>defaults</var> rather than the <var>specified</var> pathname when the latter
is a relative pathname. This allows ASDF and its users to create and use relative pathnames
without having to know beforehand what are the host and device
of the absolute pathnames they are relative to.
<span style="color: #000000;background-color: #ddffdd">+</p>
+</dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- </blockquote></div>
-
-<div class="defun">
-— Function: <b>subpathname</b><var> pathname subpath &key type<a name="index-subpathname-81"></a></var><br>
-<blockquote>
- <p>This function takes a <var>pathname</var> and a <var>subpath</var> and a <var>type</var>.
</span><span style="color: #000000;background-color: #ddffdd">+<dl>
+<dt><a name="index-subpathname"></a>Function: <strong>subpathname</strong> <em>pathname subpath &key type</em></dt>
+<dd>
+<p>This function takes a <var>pathname</var> and a <var>subpath</var> and a <var>type</var>.
</span> If <var>subpath</var> is already a <code>pathname</code> object (not namestring),
and is an absolute pathname at that, it is returned unchanged;
otherwise, <var>subpath</var> is turned into a relative pathname with given <var>type</var>
as per <code>parse-unix-namestring</code> with <code>:want-relative t :type </code><var>type</var>,
then it is merged with the <code>pathname-directory-pathname</code> of <var>pathname</var>,
as per <code>merge-pathnames*</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>We strongly encourage the use of this function
-for portably resolving relative pathnames in your code base.
-</p></blockquote></div>
-
-<div class="defun">
-— Function: <b>subpathname*</b><var> pathname subpath &key type<a name="index-subpathname_002a-82"></a></var><br>
-<blockquote>
- <p>This function returns <code>nil</code> if the base <var>pathname</var> is <code>nil</code>,
-otherwise acts like <code>subpathname</code>.
-</p></blockquote></div>
-
-<div class="defun">
-— Function: <b>run-program</b><var> command &key ignore-error-status force-shell input output error-output<a name="index-run_002dprogram-83"></a></var><br>
-<blockquote><p> if-input-does-not-exist if-output-exists if-error-output-exists
- element-type external-format &allow-other-keys
-
- <p><code>run-program</code> takes a <var>command</var> argument that is either
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>We strongly encourage the use of this function
+for portably resolving relative pathnames in your code base.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-subpathname_002a"></a>Function: <strong>subpathname*</strong> <em>pathname subpath &key type</em></dt>
+<dd>
+<p>This function returns <code>nil</code> if the base <var>pathname</var> is <code>nil</code>,
+otherwise acts like <code>subpathname</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-run_002dprogram"></a>Function: <strong>run-program</strong> <em>command &key ignore-error-status force-shell input output error-output if-input-does-not-exist if-output-exists if-error-output-exists element-type external-format &allow-other-keys</em></dt>
+<dd>
+<p><code>run-program</code> takes a <var>command</var> argument that is either
</span> a list of a program name or path and its arguments,
<span style="color: #000000;background-color: #ffdddd">-or a string to be executed by a shell.
</span><span style="color: #000000;background-color: #ddffdd">+or a string to be executed by a shell.
</span> It spawns the command, waits for it to return,
verifies that it exited cleanly (unless told not too below),
<span style="color: #000000;background-color: #ffdddd">-and optionally captures and processes its output.
-It accepts many keyword arguments to configure its behavior.
-
- <p><code>run-program</code> returns three values: the first for the output,
-the second for the error-output, and the third for the return value.
-(Beware that before ASDF 3.0.2.11, it didn't handle input or error-output,
</span><span style="color: #000000;background-color: #ddffdd">+and optionally captures and processes its output.
+It accepts many keyword arguments to configure its behaviour.
+</p>
+<p><code>run-program</code> returns three values: the first for the output,
+the second for the error-output, and the third for the return value.
+(Beware that before ASDF 3.0.2.11, it didn’t handle input or error-output,
</span> and returned only one value,
the one for the output if any handler was specified, or else the exit code;
<span style="color: #000000;background-color: #ffdddd">-please upgrade ASDF, or at least UIOP, to rely on the new enhanced behavior.)
-
- <p><var>output</var> is its most important argument;
-it specifies how the output is captured and processed.
</span><span style="color: #000000;background-color: #ddffdd">+please upgrade ASDF, or at least UIOP, to rely on the new enhanced behaviour.)
+</p>
+<p><var>output</var> is its most important argument;
+it specifies how the output is captured and processed.
</span> If it is <code>nil</code>, then the output is redirected to the null device,
<span style="color: #000000;background-color: #ffdddd">-that will discard it.
</span><span style="color: #000000;background-color: #ddffdd">+that will discard it.
</span> If it is <code>:interactive</code>, then it is inherited from the current process
(beware: this may be different from your <var>*standard-output*</var>,
<span style="color: #000000;background-color: #ffdddd">-and under SLIME will be on your <code>*inferior-lisp*</code> buffer).
-If it is <code>t</code>, output goes to your current <var>*standard-output*</var> stream.
</span><span style="color: #000000;background-color: #ddffdd">+and under SLIME will be on your <code>*inferior-lisp*</code> buffer).
+If it is <code>t</code>, output goes to your current <var>*standard-output*</var> stream.
</span> Otherwise, <var>output</var> should be a value that is a suitable first argument to
<code>slurp-input-stream</code> (see below), or
<span style="color: #000000;background-color: #ffdddd">-a list of such a value and keyword arguments.
</span><span style="color: #000000;background-color: #ddffdd">+a list of such a value and keyword arguments.
</span> In this case, <code>run-program</code> will
create a temporary stream for the program output;
the program output, in that stream,
will be processed by a call to <code>slurp-input-stream</code>,
using <var>output</var> as the first argument
<span style="color: #000000;background-color: #ffdddd">-(or if it's a list the first element of <var>output</var> and the rest as keywords).
</span><span style="color: #000000;background-color: #ddffdd">+(or if it’s a list the first element of <var>output</var> and the rest as keywords).
</span> The primary value resulting from that call
(or <code>nil</code> if no call was needed)
<span style="color: #000000;background-color: #ffdddd">-will be the first value returned by <code>run-program</code>.
</span><span style="color: #000000;background-color: #ddffdd">+will be the first value returned by <code>run-program</code>.
</span> E.g., using <code>:output :string</code>
<span style="color: #000000;background-color: #ffdddd">-will have it return the entire output stream as a string.
</span><span style="color: #000000;background-color: #ddffdd">+will have it return the entire output stream as a string.
</span> And using <code>:output '(:string :stripped t)</code>
will have it return the same string stripped of any ending newline.
<span style="color: #000000;background-color: #ffdddd">-
- <p><var>error-output</var> is similar to <var>output</var>, except that
-the resulting value is returned as the second value of <code>run-program</code>.
-<code>t</code> designates the <var>*error-output*</var>.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><var>error-output</var> is similar to <var>output</var>, except that
+the resulting value is returned as the second value of <code>run-program</code>.
+<code>t</code> designates the <var>*error-output*</var>.
</span> Also <code>:output</code> means redirecting the error output to the output stream,
in which case <code>nil</code> is returned.
<span style="color: #000000;background-color: #ffdddd">-
- <p><var>input</var> is similar to <var>output</var>, except that
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><var>input</var> is similar to <var>output</var>, except that
</span> <code>vomit-output-stream</code> is used, no value is returned,
and <code>t</code> designates the <var>*standard-input*</var>.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>element-type</code> and <code>external-format</code> are passed on
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>element-type</code> and <code>external-format</code> are passed on
</span> to your Lisp implementation, when applicable, for creation of the output stream.
<span style="color: #000000;background-color: #ffdddd">-
- <p>One and only one of the stream slurping or vomiting may or may not happen
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>One and only one of the stream slurping or vomiting may or may not happen
</span> in parallel in parallel with the subprocess,
depending on options and implementation,
<span style="color: #000000;background-color: #ffdddd">-and with priority being given to output processing.
</span><span style="color: #000000;background-color: #ddffdd">+and with priority being given to output processing.
</span> Other streams are completely produced or consumed
before or after the subprocess is spawned, using temporary files.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>force-shell</code> forces evaluation of the command through a shell,
-even if it was passed as a list rather than a string.
-If a shell is used, it is <samp><span class="file">/bin/sh</span></samp> on Unix or <samp><span class="file">CMD.EXE</span></samp> on Windows,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>force-shell</code> forces evaluation of the command through a shell,
+even if it was passed as a list rather than a string.
+If a shell is used, it is <samp>/bin/sh</samp> on Unix or <samp>CMD.EXE</samp> on Windows,
</span> except on implementations that (erroneously, IMNSHO)
insist on consulting <code>$SHELL</code> like clisp.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>ignore-error-status</code> causes <code>run-program</code>
-to not raise an error if the spawned program exits in error.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>ignore-error-status</code> causes <code>run-program</code>
+to not raise an error if the spawned program exits in error.
</span> Following POSIX convention, an error is anything but
<span style="color: #000000;background-color: #ffdddd">-a normal exit with status code zero.
</span><span style="color: #000000;background-color: #ddffdd">+a normal exit with status code zero.
</span> By default, an error of type <code>subprocess-error</code> is raised in this case.
<span style="color: #000000;background-color: #ffdddd">-
- <p><code>run-program</code> works on all platforms supported by ASDF, except Genera.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p><code>run-program</code> works on all platforms supported by ASDF, except Genera.
</span> See the source code for more documentation.
<span style="color: #000000;background-color: #ddffdd">+</p>
+</dd></dl>
+
+<dl>
+<dt><a name="index-slurp_002dinput_002dstream"></a>Function: <strong>slurp-input-stream</strong> <em>processor input-stream &key</em></dt>
+<dd>
+<p><code>slurp-input-stream</code> is a generic function of two arguments, a target object and an input stream,
+and accepting keyword arguments.
+Predefined methods based on the target object are as follows:
+</p>
+<ul>
+<li> If the object is a function, the function is called with the stream as argument.
</span>
<span style="color: #000000;background-color: #ffdddd">- </blockquote></div>
-
-<div class="defun">
-— Function: <b>slurp-input-stream</b><var> processor input-stream &key<a name="index-slurp_002dinput_002dstream-84"></a></var><br>
-<blockquote>
- <p>It's a generic function of two arguments, a target object and an input stream,
-and accepting keyword arguments.
-Predefined methods based on the target object are as follow:
-
- <p>If the object is a function, the function is called with the stream as argument.
-
- <p>If the object is a cons, its first element is applied to its rest appended by
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If the object is a cons, its first element is applied to its rest appended by
</span> a list of the input stream.
<span style="color: #000000;background-color: #ffdddd">- <p>If the object is an output stream, the contents of the input stream are copied to it.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If the object is an output stream, the contents of the input stream are copied to it.
</span> If the <var>linewise</var> keyword argument is provided, copying happens line by line,
<span style="color: #000000;background-color: #ffdddd">-and an optional <var>prefix</var> is printed before each line.
</span><span style="color: #000000;background-color: #ddffdd">+and an optional <var>prefix</var> is printed before each line.
</span> Otherwise, copying happen based on a buffer of size <var>buffer-size</var>,
using the specified <var>element-type</var>.
<span style="color: #000000;background-color: #ffdddd">- <p>If the object is <code>'string</code> or <code>:string</code>, the content is captured into a string.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If the object is <code>'string</code> or <code>:string</code>, the content is captured into a string.
</span> Accepted keywords include the <var>element-type</var> and a flag <var>stripped</var>,
which when true causes any single line ending to be removed as per <code>uiop:stripln</code>.
<span style="color: #000000;background-color: #ffdddd">- <p>If the object is <code>:lines</code>, the content is captured as a list of strings,
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If the object is <code>:lines</code>, the content is captured as a list of strings,
</span> one per line, without line ending. If the <var>count</var> keyword argument is provided,
it is a maximum count of lines to be read.
<span style="color: #000000;background-color: #ffdddd">- <p>If the object is <code>:line</code>, the content is capture as with <code>:lines</code> above,
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If the object is <code>:line</code>, the content is captured as with <code>:lines</code> above,
</span> and then its sub-object is extracted with the <var>at</var> argument,
<span style="color: #000000;background-color: #ffdddd">-which defaults to <code>0</code>, extracting the first line.
-A number will extract the corresponding line.
</span><span style="color: #000000;background-color: #ddffdd">+which defaults to <code>0</code>, extracting the first line.
+A number will extract the corresponding line.
</span> See the documentation for <code>uiop:access-at</code>.
<span style="color: #000000;background-color: #ffdddd">- <p>If the object is <code>:forms</code>, the content is captured as a list of S-expressions,
-as read by the Lisp reader.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If the object is <code>:forms</code>, the content is captured as a list of S-expressions,
+as read by the Lisp reader.
</span> If the <var>count</var> argument is provided,
<span style="color: #000000;background-color: #ffdddd">-it is a maximum count of lines to be read.
</span><span style="color: #000000;background-color: #ddffdd">+it is a maximum count of lines to be read.
</span> We recommend you control the syntax with such macro as
<code>uiop:with-safe-io-syntax</code>.
<span style="color: #000000;background-color: #ffdddd">- <p>If the object is <code>:form</code>, the content is capture as with <code>:forms</code> above,
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If the object is <code>:form</code>, the content is captured as with <code>:forms</code> above,
</span> and then its sub-object is extracted with the <var>at</var> argument,
<span style="color: #000000;background-color: #ffdddd">-which defaults to <code>0</code>, extracting the first form.
-A number will extract the corresponding form.
-See the documentation for <code>uiop:access-at</code>.
</span><span style="color: #000000;background-color: #ddffdd">+which defaults to <code>0</code>, extracting the first form.
+A number will extract the corresponding form.
+See the documentation for <code>uiop:access-at</code>.
</span> We recommend you control the syntax with such macro as
<code>uiop:with-safe-io-syntax</code>.
<span style="color: #000000;background-color: #ddffdd">+</li></ul>
+</dd></dl>
</span>
<span style="color: #000000;background-color: #ffdddd">- </blockquote></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p><a name="Getting-the-latest-version"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Getting-the-latest-version"></a>
+<a name="Getting-the-latest-version-1"></a>
+<h2 class="chapter">12 Getting the latest version</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- node-name, next, previous, up -->
-<h2 class="chapter">11 Getting the latest version</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Decide which version you want.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Decide which version you want.
</span> The <code>master</code> branch is where development happens;
its <code>HEAD</code> is usually OK, including the latest fixes and portability tweaks,
but an occasional regression may happen despite our (limited) test suite.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The <code>release</code> branch is what cautious people should be using;
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The <code>release</code> branch is what cautious people should be using;
</span> it has usually been tested more, and releases are cut at a point
<span style="color: #000000;background-color: #ffdddd">-where there isn't any known unresolved issue.
-
- <p>You may get the ASDF source repository using git:
-<kbd>git clone git://common-lisp.net/projects/asdf/asdf.git</kbd>
-
- <p>You will find the above referenced tags in this repository.
</span><span style="color: #000000;background-color: #ddffdd">+where there isn’t any known unresolved issue.
+</p>
+<p>You may get the ASDF source repository using git:
+<kbd>git clone https://gitlab.common-lisp.net/asdf/asdf.git</kbd>
+</p>
+<p>You will find the above referenced tags in this repository.
</span> You can also browse the repository on
<span style="color: #000000;background-color: #ffdddd">-<a href="http://common-lisp.net/gitweb?p=projects/asdf/asdf.git">http://common-lisp.net/gitweb?p=projects/asdf/asdf.git</a>.
-
- <p>Discussion of ASDF development is conducted on the
-mailing list
-<kbd>asdf-devel@common-lisp.net</kbd>.
-<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel">http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel</a>
-
-<p><a name="FAQ"></a>
-
-<!-- node-name, next, previous, up -->
-<h2 class="chapter">12 FAQ</h2>
</span><span style="color: #000000;background-color: #ddffdd">+<a href="https://gitlab.common-lisp.net/asdf/asdf">https://gitlab.common-lisp.net/asdf/asdf</a>.
+</p>
+<p>Discussion of ASDF development is conducted on the
+mailing list (see <a href="#Mailing-list">Mailing list</a>).
+</p>
+<hr>
+<a name="FAQ"></a>
+<a name="FAQ-1"></a>
+<h2 class="chapter">13 FAQ</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">12.1 “Where do I report a bug?”</h3>
</span>
<span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Where-do-I-report-a-bug_003f"></a>
+<a name="g_t_0060_0060Where-do-I-report-a-bug_003f_0027_0027"></a>
+<h3 class="section">13.1 “Where do I report a bug?”</h3>
+<a name="index-bug-tracker"></a>
+<a name="index-launchpad"></a>
</span> <p>ASDF bugs are tracked on launchpad: <a href="https://launchpad.net/asdf">https://launchpad.net/asdf</a>.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>If you’re unsure about whether something is a bug, or for general discussion,
+use the asdf-devel mailing list (see <a href="#Mailing-list">Mailing list</a>).
+</p>
+<hr>
+<a name="Mailing-list"></a>
+<a name="Mailing-list-1"></a>
+<h3 class="section">13.2 Mailing list</h3>
+<a name="index-mailing-list"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If you're unsure about whether something is a bug, or for general discussion,
-use the <a href="http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel">asdf-devel mailing list</a>
-
-<h3 class="section">12.2 “What has changed between ASDF 1 and ASDF 2?”</h3>
-
-<h4 class="subsection">12.2.1 What are ASDF 1 and ASDF 2?</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<p>Discussion of ASDF development is conducted on the
+mailing list
+<kbd>asdf-devel@common-lisp.net</kbd>.
+<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel">http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel</a>
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>On May 31st 2010, we have released ASDF 2.
-ASDF 2 refers to release 2.000 and later.
-(Releases between 1.656 and 1.728 were development releases for ASDF 2.)
-ASDF 1 to any release earlier than 1.369 or so.
-If your ASDF doesn't sport a version, it's an old ASDF 1.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="What-has-changed-between-ASDF-1-ASDF-2-and-ASDF-3_003f"></a>
+<a name="g_t_0060_0060What-has-changed-between-ASDF-1_002c-ASDF-2_002c-and-ASDF-3_003f_0027_0027"></a>
+<h3 class="section">13.3 “What has changed between ASDF 1, ASDF 2, and ASDF 3?”</h3>
+
+<p>We released ASDF 2.000 on May 31st 2010,
+ASDF 3.0.0 on May 15th 2013,
+ASDF 3.1.2 on May 6th 2014.
+Releases of ASDF 2 and now ASDF 3 have since then been included
+in all actively maintained CL implementations that used to bundle ASDF 1,
+plus many implementations that previously did not.
+ASDF has been made to work with all actively maintained CL
+implementations and even a few implementations that are <em>not</em>
+actively maintained.
+</p>
+<p>Furthermore, it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly
+(though we recommend instead upgrading your implementation or replacing its ASDF module).
+For this reason, we have stopped supporting ASDF 1 and ASDF 2.
+If you are using ASDF 1 or ASDF 2 and are experiencing any kind of issues or limitations,
+we recommend you upgrade to ASDF 3
+— and we explain how to do that. See <a href="#Loading-ASDF">Loading ASDF</a>.
+</p>
+<p>Note that in the context of compatibility requirements,
+ASDF 2.27, released on Feb 1st 2013, and further releases up to 2.33,
+count as pre-releases of ASDF 3, and define the <code>:asdf3</code> feature,
+though the first stable release of ASDF 3 was release 3.0.1.
+Significant new or improved functionality were added in ASDF 3.1;
+the <code>:asdf3.1</code> feature is present in recent enough versions to detect this functionality;
+the first stable release since then was ASDF 3.1.2.
+New <code>*features*</code> are only added at major milestones,
+and the next one will probably be <code>:asdf3.2</code>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>ASDF 2 and its release candidates push
-<code>:asdf2</code> onto <code>*features*</code> so that if you are writing
-ASDF-dependent code you may check for this feature
-to see if the new API is present.
-<em>All</em> versions of ASDF should have the <code>:asdf</code> feature.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Additionally, all versions of ASDF 2
-define a function <code>(asdf:asdf-version)</code> you may use to query the version;
-and the source code of recent versions of ASDF 2 features the version number
-prominently on the second line of its source code.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="What-are-ASDF-1-2-3_003f"></a>
+<a name="What-are-ASDF-1_002c-ASDF-2_002c-and-ASDF-3_003f"></a>
+<h4 class="subsection">13.3.1 What are ASDF 1, ASDF 2, and ASDF 3?</h4>
+
+<p>ASDF 1 refers to any release earlier than 1.369 or so (from August 2001 to October 2009),
+and to any development revision earlier than 2.000 (May 2010).
+If your copy of ASDF doesn’t even contain version information, it’s an old ASDF 1.
+Revisions between 1.656 and 1.728 may count as development releases for ASDF 2.
+</p>
+<p>ASDF 2 refers to releases from 2.000 (May 31st 2010) to 2.26 (Oct 30th 2012),
+and any development revision newer than ASDF 1 and older than 2.27 (Feb 1st 2013).
+</p>
+<p>ASDF 3 refers to releases from 2.27 (Feb 1st 2013) to 2.33 and 3.0.0 onward (May 15th 2013).
+2.27 to 2.33 count as pre-releases to ASDF 3.
+</p>
+<p>ASDF 3.1 refers to releases from 3.1.2 (May 6th 2014) onward.
+These releases are also considered part of ASDF 3.
+</p>
+<hr>
+<a name="How-do-I-detect-the-ASDF-version_003f"></a>
+<a name="How-do-I-detect-the-ASDF-version_003f-1"></a>
+<h4 class="subsection">13.3.2 How do I detect the ASDF version?</h4>
+<a name="index-asdf_002dversion"></a>
+<a name="index-_002afeatures_002a"></a>
+
+<p>All releases of ASDF
+push <code>:asdf</code> onto <code>*features*</code>.
+Releases starting with ASDF 2
+push <code>:asdf2</code> onto <code>*features*</code>.
+Releases starting with ASDF 3 (including 2.27 and later pre-releases)
+push <code>:asdf3</code> onto <code>*features*</code>.
+Furthermore, releases starting with ASDF 3.1.2 (May 2014),
+though they count as ASDF 3, include enough progress that they
+also push <code>:asdf3.1</code> onto <code>*features*</code>.
+You may depend on the presence or absence of these features
+to write code that takes advantage of recent ASDF functionality
+but still works on older versions, or at least detects the old version and signals an error.
+</p>
+<p>Additionally, all releases starting with ASDF 2
+define a function <code>(asdf:asdf-version)</code> you may use to query the version.
+All releases starting with 2.013 display the version number prominently
+on the second line of the <samp>asdf.lisp</samp> source file.
+</p>
+<p>If you are experiencing problems or limitations of any sort with ASDF 1 or ASDF 2,
+we recommend that you should upgrade to the latest release, be it ASDF 3 or other.
+</p>
+<p>Finally, here is a code snippet to programmatically determine what version of ASDF is loaded, if any,
+that works on all versions including very old ones:
+</p>
+<div class="lisp">
+<pre class="lisp">(when (find-package :asdf)
+ (let ((ver (symbol-value
+ (or (find-symbol (string :*asdf-version*) :asdf)
+ (find-symbol (string :*asdf-revision*) :asdf)))))
+ (etypecase ver
+ (string ver)
+ (cons (with-output-to-string (s)
+ (loop for (n . m) on ver
+ do (princ n s)
+ (when m (princ "." s)))))
+ (null "1.0"))))
+</pre></div>
+
+<p>If it returns <code>nil</code> then ASDF is not installed.
+Otherwise it should return a string.
+If it returns <code>"1.0"</code>, then it can actually be
+any version before 1.77 or so, or some buggy variant of 1.x.
+If it returns anything older than <code>"3.0.1"</code>,
+you really need to upgrade your implementation or at least upgrade its ASDF.
+See <a href="#Replacing-your-implementation_0027s-ASDF">Replacing your implementation's ASDF</a>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If you are experiencing problems or limitations of any sort with ASDF 1,
-we recommend that you should upgrade to ASDF 2,
-or whatever is the latest release.
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.2.2 ASDF can portably name files in subdirectories</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="ASDF-can-portably-name-files-in-subdirectories"></a>
+<a name="ASDF-can-portably-name-files-in-subdirectories-1"></a>
+<h4 class="subsection">13.3.3 ASDF can portably name files in subdirectories</h4>
</span>
<p>Common Lisp namestrings are not portable,
<span style="color: #000000;background-color: #ffdddd">-except maybe for logical pathnamestrings,
</span><span style="color: #000000;background-color: #ddffdd">+except maybe for logical pathname namestrings,
</span> that themselves have various limitations and require a lot of setup
that is itself ultimately non-portable.
<span style="color: #000000;background-color: #ffdddd">-
- <p>In ASDF 1, the only portable ways to refer to pathnames inside systems and components
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>In ASDF 1, the only portable ways to refer to pathnames inside systems and components
</span> were very awkward, using <code>#.(make-pathname ...)</code> and
<span style="color: #000000;background-color: #ffdddd">-<code>#.(merge-pathnames ...)</code>.
</span><span style="color: #000000;background-color: #ddffdd">+<code>#.(merge-pathnames ...)</code>.
</span> Even the above were themselves were inadequate in the general case
<span style="color: #000000;background-color: #ffdddd">-due to host and device issues, unless horribly complex patterns were used.
-Plenty of simple cases that looked portable actually weren't,
</span><span style="color: #000000;background-color: #ddffdd">+due to host and device issues, unless horribly complex patterns were used.
+Plenty of simple cases that looked portable actually weren’t,
</span> leading to much confusion and greavance.
<span style="color: #000000;background-color: #ffdddd">-
- <p>ASDF 2 implements its own portable syntax for strings as pathname specifiers.
-Naming files within a system definition becomes easy and portable again.
-See <a href="#Miscellaneous-additional-functionality">asdf:system-relative-pathname</a>,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>ASDF 2 implements its own portable syntax for strings as pathname specifiers.
+Naming files within a system definition becomes easy and portable again.
+See <a href="#Miscellaneous-additional-functionality">system-relative-pathname</a>,
</span> <code>merge-pathnames*</code>,
<code>coerce-pathname</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>On the other hand, there are places where systems used to accept namestrings
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>On the other hand, there are places where systems used to accept namestrings
</span> where you must now use an explicit pathname object:
<span style="color: #000000;background-color: #ffdddd">-<code>(defsystem ... :pathname "LOGICAL-HOST:PATH;TO;SYSTEM;" ...)</code>
</span><span style="color: #000000;background-color: #ddffdd">+<code>(defsystem ... :pathname "LOGICAL-HOST:PATH;TO;SYSTEM;" ...)</code>
</span> must now be written with the <code>#p</code> syntax:
<span style="color: #000000;background-color: #ffdddd">-<code>(defsystem ... :pathname #p"LOGICAL-HOST:PATH;TO;SYSTEM;" ...)</code>
-
- <p>See <a href="#The-defsystem-grammar">Pathname specifiers</a>.
</span><span style="color: #000000;background-color: #ddffdd">+<code>(defsystem ... :pathname #p"LOGICAL-HOST:PATH;TO;SYSTEM;" ...)</code>
+</p>
+<p>See <a href="#The-defsystem-grammar">Pathname specifiers</a>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.2.3 Output translations</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Output-translations"></a>
+<a name="Output-translations-1"></a>
+<h4 class="subsection">13.3.4 Output translations</h4>
</span>
<p>A popular feature added to ASDF was output pathname translation:
<code>asdf-binary-locations</code>, <code>common-lisp-controller</code>,
<code>cl-launch</code> and other hacks were all implementing it in ways
both mutually incompatible and difficult to configure.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Output pathname translation is essential to share
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Output pathname translation is essential to share
</span> source directories of portable systems across multiple implementations
or variants thereof,
or source directories of shared installations of systems across multiple users,
or combinations of the above.
<span style="color: #000000;background-color: #ffdddd">-
- <p>In ASDF 2, a standard mechanism is provided for that,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>In ASDF 2, a standard mechanism is provided for that,
</span> <code>asdf-output-translations</code>,
with sensible defaults, adequate configuration languages,
a coherent set of configuration files and hooks,
and support for non-Unix platforms.
<span style="color: #000000;background-color: #ffdddd">-
- <p>See <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a>.
-
-<h4 class="subsection">12.2.4 Source Registry Configuration</h4>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>See <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a>.
+</p>
+<hr>
+<a name="Source-Registry-Configuration"></a>
+<a name="Source-Registry-Configuration-1"></a>
+<h4 class="subsection">13.3.5 Source Registry Configuration</h4>
</span>
<p>Configuring ASDF used to require special magic
to be applied just at the right moment,
between the moment ASDF is loaded and the moment it is used,
in a way that is specific to the user,
the implementation he is using and the application he is building.
<span style="color: #000000;background-color: #ffdddd">-
- <p>This made for awkward configuration files and startup scripts
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>This made for awkward configuration files and startup scripts
</span> that could not be shared between users, managed by administrators
or packaged by distributions.
<span style="color: #000000;background-color: #ffdddd">-
- <p>ASDF 2 provides a well-documented way to configure ASDF,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>ASDF 2 provides a well-documented way to configure ASDF,
</span> with sensible defaults, adequate configuration languages,
and a coherent set of configuration files and hooks.
<span style="color: #000000;background-color: #ffdddd">-
- <p>We believe it's a vast improvement because it decouples
-application distribution from library distribution.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>We believe it’s a vast improvement because it decouples
+application distribution from library distribution.
</span> The application writer can avoid thinking where the libraries are,
<span style="color: #000000;background-color: #ffdddd">-and the library distributor (dpkg, clbuild, advanced user, etc.)
-can configure them once and for every application.
</span><span style="color: #000000;background-color: #ddffdd">+and the library distributor (dpkg, clbuild, advanced user, etc.)
+can configure them once and for every application.
</span> Yet settings can be easily overridden where needed,
so whoever needs control has exactly as much as required.
<span style="color: #000000;background-color: #ffdddd">-
- <p>At the same time, ASDF 2 remains compatible
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>At the same time, ASDF 2 remains compatible
</span> with the old magic you may have in your build scripts
(using <code>*central-registry*</code> and
<code>*system-definition-search-functions*</code>)
to tailor the ASDF configuration to your build automation needs,
and also allows for new magic, simpler and more powerful magic.
<span style="color: #000000;background-color: #ddffdd">+</p>
+<p>See <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>See <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a>.
-
-<h4 class="subsection">12.2.5 Usual operations are made easier to the user</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Usual-operations-are-made-easier-to-the-user"></a>
+<a name="Usual-operations-are-made-easier-to-the-user-1"></a>
+<h4 class="subsection">13.3.6 Usual operations are made easier to the user</h4>
</span>
<p>In ASDF 1, you had to use the awkward syntax
<code>(asdf:oos 'asdf:load-op :foo)</code>
to load a system,
and similarly for <code>compile-op</code>, <code>test-op</code>.
<span style="color: #000000;background-color: #ffdddd">-
- <p>In ASDF 2, you can use shortcuts for the usual operations:
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>In ASDF 2, you can use shortcuts for the usual operations:
</span> <code>(asdf:load-system :foo)</code>, and
similarly for <code>compile-system</code>, <code>test-system</code>.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.2.6 Many bugs have been fixed</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Many-bugs-have-been-fixed"></a>
+<a name="Many-bugs-have-been-fixed-1"></a>
+<h4 class="subsection">13.3.7 Many bugs have been fixed</h4>
</span>
<p>The following issues and many others have been fixed:
<span style="color: #000000;background-color: #ffdddd">-
- <ul>
-<li>The infamous TRAVERSE function has been revamped completely
-between ASDF 1 and ASDF 2, with many bugs squashed.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<ul>
+<li> The infamous TRAVERSE function has been revamped completely
+between ASDF 1 and ASDF 2, with many bugs squashed.
</span> In particular, dependencies were not correctly propagated
<span style="color: #000000;background-color: #ffdddd">-across modules but now are.
</span><span style="color: #000000;background-color: #ddffdd">+across modules but now are.
</span> It has been completely rewritten many times over
between ASDF 2.000 and ASDF 3,
<span style="color: #000000;background-color: #ffdddd">-with fundamental issues in the original model being fixed.
-Timestamps were not propagated at all, and now are.
</span><span style="color: #000000;background-color: #ddffdd">+with fundamental issues in the original model being fixed.
+Timestamps were not propagated at all, and now are.
</span> The internal model of how actions depend on each other
<span style="color: #000000;background-color: #ffdddd">-is now both consistent and complete.
-The :version and
-the :force (system1 .. systemN) feature have been fixed.
</span><span style="color: #000000;background-color: #ddffdd">+is now both consistent and complete.
+The <code>:version</code> and
+the <code>:force (system1 .. systemN)</code> feature have been fixed.
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>Performance has been notably improved for large systems
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Performance has been notably improved for large systems
</span> (say with thousands of components) by using
hash-tables instead of linear search,
<span style="color: #000000;background-color: #ffdddd">-and linear-time list accumulation
-instead of quadratic-time recursive appends.
</span><span style="color: #000000;background-color: #ddffdd">+and linear-time list accumulation instead of cubic time recursive append,
+for an overall <em>O(n)</em> complexity vs <em>O(n^4)</em>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>Many features used to not be portable,
-especially where pathnames were involved.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Many features used to not be portable,
+especially where pathnames were involved.
</span> Windows support was notably quirky because of such non-portability.
<span style="color: #000000;background-color: #ffdddd">- <li>The internal test suite used to massively fail on many implementations.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The internal test suite used to massively fail on many implementations.
</span> While still incomplete, it now fully passes
on all implementations supported by the test suite,
<span style="color: #000000;background-color: #ffdddd">-except for GCL (due to GCL bugs).
</span><span style="color: #000000;background-color: #ddffdd">+though some tests are commented out on a few implementations.
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>Support was lacking for some implementations.
-ABCL and GCL were notably wholly broken.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Support was lacking for some implementations.
+ABCL and GCL were notably wholly broken.
</span> ECL extensions were not integrated with ASDF release.
<span style="color: #000000;background-color: #ffdddd">- <li>The documentation was grossly out of date.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The documentation was grossly out of date.
+
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- </ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.2.7 ASDF itself is versioned</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="ASDF-itself-is-versioned"></a>
+<a name="ASDF-itself-is-versioned-1"></a>
+<h4 class="subsection">13.3.8 ASDF itself is versioned</h4>
</span>
<p>Between new features, old bugs fixed, and new bugs introduced,
there were various releases of ASDF in the wild,
<span style="color: #000000;background-color: #ffdddd">-and no simple way to check which release had which feature set.
</span><span style="color: #000000;background-color: #ddffdd">+and no simple way to check which release had which feature set.
</span> People using or writing systems had to either make worst-case assumptions
as to what features were available and worked,
or take great pains to have the correct version of ASDF installed.
<span style="color: #000000;background-color: #ffdddd">-
- <p>With ASDF 2, we provide a new stable set of working features
-that everyone can rely on from now on.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>With ASDF 2, we provide a new stable set of working features
+that everyone can rely on from now on.
</span> Use <code>#+asdf2</code> to detect presence of ASDF 2,
<span style="color: #000000;background-color: #ffdddd">-<code>(asdf:version-satisfies (asdf:asdf-version) "2.345.67")</code>
</span><span style="color: #000000;background-color: #ddffdd">+<code>(asdf:version-satisfies (asdf:asdf-version) "2.345.67")</code>
</span> to check the availability of a version no earlier than required.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.2.8 ASDF can be upgraded</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="ASDF-can-be-upgraded"></a>
+<a name="ASDF-can-be-upgraded-1"></a>
+<h4 class="subsection">13.3.9 ASDF can be upgraded</h4>
</span>
<p>When an old version of ASDF was loaded,
it was very hard to upgrade ASDF in your current image
<span style="color: #000000;background-color: #ffdddd">-without breaking everything.
</span><span style="color: #000000;background-color: #ddffdd">+without breaking everything.
</span> Instead you had to exit the Lisp process and
<span style="color: #000000;background-color: #ffdddd">-somehow arrange to start a new one from a simpler image.
-Something that can't be done from within Lisp,
</span><span style="color: #000000;background-color: #ddffdd">+somehow arrange to start a new one from a simpler image.
+Something that can’t be done from within Lisp,
</span> making automation of it difficult,
which compounded with difficulty in configuration,
<span style="color: #000000;background-color: #ffdddd">-made the task quite hard.
</span><span style="color: #000000;background-color: #ddffdd">+made the task quite hard.
</span> Yet as we saw before, the task would have been required
to not have to live with the worst case or non-portable
subset of ASDF features.
<span style="color: #000000;background-color: #ffdddd">-
- <p>With ASDF 2, it is easy to upgrade
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>With ASDF 2, it is easy to upgrade
</span> from ASDF 2 to later versions from within Lisp,
<span style="color: #000000;background-color: #ffdddd">-and not too hard to upgrade from ASDF 1 to ASDF 2 from within Lisp.
</span><span style="color: #000000;background-color: #ddffdd">+and not too hard to upgrade from ASDF 1 to ASDF 2 from within Lisp.
</span> We support hot upgrade of ASDF and any breakage is a bug
<span style="color: #000000;background-color: #ffdddd">-that we will do our best to fix.
</span><span style="color: #000000;background-color: #ddffdd">+that we will do our best to fix.
</span> There are still limitations on upgrade, though,
most notably the fact that after you upgrade ASDF,
you must also reload or upgrade all ASDF extensions.
<span style="color: #000000;background-color: #ffdddd">-
-<h4 class="subsection">12.2.9 Decoupled release cycle</h4>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="Decoupled-release-cycle"></a>
+<a name="Decoupled-release-cycle-1"></a>
+<h4 class="subsection">13.3.10 Decoupled release cycle</h4>
</span>
<p>When vendors were releasing their Lisp implementations with ASDF,
they had to basically never change version
because neither upgrade nor downgrade was possible
without breaking something for someone,
and no obvious upgrade path was visible and recommendable.
<span style="color: #000000;background-color: #ffdddd">-
- <p>With ASDF 2, upgrade is possible, easy and can be recommended.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>With ASDF 2, upgrade is possible, easy and can be recommended.
</span> This means that vendors can safely ship a recent version of ASDF,
<span style="color: #000000;background-color: #ffdddd">-confident that if a user isn't fully satisfied,
</span><span style="color: #000000;background-color: #ddffdd">+confident that if a user isn’t fully satisfied,
</span> he can easily upgrade ASDF and deal
<span style="color: #000000;background-color: #ffdddd">-with a supported recent version of it.
</span><span style="color: #000000;background-color: #ddffdd">+with a supported recent version of it.
</span> This means that release cycles will be causally decoupled,
the practical consequence of which will mean faster convergence
towards the latest version for everyone.
<span style="color: #000000;background-color: #ddffdd">+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.2.10 Pitfalls of the transition to ASDF 2</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Pitfalls-of-the-transition-to-ASDF-2"></a>
+<a name="Pitfalls-of-the-transition-to-ASDF-2-1"></a>
+<h4 class="subsection">13.3.11 Pitfalls of the transition to ASDF 2</h4>
</span>
<p>The main pitfalls in upgrading to ASDF 2 seem to be related
to the output translation mechanism.
<span style="color: #000000;background-color: #ffdddd">-
- <ul>
-<li>Output translations is enabled by default. This may surprise some users,
-most of them in pleasant way (we hope), a few of them in an unpleasant way.
-It is trivial to disable output translations.
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<ul>
+<li> Output translations is enabled by default. This may surprise some users,
+most of them in pleasant way (we hope), a few of them in an unpleasant way.
+It is trivial to disable output translations.
</span> See <a href="#FAQ">“How can I wholly disable the compiler output cache?”</a>.
<span style="color: #000000;background-color: #ffdddd">- <li>Some systems in the large have been known
-not to play well with output translations.
-They were relatively easy to fix.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Some systems in the large have been known
+not to play well with output translations.
+They were relatively easy to fix.
</span> Once again, it is also easy to disable output translations,
or to override its configuration.
<span style="color: #000000;background-color: #ffdddd">- <li>The new ASDF output translations are incompatible with ASDF-Binary-Locations.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The new ASDF output translations are incompatible with ASDF-Binary-Locations.
</span> They replace A-B-L, and there is compatibility mode to emulate
<span style="color: #000000;background-color: #ffdddd">-your previous A-B-L configuration.
</span><span style="color: #000000;background-color: #ddffdd">+your previous A-B-L configuration.
</span> See <code>enable-asdf-binary-locations-compatibility</code> in
<span style="color: #000000;background-color: #ffdddd">-see <a href="#Controlling-where-ASDF-saves-compiled-files">Backward Compatibility</a>.
</span><span style="color: #000000;background-color: #ddffdd">+see <a href="#Controlling-where-ASDF-saves-compiled-files">Backward Compatibility</a>.
</span> But thou shalt not load ABL on top of ASDF 2.
<span style="color: #000000;background-color: #ffdddd">- </ul>
-
- <p>Other issues include the following:
</span><span style="color: #000000;background-color: #ddffdd">+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- <ul>
-<li>ASDF pathname designators are now specified
</span><span style="color: #000000;background-color: #ddffdd">+<p>Other issues include the following:
+</p>
+<ul>
+<li> ASDF pathname designators are now specified
</span> in places where they were unspecified,
<span style="color: #000000;background-color: #ffdddd">-and a few small adjustments have to be made to some non-portable defsystems.
</span><span style="color: #000000;background-color: #ddffdd">+and a few small adjustments have to be made to some non-portable defsystems.
</span> Notably, in the <code>:pathname</code> argument
to a <code>defsystem</code> and its components,
a logical pathname (or implementation-dependent hierarchical pathname)
must now be specified with <code>#p</code> syntax
where the namestring might have previously sufficed;
moreover when evaluation is desired <code>#.</code> must be used,
<span style="color: #000000;background-color: #ffdddd">-where it wasn't necessary in the toplevel <code>:pathname</code> argument
</span><span style="color: #000000;background-color: #ddffdd">+where it wasn’t necessary in the toplevel <code>:pathname</code> argument
</span> (but necessary in other <code>:pathname</code> arguments).
<span style="color: #000000;background-color: #ffdddd">- <li>There is a slight performance bug, notably on SBCL,
-when initially searching for <samp><span class="file">asd</span></samp> files,
-the implicit <code>(directory "/configured/path/**/*.asd")</code>
-for every configured path <code>(:tree "/configured/path/")</code>
-in your <code>source-registry</code> configuration can cause a slight pause.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> There is a slight performance bug, notably on SBCL,
+when initially searching for <samp>asd</samp> files,
+the implicit <code>(directory "/configured/path/**/*.asd")</code>
+for every configured path <code>(:tree "/configured/path/")</code>
+in your <code>source-registry</code> configuration can cause a slight pause.
</span> Try to <code>(time (asdf:initialize-source-registry))</code>
<span style="color: #000000;background-color: #ffdddd">-to see how bad it is or isn't on your system.
</span><span style="color: #000000;background-color: #ddffdd">+to see how bad it is or isn’t on your system.
</span> If you insist on not having this pause,
you can avoid the pause by overriding the default source-registry configuration
and not use any deep <code>:tree</code> entry but only <code>:directory</code> entries
<span style="color: #000000;background-color: #ffdddd">-or shallow <code>:tree</code> entries.
</span><span style="color: #000000;background-color: #ddffdd">+or shallow <code>:tree</code> entries.
</span> Or you can fix your implementation to not be quite that slow
<span style="color: #000000;background-color: #ffdddd">-when recursing through directories.
</span><span style="color: #000000;background-color: #ddffdd">+when recursing through directories.
</span> <em>Update</em>: This performance bug fixed the hard way in 2.010.
<span style="color: #000000;background-color: #ffdddd">- <li>On Windows, only LispWorks supports proper default configuration pathnames
-based on the Windows registry.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> On Windows, only LispWorks supports proper default configuration pathnames
+based on the Windows registry.
</span> Other implementations make do with environment variables,
that you may have to define yourself
<span style="color: #000000;background-color: #ffdddd">-if you're using an older version of Windows.
-Windows support is somewhat less tested than Unix support.
-Please help report and fix bugs.
</span><span style="color: #000000;background-color: #ddffdd">+if you’re using an older version of Windows.
+Windows support is somewhat less tested than Unix support.
+Please help report and fix bugs.
</span> <em>Update</em>: As of ASDF 2.21, all implementations
should now use the same proper default configuration pathnames
<span style="color: #000000;background-color: #ffdddd">-and they should actually work, though they haven't all been tested.
</span><span style="color: #000000;background-color: #ddffdd">+and they should actually work, though they haven’t all been tested.
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>The mechanism by which one customizes a system so that Lisp files
-may use a different extension from the default <samp><span class="file">.lisp</span></samp> has changed.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> The mechanism by which one customizes a system so that Lisp files
+may use a different extension from the default <samp>.lisp</samp> has changed.
</span> Previously, the pathname for a component
was lazily computed when operating on a system,
and you would
<code>(defmethod source-file-type ((component cl-source-file) (system (eql (find-system 'foo))))
<span style="color: #000000;background-color: #ffdddd">- (declare (ignorable component system)) "lis")</code>.
</span><span style="color: #000000;background-color: #ddffdd">+ (declare (ignorable component system)) "lis")</code>.
</span> Now, the pathname for a component is eagerly computed when defining the system,
<span style="color: #000000;background-color: #ffdddd">-and instead you will <code>(defclass cl-source-file.lis (cl-source-file) ((type :initform "lis")))</code>
</span><span style="color: #000000;background-color: #ddffdd">+and instead you will <code>(defclass cl-source-file.lis (cl-source-file) ((type :initform "lis")))</code>
</span> and use <code>:default-component-class cl-source-file.lis</code>
as argument to <code>defsystem</code>,
as detailed in a see <a href="#FAQ">How do I create a system definition where all the source files have a .cl extension?</a> below.
<span style="color: #000000;background-color: #ddffdd">+<code>source-file-type</code> is deprecated. To access a component’s
+file-type, use <code>file-type</code>, instead. <code>source-file-type</code> will
+be removed.
+
+<a name="index-source_002dfile_002dtype"></a>
+<a name="index-file_002dtype"></a>
+
+</li></ul>
+
+
+<hr>
+<a name="Pitfalls-of-the-upgrade-to-ASDF-3"></a>
+<a name="Pitfalls-of-the-upgrade-to-ASDF-3-1"></a>
+<h4 class="subsection">13.3.12 Pitfalls of the upgrade to ASDF 3</h4>
+
+<p>While ASDF 3 is largely compatible with ASDF 2,
+there are a few pitfalls when upgrading from ASDF 2,
+due to limitations in ASDF 2.
+</p>
+<ul>
+<li> ASDF 2 was designed so it could be upgraded;
+but upgrading it required a special setup at the beginning of your build files.
+Failure to upgrade it early could result in catastrophic attempt to self-upgrade in mid-build.
+
+</li><li> Starting with ASDF 3 (2.27 or later),
+ASDF will automatically attempt to upgrade itself
+as the first step before any system operation,
+to avoid any possibility of such catastrophic mid-build self-upgrade.
+But that doesn’t help if your old implementation still provides ASDF 2.
+
+</li><li> It was unsafe in ASDF 2 for a system definition to declare a dependency on ASDF,
+since it could trigger such catastrophe for users who were not carefully configured.
+If you declare a dependency on a recent enough ASDF,
+yet want to be nice with these potentially misconfigured users,
+we recommend that you not only specify a recent ASDF in your dependencies with
+<code>:depends-on ((:version "asdf" "3.1.2"))</code>,
+but that you <em>also</em> check that ASDF 3 is installed,
+or else the upgrade catastrophe might happen before that specification is checked,
+by starting your <samp>.asd</samp> file with a version check as follows:
+<div class="example">
+<pre class="example">#-asdf3 (error "<var>MY-SYSTEM</var> requires ASDF 3.1.2")
+</pre></div>
+
+</li><li> When you upgrade from too old a version of ASDF,
+previously loaded ASDF extensions become invalid, and will need to be reloaded.
+Example extensions include CFFI-Grovel, hacks used by ironclad, etc.
+Since it isn’t possible to automatically detect what extensions
+need to be invalidated and what systems use them,
+ASDF will invalidate <em>all</em> previously loaded systems
+when it is loaded on top of a forward-incompatible ASDF version.
+<a name="DOCF17" href="#FOOT17"><sup>17</sup></a>
+
+</li><li> To write a portable build script, you need to rely on a recent version of UIOP,
+but until you have ensured a recent ASDF is loaded,
+you can’t rely on UIOP being present,
+and thus must manually avoid all the pathname pitfalls when loading ASDF itself.
+
+</li><li> Bugs in CMUCL and XCL prevent upgrade of ASDF from an old forward-incompatible version.
+Happily, CMUCL comes with a recent ASDF,
+and XCL is more of a working demo than something you’d use seriously anyway.
+
+</li><li> For the above reasons, your build and startup scripts
+should load, configure and upgrade ASDF among the very first things they do,
+and ensure that ASDF 3 or later is present indeed,
+before they start using ASDF to load anything else.
+
+</li><li> Now that all implementations provide ASDF 3 or later (since May 2015),
+the simple solution is just to use code as below in your setup,
+and when it fails, upgrade your implementation or replace its ASDF.
+(see <a href="#Replacing-your-implementation_0027s-ASDF">Replacing your implementation's ASDF</a>):
+<div class="example">
+<pre class="example">(require "asdf")
+#-asdf3 (error "ASDF 3 or bust")
+</pre></div>
+
+</li><li> For scripts that try to use ASDF simply via <code>require</code> at first, and
+make heroic attempts to load it the hard way if at first they don’t succeed,
+see <samp>tools/load-asdf.lisp</samp> distributed with the ASDF source repository,
+or the code of <a href="https://cliki.net/cl-launch"><code>cl-launch</code></a>.
+
+</li><li> Note that in addition to the pitfalls and constraints above,
+these heroic scripts (should you wish to write or modify one),
+must take care to configure ASDF <em>twice</em>.
+A first time, right after you load the old ASDF 2 and before you upgrade to the new ASDF 3,
+so it may find where you put ASDF 3.
+A second time, because some implementations can’t handle a smooth upgrade to ASDF 3,
+and lose configuration as they do.
+<div class="lisp">
+<pre class="lisp">(ignore-errors (funcall 'require "asdf")) ;; <--- try real hard
+;; <--- insert heroics here, if that failed to provide ASDF 2 or 3
+;; <--- insert configuration here, if that succeeded
+(asdf:load-system "asdf")
+;; <--- re-configure here, too, in case at first you got ASDF 2
+</pre></div>
+
+</li></ul>
+
+
+<hr>
+<a name="What-happened-to-the-bundle-operations"></a>
+<a name="What-happened-to-the-bundle-operations_003f"></a>
+<h4 class="subsection">13.3.13 What happened to the bundle operations?</h4>
+
+<a name="index-fasl_002dop-_0028obsolete_0029"></a>
+<a name="index-load_002dfasl_002dop-_0028obsolete_0029"></a>
+<a name="index-binary_002dop-_0028obsolete_0029"></a>
+<a name="index-monolithic_002dfasl_002dop-_0028obsolete_0029"></a>
+<a name="index-monolithic_002dload_002dfasl_002dop-_0028obsolete_0029"></a>
+<a name="index-monolithic_002dbinary_002dop-_0028obsolete_0029"></a>
+<a name="index-compile_002dbundle_002dop-1"></a>
+<a name="index-load_002dbundle_002dop"></a>
+<a name="index-deliver_002dasd_002dop"></a>
+<a name="index-monolithic_002dcompile_002dbundle_002dop"></a>
+<a name="index-monolithic_002dload_002dbundle_002dop"></a>
+<a name="index-monolithic_002ddeliver_002dasd_002dop"></a>
+
+<p><code>asdf-ecl</code> and its short-lived successor <code>asdf-bundle</code> are no more,
+having been replaced by code now built into ASDF 3.
+Moreover, the name of the bundle operations has changed since ASDF 3.1.3.
+</p>
+<p>And yet, the feature is not enabled to be used by <code>load-system</code> by default on ECL as originally intended,
+because of a bug in ECL itself found during testing.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><a name="index-source_002dfile_002dtype-85"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<p>Some of the bundle operations were renamed after ASDF 3.1.3, and the old
+names have been removed. Old bundle operations, and their modern
+equivalents are:
+</p>
+<ul>
+<li> <code>fasl-op</code> is now <code>compile-bundle-op</code>
+</li><li> <code>load-fasl-op</code> is now <code>load-bundle-op</code>
+</li><li> <code>binary-op</code> is now <code>deliver-asd-op</code>
+</li><li> <code>monolithic-fasl-op</code> is now <code>monolithic-compile-bundle-op</code>
+</li><li> <code>monolithic-load-fasl-op</code> is now <code>monolithic-load-bundle-op</code>
+</li><li> <code>monolithic-binary-op</code> is now <code>monolithic-deliver-asd-op</code>
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- </ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">12.3 Issues with installing the proper version of ASDF</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.3.1 “My Common Lisp implementation comes with an outdated version of ASDF. What to do?”</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Issues-with-installing-the-proper-version-of-ASDF"></a>
+<a name="Issues-with-installing-the-proper-version-of-ASDF-1"></a>
+<h3 class="section">13.4 Issues with installing the proper version of ASDF</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>We recommend you upgrade ASDF.
-See <a href="#Loading-ASDF">Upgrading ASDF</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If this does not work, it is a bug, and you should report it.
-See <a href="#FAQ">report-bugs</a>.
-In the meantime, you can load <samp><span class="file">asdf.lisp</span></samp> directly.
-See <a href="#Loading-ASDF">Loading an otherwise installed ASDF</a>.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="My-Common-Lisp-implementation-comes-with-an-outdated-version-of-ASDF_002e-What-to-do_003f"></a>
+<a name="g_t_0060_0060My-Common-Lisp-implementation-comes-with-an-outdated-version-of-ASDF_002e-What-to-do_003f_0027_0027"></a>
+<h4 class="subsection">13.4.1 “My Common Lisp implementation comes with an outdated version of ASDF. What to do?”</h4>
+
+<p>If you have a recent implementation, it should already come with ASDF 3 or later.
+If you need a more recent version than is provided,
+we recommend you simply upgrade ASDF by installing a recent version
+in a path configured in your source-registry.
+See <a href="#Upgrading-ASDF">Upgrading ASDF</a>.
+</p>
+<p>If you have an old implementation that does not provide ASDF 3,
+we recommend you replace your implementation’s ASDF.
+See <a href="#Replacing-your-implementation_0027s-ASDF">Replacing your implementation's ASDF</a>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.3.2 “I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?”</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="I_0027m-a-Common-Lisp-implementation-vendor_002e-When-and-how-should-I-upgrade-ASDF_003f"></a>
+<a name="g_t_0060_0060I_0027m-a-Common-Lisp-implementation-vendor_002e-When-and-how-should-I-upgrade-ASDF_003f_0027_0027"></a>
+<h4 class="subsection">13.4.2 “I’m a Common Lisp implementation vendor. When and how should I upgrade ASDF?”</h4>
</span>
<p>Since ASDF 2,
<span style="color: #000000;background-color: #ffdddd">-it should always be a good time to upgrade to a recent version of ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+it should always be a good time to upgrade to a recent version of ASDF.
</span> You may consult with the maintainer for which specific version they recommend,
<span style="color: #000000;background-color: #ffdddd">-but the latest <code>release</code> should be correct.
-We trust you to thoroughly test it with your implementation
-before you release it.
</span><span style="color: #000000;background-color: #ddffdd">+but the latest <code>release</code> should be correct.
+Though we do try to test ASDF releases against all implementations that we can,
+we may not be testing against all variants of your implementation,
+and we may not be running enough tests;
+we trust you to thoroughly test it with your own implementation
+before you release it.
</span> If there are any issues with the current release,
<span style="color: #000000;background-color: #ffdddd">-it's a bug that you should report upstream and that we will fix ASAP.
-
- <p>As to how to include ASDF, we recommend the following:
-
- <ul>
-<li>If ASDF isn't loaded yet, then <code>(require "asdf")</code>
-should load the version of ASDF that is bundled with your system.
-If possible so should <code>(require "ASDF")</code>.
</span><span style="color: #000000;background-color: #ddffdd">+it’s a bug that you should report upstream and that we will fix ASAP.
+</p>
+<p>As to how to include ASDF, we recommend the following:
+</p>
+<ul>
+<li> If ASDF isn’t loaded yet, then <code>(require "asdf")</code>
+should load the version of ASDF that is bundled with your system.
+If possible so should <code>(require "ASDF")</code>.
</span> You may have it load some other version configured by the user,
if you allow such configuration.
<span style="color: #000000;background-color: #ffdddd">- <li>If your system provides a mechanism to hook into <code>CL:REQUIRE</code>,
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If your system provides a mechanism to hook into <code>cl:require</code>,
</span> then it would be nice to add ASDF to this hook the same way that
<span style="color: #000000;background-color: #ffdddd">-ABCL, CCL, CLISP, CMUCL, ECL, SBCL and SCL do it.
</span><span style="color: #000000;background-color: #ddffdd">+ABCL, CCL, CLISP, CMUCL, ECL, SBCL and SCL do it.
</span> Please send us appropriate code to this end.
<span style="color: #000000;background-color: #ffdddd">- <li>You may, like SBCL, have ASDF be implicitly used to require systems
-that are bundled with your Lisp distribution.
-If you do have a few magic systems that come with your implementation
-in a precompiled way such that one should only use the binary version
-that goes with your distribution, like SBCL does,
-then you should add them in the beginning of <code>wrapping-source-registry</code>.
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> You may, like SBCL since 1.1.13 or MKCL since 1.1.9,
+have ASDF create bundle FASLs
+that are provided as modules by your Lisp distribution.
+You may also, but we don’t recommend that anymore,
+as in SBCL up until 1.1.12, have ASDF be implicitly used
+to <code>cl:require</code> these modules that are provided by your Lisp distribution;
+if you do, you should add these modules in the beginning of both
+<code>wrapping-source-registry</code> and <code>wrapping-output-translations</code>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>If you have magic systems as above, like SBCL does,
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If you have magic systems as above, like SBCL used to do,
</span> then we explicitly ask you to <em>NOT</em> distribute
<span style="color: #000000;background-color: #ffdddd">-<samp><span class="file">asdf.asd</span></samp> as part of those magic systems.
-You should still include the file <samp><span class="file">asdf.lisp</span></samp> in your source distribution
</span><span style="color: #000000;background-color: #ddffdd">+<samp>asdf.asd</samp> as part of those magic systems.
+You should still include the file <samp>asdf.lisp</samp> in your source distribution
</span> and precompile it in your binary distribution,
<span style="color: #000000;background-color: #ffdddd">-but <samp><span class="file">asdf.asd</span></samp> if included at all,
</span><span style="color: #000000;background-color: #ddffdd">+but <samp>asdf.asd</samp> if included at all,
</span> should be secluded from the magic systems,
<span style="color: #000000;background-color: #ffdddd">-in a separate file hierarchy.
</span><span style="color: #000000;background-color: #ddffdd">+in a separate file hierarchy.
</span> Alternatively, you may provide the system
<span style="color: #000000;background-color: #ffdddd">-after renaming it and its <samp><span class="file">.asd</span></samp> file to e.g.
-<code>asdf-ecl</code> and <samp><span class="file">asdf-ecl.asd</span></samp>, or
-<code>sb-asdf</code> and <samp><span class="file">sb-asdf.asd</span></samp>.
-Indeed, if you made <samp><span class="file">asdf.asd</span></samp> a magic system,
</span><span style="color: #000000;background-color: #ddffdd">+after renaming it and its <samp>.asd</samp> file to e.g.
+<code>asdf-ecl</code> and <samp>asdf-ecl.asd</samp>, or
+<code>sb-asdf</code> and <samp>sb-asdf.asd</samp>.
+Indeed, if you made <samp>asdf.asd</samp> a magic system,
</span> then users would no longer be able to upgrade ASDF using ASDF itself
to some version of their preference that
they maintain independently from your Lisp distribution.
<span style="color: #000000;background-color: #ffdddd">- <li>If you do not have any such magic systems, or have other non-magic systems
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> If you do not have any such magic systems, or have other non-magic systems
</span> that you want to bundle with your implementation,
then you may add them to the <code>wrapping-source-registry</code>,
<span style="color: #000000;background-color: #ffdddd">-and you are welcome to include <samp><span class="file">asdf.asd</span></samp> amongst them.
</span><span style="color: #000000;background-color: #ddffdd">+and you are welcome to include <samp>asdf.asd</samp> amongst them.
</span> Non-magic systems should be at the back of the <code>wrapping-source-registry</code>
while magic systems are at the front.
<span style="color: #000000;background-color: #ddffdd">+If they are precompiled,
+they should also be in the <code>wrapping-output-translations</code>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>Please send us upstream any patches you make to ASDF itself,
</span><span style="color: #000000;background-color: #ddffdd">+</li><li> Since ASDF 3, the library UIOP comes transcluded in ASDF.
+But if you want to be nice to users who care for UIOP but not for ASDF,
+you may package UIOP separately,
+so that one may <code>(require "uiop")</code> and not load ASDF,
+or one may <code>(require "asdf")</code>
+which would implicitly require and load the former.
+
+</li><li> Please send us upstream any patches you make to ASDF itself,
</span> so we can merge them back in for the benefit of your users
when they upgrade to the upstream version.
<span style="color: #000000;background-color: #ffdddd">- </ul>
</span><span style="color: #000000;background-color: #ddffdd">+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">12.4 Issues with configuring ASDF</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.4.1 “How can I customize where fasl files are stored?”</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>See <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a>.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Issues-with-configuring-ASDF"></a>
+<a name="Issues-with-configuring-ASDF-1"></a>
+<h3 class="section">13.5 Issues with configuring ASDF</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>Note that in the past there was an add-on to ASDF called
-<code>ASDF-binary-locations</code>, developed by Gary King.
</span><span style="color: #000000;background-color: #ddffdd">+
+<hr>
+<a name="How-can-I-customize-where-fasl-files-are-stored_003f"></a>
+<a name="g_t_0060_0060How-can-I-customize-where-fasl-files-are-stored_003f_0027_0027"></a>
+<h4 class="subsection">13.5.1 “How can I customize where fasl files are stored?”</h4>
+
+<p>See <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a>.
+</p>
+<p>Note that in the past there was an add-on to ASDF called
+<code>ASDF-binary-locations</code>, developed by Gary King.
</span> That add-on has been merged into ASDF proper,
then superseded by the <code>asdf-output-translations</code> facility.
<span style="color: #000000;background-color: #ffdddd">-
- <p>Note that use of <code>asdf-output-translations</code>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>Note that use of <code>asdf-output-translations</code>
</span> can interfere with one aspect of your systems
— if your system uses <code>*load-truename*</code> to find files
(e.g., if you have some data files stored with your program),
then the relocation that this ASDF customization performs
<span style="color: #000000;background-color: #ffdddd">-is likely to interfere.
</span><span style="color: #000000;background-color: #ddffdd">+is likely to interfere.
</span> Use <code>asdf:system-relative-pathname</code> to locate a file
in the source directory of some system, and
use <code>asdf:apply-output-translations</code> to locate a file
whose pathname has been translated by the facility.
<span style="color: #000000;background-color: #ffdddd">-
-<h4 class="subsection">12.4.2 “How can I wholly disable the compiler output cache?”</h4>
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<hr>
+<a name="How-can-I-wholly-disable-the-compiler-output-cache_003f"></a>
+<a name="g_t_0060_0060How-can-I-wholly-disable-the-compiler-output-cache_003f_0027_0027"></a>
+<h4 class="subsection">13.5.2 “How can I wholly disable the compiler output cache?”</h4>
</span>
<p>To permanently disable the compiler output cache
for all future runs of ASDF, you can:
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="example">
+<pre class="example">mkdir -p ~/.config/common-lisp/asdf-output-translations.conf.d/
+echo ':disable-cache' > \
+~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> mkdir -p ~/.config/common-lisp/asdf-output-translations.conf.d/
- echo ':disable-cache' > ~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf
-</pre>
- <p>This assumes that you didn't otherwise configure the ASDF files
</span><span style="color: #000000;background-color: #ddffdd">+<p>This assumes that you didn’t otherwise configure the ASDF files
</span> (if you did, edit them again),
<span style="color: #000000;background-color: #ffdddd">-and don't somehow override the configuration at runtime
</span><span style="color: #000000;background-color: #ddffdd">+and don’t somehow override the configuration at runtime
</span> with a shell variable (see below) or some other runtime command
(e.g. some call to <code>asdf:initialize-output-translations</code>).
<span style="color: #000000;background-color: #ffdddd">-
- <p>To disable the compiler output cache in Lisp processes
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>To disable the compiler output cache in Lisp processes
</span> run by your current shell, try (assuming <code>bash</code> or <code>zsh</code>)
(on Unix and cygwin only):
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="example">
+<pre class="example">export ASDF_OUTPUT_TRANSLATIONS=/:
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> export ASDF_OUTPUT_TRANSLATIONS=/:
-</pre>
- <p>To disable the compiler output cache just in the current Lisp process,
</span><span style="color: #000000;background-color: #ddffdd">+<p>To disable the compiler output cache just in the current Lisp process,
</span> use (after loading ASDF but before using it):
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="example">
+<pre class="example">(asdf:disable-output-translations)
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="example"> (asdf:disable-output-translations)
-</pre>
- <h3 class="section">12.5 Issues with using and extending ASDF to define systems</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<p>Note that this does <em>NOT</em> belong in a <samp>.asd</samp> file.
+Please do not tamper with ASDF configuration from a <samp>.asd</samp> file,
+and only do this from your personal configuration or build scripts.
+</p>
+<hr>
+<a name="Issues-with-using-and-extending-ASDF-to-define-systems"></a>
+<a name="Issues-with-using-and-extending-ASDF-to-define-systems-1"></a>
+<h3 class="section">13.6 Issues with using and extending ASDF to define systems</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.5.1 “How can I cater for unit-testing in my system?”</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>ASDF provides a predefined test operation, <code>test-op</code>.
-See <a href="#Predefined-operations-of-ASDF">test-op</a>.
-The test operation, however, is largely left to the system definer to specify.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="How-can-I-cater-for-unit_002dtesting-in-my-system_003f"></a>
+<a name="g_t_0060_0060How-can-I-cater-for-unit_002dtesting-in-my-system_003f_0027_0027"></a>
+<h4 class="subsection">13.6.1 “How can I cater for unit-testing in my system?”</h4>
+
+<p>ASDF provides a predefined test operation, <code>test-op</code>.
+See <a href="#Predefined-operations-of-ASDF">test-op</a>.
+The test operation, however, is largely left to the system definer to specify.
</span> <code>test-op</code> has been
a topic of considerable discussion on the
<span style="color: #000000;background-color: #ffdddd">-<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel">asdf-devel mailing list</a>,
</span><span style="color: #000000;background-color: #ddffdd">+<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel">asdf-devel mailing list</a>
+(see <a href="#Mailing-list">Mailing list</a>),
</span> and on the
<span style="color: #000000;background-color: #ffdddd">-<a href="https://launchpad.net/asdf">launchpad bug-tracker</a>.
-
- <p>Here are some guidelines:
-
- <ul>
-<li>For a given system, <var>foo</var>, you will want to define a corresponding
-test system, such as <var>foo-test</var>. The reason that you will want this
-separate system is that ASDF does not out of the box supply components
-that are conditionally loaded. So if you want to have source files
-(with the test definitions) that will not be loaded except when testing,
-they should be put elsewhere.
-
- <li>The <var>foo-test</var> system can be defined in an asd file of its own or
-together with <var>foo</var>. An aesthetic preference against cluttering up
-the filesystem with extra asd files should be balanced against the
-question of whether one might want to directly load <var>foo-test</var>.
-Typically one would not want to do this except in early stages of
-debugging.
-
- <li>Record that testing is implemented by <var>foo-test</var>. For example:
- <pre class="example"> (defsystem <var>foo</var>
- :in-order-to ((test-op (test-op <var>foo-test</var>)))
- ....)
-
- (defsystem <var>foo-test</var>
- :depends-on (<var>foo</var> <var>my-test-library</var> ...)
- ....)
-</pre>
- </ul>
</span><span style="color: #000000;background-color: #ddffdd">+<a href="https://launchpad.net/asdf">launchpad bug-tracker</a> (see <a href="#Where-do-I-report-a-bug_003f">Where do I report a bug?</a>).
+We provide some guidelines in the discussion of <code>test-op</code>.
+</p>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>This procedure will allow you to support users who do not wish to
-install your test framework.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>One oddity of ASDF is that <code>operate</code> (see <a href="#Operations">operate</a>)
-does not return a value. So in current versions of ASDF there is no
-reliable programmatic means of determining whether or not a set of tests
-has passed, or which tests have failed. The user must simply read the
-console output. This limitation has been the subject of much
-discussion.
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.5.2 “How can I cater for documentation generation in my system?”</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>The ASDF developers are currently working to add a <code>doc-op</code>
-to the set of predefined ASDF operations.
-See <a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a>.
-See also <a href="https://bugs.launchpad.net/asdf/+bug/479470">https://bugs.launchpad.net/asdf/+bug/479470</a>.
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.5.3 “How can I maintain non-Lisp (e.g. C) source files?”</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>See <code>cffi</code>'s <code>cffi-grovel</code>.
</span>
<span style="color: #000000;background-color: #ffdddd">- <p><a name="report_002dbugs"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="How-can-I-cater-for-documentation-generation-in-my-system_003f"></a>
+<a name="g_t_0060_0060How-can-I-cater-for-documentation-generation-in-my-system_003f_0027_0027"></a>
+<h4 class="subsection">13.6.2 “How can I cater for documentation generation in my system?”</h4>
+
+<p>Various ASDF extensions provide some kind of <code>doc-op</code> operation.
+See also <a href="https://bugs.launchpad.net/asdf/+bug/479470">https://bugs.launchpad.net/asdf/+bug/479470</a>.
+</p>
+
+<hr>
+<a name="How-can-I-maintain-non_002dLisp-_0028e_002eg_002e-C_0029-source-files_003f"></a>
+<a name="g_t_0060_0060How-can-I-maintain-non_002dLisp-_0028e_002eg_002e-C_0029-source-files_003f_0027_0027"></a>
+<h4 class="subsection">13.6.3 “How can I maintain non-Lisp (e.g. C) source files?”</h4>
+
+<p>See <code>cffi</code>’s <code>cffi-grovel</code>.
+</p>
+<a name="report_002dbugs"></a>
</span>
<span style="color: #000000;background-color: #ffdddd">-<h4 class="subsection">12.5.4 “I want to put my module's files at the top level. How do I do this?”</h4>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="I-want-to-put-my-module_0027s-files-at-the-top-level_002e-How-do-I-do-this_003f"></a>
+<a name="g_t_0060_0060I-want-to-put-my-module_0027s-files-at-the-top-level_002e-How-do-I-do-this_003f_0027_0027"></a>
+<h4 class="subsection">13.6.4 “I want to put my module’s files at the top level. How do I do this?”</h4>
</span>
<p>By default, the files contained in an asdf module go
<span style="color: #000000;background-color: #ffdddd">-in a subdirectory with the same name as the module.
-However, this can be overridden by adding a <code>:pathname ""</code> argument
-to the module description.
</span><span style="color: #000000;background-color: #ddffdd">+in a subdirectory with the same name as the module.
+However, this can be overridden by adding a <code>:pathname ""</code> argument
+to the module description.
</span> For example, here is how it could be done
<span style="color: #000000;background-color: #ffdddd">-in the spatial-trees ASDF system definition for ASDF 2:
-
-<pre class="example"> (asdf:defsystem :spatial-trees
- :components
- ((:module base
- :pathname ""
- :components
- ((:file "package")
- (:file "basedefs" :depends-on ("package"))
- (:file "rectangles" :depends-on ("package"))))
- (:module tree-impls
- :depends-on (base)
- :pathname ""
- :components
- ((:file "r-trees")
- (:file "greene-trees" :depends-on ("r-trees"))
- (:file "rstar-trees" :depends-on ("r-trees"))
- (:file "rplus-trees" :depends-on ("r-trees"))
- (:file "x-trees" :depends-on ("r-trees" "rstar-trees"))))
- (:module viz
- :depends-on (base)
- :pathname ""
- :components
- ((:static-file "spatial-tree-viz.lisp")))
- (:module tests
- :depends-on (base)
- :pathname ""
- :components
- ((:static-file "spatial-tree-test.lisp")))
- (:static-file "LICENCE")
- (:static-file "TODO")))
-</pre>
- <p>All of the files in the <code>tree-impls</code> module are at the top level,
-instead of in a <samp><span class="file">tree-impls/</span></samp> subdirectory.
-
- <p>Note that the argument to <code>:pathname</code> can be either a pathname object or a string.
-A pathname object can be constructed with the <samp><span class="file">#p"foo/bar/"</span></samp> syntax,
-but this is discouraged because the results of parsing a namestring are not portable.
</span><span style="color: #000000;background-color: #ddffdd">+in the spatial-trees ASDF system definition for ASDF 2 or later:
+</p>
+<div class="example">
+<pre class="example">(asdf:defsystem "spatial-trees"
+ :components
+ ((:module "base"
+ :pathname ""
+ :components
+ ((:file "package")
+ (:file "basedefs" :depends-on ("package"))
+ (:file "rectangles" :depends-on ("package"))))
+ (:module tree-impls
+ :depends-on ("base")
+ :pathname ""
+ :components
+ ((:file "r-trees")
+ (:file "greene-trees" :depends-on ("r-trees"))
+ (:file "rstar-trees" :depends-on ("r-trees"))
+ (:file "rplus-trees" :depends-on ("r-trees"))
+ (:file "x-trees" :depends-on ("r-trees" "rstar-trees"))))
+ (:module viz
+ :depends-on ("base")
+ :pathname ""
+ :components
+ ((:static-file "spatial-tree-viz.lisp")))
+ (:module tests
+ :depends-on ("base")
+ :pathname ""
+ :components
+ ((:static-file "spatial-tree-test.lisp")))
+ (:static-file "LICENCE")
+ (:static-file "TODO")))
+</pre></div>
+
+<p>All of the files in the <code>tree-impls</code> module are at the top level,
+instead of in a <samp>tree-impls/</samp> subdirectory.
+</p>
+<p>Note that the argument to <code>:pathname</code> can be either a pathname object or a string.
+A pathname object can be constructed with the <samp>#p"foo/bar/"</samp> syntax,
+but this is discouraged because the results of parsing a namestring are not portable.
</span> A pathname can only be portably constructed with such syntax as
<span style="color: #000000;background-color: #ffdddd">-<code>#.(make-pathname :directory '(:relative "foo" "bar"))</code>,
</span><span style="color: #000000;background-color: #ddffdd">+<code>#.(make-pathname :directory '(:relative "foo" "bar"))</code>,
</span> and similarly the current directory can only be portably specified as
<span style="color: #000000;background-color: #ffdddd">-<code>#.(make-pathname :directory '(:relative))</code>.
-However, as of ASDF 2, you can portably use a string to denote a pathname.
</span><span style="color: #000000;background-color: #ddffdd">+<code>#.(make-pathname :directory '(:relative))</code>.
+However, as of ASDF 2, you can portably use a string to denote a pathname.
</span> The string will be parsed as a <code>/</code>-separated path from the current directory,
<span style="color: #000000;background-color: #ffdddd">-such that the empty string <code>""</code> denotes the current directory, and
-<code>"foo/bar"</code> (no trailing <code>/</code> required in the case of modules)
-portably denotes the same subdirectory as above.
</span><span style="color: #000000;background-color: #ddffdd">+such that the empty string <code>""</code> denotes the current directory, and
+<code>"foo/bar"</code> (no trailing <code>/</code> required in the case of modules)
+portably denotes the same subdirectory as above.
</span> When files are specified, the last <code>/</code>-separated component is interpreted
either as the name component of a pathname
(if the component class specifies a pathname type),
or as a name component plus optional dot-separated type component
<span style="color: #000000;background-color: #ffdddd">-(if the component class doesn't specifies a pathname type).
-
-<h4 class="subsection">12.5.5 How do I create a system definition where all the source files have a .cl extension?</h4>
</span><span style="color: #000000;background-color: #ddffdd">+(if the component class doesn’t specifies a pathname type).
+</p>
+<hr>
+<a name="How-do-I-create-a-system-definition-where-all-the-source-files-have-a-_002ecl-extension_003f"></a>
+<a name="How-do-I-create-a-system-definition-where-all-the-source-files-have-a-_002ecl-extension_003f-1"></a>
+<h4 class="subsection">13.6.5 How do I create a system definition where all the source files have a .cl extension?</h4>
</span>
<p>Starting with ASDF 2.014.14, you may just pass
the builtin class <code>cl-source-file.cl</code> as
the <code>:default-component-class</code> argument to <code>defsystem</code>:
<span style="color: #000000;background-color: #ffdddd">-
-<pre class="lisp"> (defsystem my-cl-system
- :default-component-class cl-source-file.cl
- ...)
-</pre>
- <p>Another builtin class <code>cl-source-file.lsp</code> is offered
-for files ending in <samp><span class="file">.lsp</span></samp>.
-
- <p>If you want to use a different extension
-for which ASDF doesn't provide builtin support,
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">(defsystem my-cl-system
+ :default-component-class cl-source-file.cl
+ ...)
+</pre></div>
+
+<p>Another builtin class <code>cl-source-file.lsp</code> is offered
+for files ending in <samp>.lsp</samp>.
+</p>
+<p>If you want to use a different extension
+for which ASDF doesn’t provide builtin support,
</span> or want to support versions of ASDF
earlier than 2.014.14 (but later than 2.000),
you can define a class as follows:
<span style="color: #000000;background-color: #ffdddd">-
-<pre class="lisp"> ;; Prologue: make sure we're using a sane package.
- (defpackage :my-asdf-extension
- (:use :asdf :common-lisp)
- (:export #:cl-source-file.lis))
- (in-package :my-asdf-extension)
-
- (defclass cl-source-file.lis (cl-source-file)
- ((type :initform "lis")))
-</pre>
- <p>Then you can use it as follows:
-<pre class="lisp"> (defsystem my-cl-system
- :default-component-class my-asdf-extension:cl-source-file.lis
- ...)
-</pre>
- <p>Of course, if you're in the same package, e.g. in the same file,
-you won't need to use the package qualifier before <code>cl-source-file.lis</code>.
-Actually, if all you're doing is defining this class
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">;; Prologue: make sure we're using a sane package.
+(defpackage :my-asdf-extension
+ (:use :asdf :common-lisp)
+ (:export #:cl-source-file.lis))
+(in-package :my-asdf-extension)
+
+(defclass cl-source-file.lis (cl-source-file)
+ ((type :initform "lis")))
+</pre></div>
+
+<p>Then you can use it as follows:
+</p><div class="lisp">
+<pre class="lisp">(defsystem my-cl-system
+ :default-component-class my-asdf-extension:cl-source-file.lis
+ ...)
+</pre></div>
+
+<p>Of course, if you’re in the same package, e.g. in the same file,
+you won’t need to use the package qualifier before <code>cl-source-file.lis</code>.
+Actually, if all you’re doing is defining this class
</span> and using it in the same file without other fancy definitions,
you might skip package complications:
<span style="color: #000000;background-color: #ddffdd">+</p>
+<div class="lisp">
+<pre class="lisp">(in-package :asdf)
+(defclass cl-source-file.lis (cl-source-file)
+ ((type :initform "lis")))
+(defsystem my-cl-system
+ :default-component-class cl-source-file.lis
+ ...)
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-<pre class="lisp"> (in-package :asdf)
- (defclass cl-source-file.lis (cl-source-file)
- ((type :initform "lis")))
- (defsystem my-cl-system
- :default-component-class cl-source-file.lis
- ...)
-</pre>
- <p>It is possible to achieve the same effect
-in a way that supports both ASDF 1 and ASDF 2,
-but really, friends don't let friends use ASDF 1.
-Please upgrade to ASDF 3.
-In short, though: do same as above, but
-<em>before</em> you use the class in a <code>defsystem</code>,
-you also define the following method:
-
-<pre class="lisp"> (defmethod source-file-type ((f cl-source-file.lis) (s system))
- (declare (ignorable f s))
- "lis")
-</pre>
- <!-- FIXME: Add a FAQ about how to use a new system class... -->
-<p><a name="TODO-list"></a>
-
-<!-- node-name, next, previous, up -->
-<h2 class="chapter">13 TODO list</h2>
-
-<p>Here is an old list of things to do,
-in addition to the bugs that are now tracked on launchpad:
-<a href="https://launchpad.net/asdf">https://launchpad.net/asdf</a>.
-
-<h3 class="section">13.1 Outstanding spec questions, things to add</h3>
-
-<p>** packaging systems
-
- <p>*** manual page component?
-
- <p>** style guide for .asd files
-
- <p>You should either use keywords or be careful
-with the package that you evaluate defsystem forms in.
-Otherwise <code>(defsystem partition ...)</code>
-being read in the <code>cl-user</code> package
-will intern a <code>cl-user:partition</code> symbol,
-which will then collide with the <code>partition:partition</code> symbol.
-
- <p>Actually there's a hairier packages problem to think about too.
-<code>in-order-to</code> is not a keyword:
-if you read <code>defsystem</code> forms in a package that doesn't use ASDF,
-odd things might happen.
-
- <p>** extending defsystem with new options
-
- <p>You might not want to write a whole parser,
-but just to add options to the existing syntax.
-Reinstate <code>parse-option</code> or something akin.
-
- <p>** Diagnostics
-
- <p>A “dry run” of an operation can be made with the following form:
-
-<pre class="lisp"> (let ((asdf::*verbose-out* *standard-output*))
- (loop :for (op . comp) :in
- (asdf::traverse (make-instance '<operation-name> :force t)
- (asdf:find-system <system-name>))
- :do (asdf:explain op comp)))
-</pre>
- <p>This uses unexported symbols.
-What would be a nice interface for this functionality?
-
-<h3 class="section">13.2 Missing bits in implementation</h3>
-
-<p>** reuse the same scratch package whenever a system is reloaded from disk
-
- <p>Have a package ASDF-USER instead of all these temporary packages?
-
- <p>** proclamations probably aren't
-
- <p>** A revert function
-
- <p>Other possible interface: have a “revert” function akin to <code>make clean</code>.
-
-<pre class="lisp"> (asdf:revert 'asdf:compile-op 'araneida)
-</pre>
- <p>would delete any files produced by <code>(compile-system :araneida)</code>.
-Of course, it wouldn't be able to do much about stuff in the image itself.
-
- <p>How would this work?
-
- <p><code>traverse</code>
-
- <p>There's a difference between a module's dependencies (peers)
-and its components (children).
-Perhaps there's a similar difference in operations?
-For example, <code>(load "use") depends-on (load "macros")</code> is a peer,
-whereas <code>(load "use") depends-on (compile "use")</code>
-is more of a “subservient” relationship.
-
-<p><a name="Inspiration"></a>
-
-<!-- node-name, next, previous, up -->
-<h2 class="chapter">14 Inspiration</h2>
-
-<h3 class="section">14.1 mk-defsystem (defsystem-3.x)</h3>
-
-<p>We aim to solve basically the same problems as <code>mk-defsystem</code> does.
-However, our architecture for extensibility
-better exploits CL language features (and is documented),
-and we intend to be portable rather than just widely-ported.
-No slight on the <code>mk-defsystem</code> authors and maintainers is intended here;
-that implementation has the unenviable task
-of supporting pre-ANSI implementations, which is no longer necessary.
-
- <p>The surface defsystem syntax of asdf is more-or-less compatible with
-<code>mk-defsystem</code>, except that we do not support
-the <code>source-foo</code> and <code>binary-foo</code> prefixes
-for separating source and binary files, and
-we advise the removal of all options to specify pathnames.
-
- <p>The <code>mk-defsystem</code> code for topologically sorting
-a module's dependency list was very useful.
-
-<h3 class="section">14.2 defsystem-4 proposal</h3>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="How-do-I-mark-a-source-file-to-be-loaded-only-and-not-compiled_003f"></a>
+<a name="How-do-I-mark-a-source-file-to-be-loaded-only-and-not-compiled_003f-1"></a>
+<h4 class="subsection">13.6.6 How do I mark a source file to be loaded only and not compiled?</h4>
+
+<p>There is no provision in ASDF for ensuring that
+some components are always loaded as source, while others are always
+compiled.
+There is <code>load-source-op</code> (see <a href="#Predefined-operations-of-ASDF">load-source-op</a>), but that is an operation to be applied to a
+system as a whole, not to one or another specific source files.
+While this idea often comes up in discussions,
+it doesn’t play well with either the linking model of ECL
+or with various bundle operations.
+In addition, the dependency model of ASDF would have to be modified incompatibly
+to allow for such a trick.
+</p>
+<hr>
+<a name="How-do-I-work-with-readtables_003f"></a>
+<a name="How-do-I-work-with-readtables_003f-1"></a>
+<h4 class="subsection">13.6.7 How do I work with readtables?</h4>
+
+<a name="index-readtables"></a>
+
+<p>It is possible to configure the lisp syntax by modifying the currently-active readtable.
+However, this same readtable is shared globally by all software being compiled by ASDF,
+especially since <code>load</code> and <code>compile-file</code> both bind <var>*readtable*</var>,
+so that its value is the same across the build at the start of every file
+(unless overridden by some <code>perform :around</code> method),
+even if a file locally binds it to a different readtable during the build.
+</p>
+<p>Therefore, the following hygiene restrictions apply. If you don’t abide by these restrictions,
+there will be situations where your output files will be corrupted during an incremental build.
+We are not trying to prescribe new restrictions for the sake of good style:
+these restrictions have always applied implicitly, and
+we are simply describing what they have always been.
+</p>
+<ul>
+<li> It is forbidden to modifying any standard character or standard macro dispatch defined in the CLHS.
+</li><li> No two dependencies may assign different meanings to the same non-standard character.
+</li><li> Using any non-standard character while expecting the implementation to treat some way
+ counts as such an assignment of meaning.
+</li><li> libraries need to document these assignments of meaning to non-standard characters.
+</li><li> free software libraries will register these changes on:
+ <a href="http://www.cliki.net/Macro%20Characters">http://www.cliki.net/Macro%20Characters</a>
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Marco and Peter's proposal for defsystem 4 served as the driver for
-many of the features in here. Notable differences are:
</span><span style="color: #000000;background-color: #ddffdd">+<p>If you want to use readtable modifications that cannot abide by those restrictions,
+you <em>must</em> create a different readtable object and set <var>*readtable*</var>
+to temporarily bind it to your new readtable (which will be undone after processing the file).
+</p>
+<p>For that, we recommend you use system <code>named-readtables</code>
+to define or combine such readtables using <code>named-readtables:defreadtable</code>
+and use them using <code>named-readtables:in-readtable</code>.
+Equivalently, you can use system <code>cl-syntax</code>,
+that itself uses <code>named-readtables</code>,
+but may someday do more with, e.g. <var>*print-pprint-dispatch*</var>.
+</p>
+<p>For even more advanced syntax modification beyond what a readtable can express,
+you may consider either:
+</p><ul>
+<li> a <code>perform</code> method that compiles a constant file that contains a single form
+ <code>#.*code-read-with-alternate-reader*</code> in an environment where this special variable
+ was bound to the code read by your alternate reader, or
+</li><li> using the system <code>reader-interception</code>.
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">- <ul>
-<li>We don't specify output files or output file extensions
-as part of the system.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Beware that it is unsafe to use ASDF from the REPL to compile or load systems
+while the readtable isn’t the shared readtable previously used to build software.
+You <em>must</em> manually undo any binding of <var>*readtable*</var> at the REPL
+and restore its initial value whenever you call <code>operate</code>
+(via e.g. <code>load-system</code>, <code>test-system</code> or <code>require</code>)
+from a REPL that is using a different readtable.
+</p>
+<a name="How-should-my-system-use-a-readtable-exported-by-another-system_003f"></a>
+<h4 class="subsubsection">13.6.7.1 How should my system use a readtable exported by another system?</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If you want to find out what files an operation would create,
-ask the operation.
</span><span style="color: #000000;background-color: #ddffdd">+<p>Use from the <code>named-readtables</code> system the macro <code>named-readtables:in-readtable</code>.
+</p>
+<p>If the other system fails to use <code>named-readtables</code>, fix it and send a patch upstream.
+In the day and age of Quicklisp and clbuild, there is little reason
+to eschew using such an important library anymore.
+</p>
+<a name="How-should-my-library-make-a-readtable-available-to-other-systems_003f"></a>
+<h4 class="subsubsection">13.6.7.2 How should my library make a readtable available to other systems?</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>We don't deal with CL packages
</span><span style="color: #000000;background-color: #ddffdd">+<p>Use from the <code>named-readtables</code> system the macro <code>named-readtables:defreadtable</code>.
+</p>
+<hr>
+<a name="ASDF-development-FAQs"></a>
+<a name="ASDF-development-FAQs-1"></a>
+<h3 class="section">13.7 ASDF development FAQs</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>If you want to compile in a particular package, use an <code>in-package</code> form
-in that file (ilisp / SLIME will like you more if you do this anyway)
</span>
<span style="color: #000000;background-color: #ffdddd">- <li>There is no proposal here that <code>defsystem</code> does version control.
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="How-do-I-run-the-tests-interactively-in-a-REPL_003f"></a>
+<a name="How-do-I-run-the-tests-interactively-in-a-REPL_003f-1"></a>
+<h4 class="subsection">13.7.1 How do I run the tests interactively in a REPL?</h4>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>A system has a given version which can be used to check dependencies,
-but that's all.
-</ul>
</span><span style="color: #000000;background-color: #ddffdd">+<p>This not-so-frequently asked question is primarily for ASDF developers,
+but those who encounter an unexpected error in some test may be
+interested, too.
+</p>
+<p>Here’s the procedure for experimenting with tests in a REPL:
+</p><div class="example">
+<pre class="example">;; BEWARE! Some tests expect you to be in the .../asdf/test directory
+;; If your REPL is not there yet, change your current directory:
+;; under SLIME, you may: ,change-directory ~/common-lisp/asdf/test/
+;; otherwise you may evaluate something like:
+(require "asdf") (asdf:upgrade-asdf) ;load UIOP & update asdf.lisp
+(uiop:chdir (asdf:system-relative-pathname :asdf "test/"))
+(setf *default-pathname-defaults* (uiop:getcwd))
+
+;; Load the test script support.
+(load "script-support.lisp")
+
+;; Initialize the script support.
+;; This will also change your *package* to asdf-test.
+;; NB: this function is also available from package cl-user,
+;; and also available with the shorter name da in both packages.
+(asdf-test::debug-asdf)
+
+;; In case you modified ASDF since you last tested it,
+;; you need to update asdf.lisp itself by evaluating 'make' in a shell,
+;; or (require "asdf") (asdf:load-system :asdf) in another CL REPL,
+;; if not done in this REPL above.
+;; *Then*, in this REPL, you need to evaluate:
+;(asdf-test::compile-load-asdf)
+
+;; Now, you may experiment with test code from a .script file.
+;; See the instructions given at the end of your failing test
+;; to identify which form is needed, e.g.
+(frob-packages)
+(asdf::with-asdf-cache () (load "test-utilities.script"))
+</pre></div>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>The defsystem 4 proposal tends to look more at the external features,
-whereas this one centres on a protocol for system introspection.
</span>
<span style="color: #000000;background-color: #ffdddd">-<h3 class="section">14.3 kmp's “The Description of Large Systems”, MIT AI Memo 801</h3>
</span>
<span style="color: #000000;background-color: #ffdddd">-<p>Available in updated-for-CL form on the web at
-<a href="http://nhplace.com/kent/Papers/Large-Systems.html">http://nhplace.com/kent/Papers/Large-Systems.html</a>
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Ongoing-Work"></a>
+<a name="Ongoing-Work-1"></a>
+<h2 class="unnumbered">Ongoing Work</h2>
+<p>For an active list of things to be done,
+see the <samp>TODO</samp> file in the source repository.
+</p>
+<p>Also, bugs are currently tracked on launchpad:
+<a href="https://launchpad.net/asdf">https://launchpad.net/asdf</a>.
+</p>
+<hr>
+<a name="Bibliography"></a>
+<a name="Bibliography-1"></a>
+<h2 class="unnumbered">Bibliography</h2>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p>In our implementation we borrow kmp's overall <code>PROCESS-OPTIONS</code>
-and concept to deal with creating component trees
-from <code>defsystem</code> surface syntax.
-[ this is not true right now, though it used to be and
-probably will be again soon ]
</span><span style="color: #000000;background-color: #ddffdd">+<ul>
+<li> Francois-Rene Rideau:
+ “ASDF 3, or Why Lisp is Now an Acceptable Scripting Language”, 2014.
+ This article describes the innovations in ASDF 3 and 3.1,
+ as well as historical information on previous versions.
+ <a href="https://github.com/fare/asdf3-2013">https://github.com/fare/asdf3-2013</a>
+</li><li> Alastair Bridgewater:
+ “Quick-build” (private communication), 2012.
+ <code>quick-build</code> is a simple and robust one file, one package build system,
+ similar to <code>faslpath</code>, in 182 lines of code
+ (117 of which are not blank, not comments, not docstrings).
+ Unhappily, it remains unpublished and its IP status is unclear as of April 2014.
+ <code>asdf/package-system</code> is mostly compatible with it,
+ modulo a different setup for toplevel hierarchies.
+</li><li> Zach Beane:
+ “Quicklisp”, 2011.
+ The Quicklisp blog and Xach’s livejournal contain information on Quicklisp.
+ <a href="http://blog.quicklisp.org/">http://blog.quicklisp.org/</a>
+ <a href="http://xach.livejournal.com/">http://xach.livejournal.com/</a>
+</li><li> Francois-Rene Rideau and Robert Goldman:
+ “Evolving ASDF: More Cooperation, Less Coordination”, 2010.
+ This article describes the main issues solved by ASDF 2.
+ <a href="https://common-lisp.net/project/asdf/doc/ilc2010draft.pdf">https://common-lisp.net/project/asdf/doc/ilc2010draft.pdf</a>
+ <a href="https://gitlab.common-lisp.org/asdf/ilc2010">https://gitlab.common-lisp.org/asdf/ilc2010</a>
+</li><li> Francois-Rene Rideau and Spencer Brody:
+ “XCVB: an eXtensible Component Verifier and Builder for Common Lisp”, 2009.
+ This article describes XCVB, a proposed competitor for ASDF;
+ many of its ideas have been incorporated into ASDF 2 and 3,
+ though many other ideas still haven’t.
+ <a href="https://common-lisp.net/project/xcvb/">https://common-lisp.net/project/xcvb/</a>
+</li><li> Peter von Etter:
+ “faslpath”, 2009.
+ <code>faslpath</code> is similar to the latter <code>quick-build</code>
+ and our yet latter <code>asdf/package-system</code> extension,
+ except that it uses dot <code>.</code> rather than slash <code>/</code> as a separator.
+ <a href="https://code.google.com/p/faslpath/">https://code.google.com/p/faslpath/</a>
+</li><li> Drew McDermott:
+ “A Framework for Maintaining the Coherence of a Running Lisp,”
+ International Lisp Conference, 2005, available in pre-print form at
+ <a href="http://www.cs.yale.edu/homes/dvm/papers/lisp05.pdf">http://www.cs.yale.edu/homes/dvm/papers/lisp05.pdf</a>
+</li><li> Dan Barlow: “ASDF Manual”, 2004.
+ Older versions of this document from the days of ASDF 1;
+ they include ideas laid down by Dan Barlow,
+ and comparisons with older defsystems (<code>mk-defsystem</code>)
+ and defsystem (<code>defsystem-4</code>, kmp’s Memo 801).
+</li><li> Marco Antoniotti and Peter Van Eynde:
+ “<code>DEFSYSTEM</code>: A <code>make</code> for Common Lisp, A Thoughtful Re-Implementation of an Old Idea”, 2002.
+ The <samp>defsystem-4</samp> proposal available in the CLOCC repository.
+</li><li> Mark Kantrovitz: “Defsystem: A Portable Make Facility for Common Lisp”, 1990.
+ The classic <samp>mk-defsystem</samp>, later variants of which
+ are available in the CLOCC repository as <code>defsystem-3.x</code>.
+</li><li> Richard Elliot Robbins:
+ “BUILD: A Tool for Maintaining Consistency in Modular Systems”, MIT AI TR 874, 1985.
+ <a href="ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-874.pdf">ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-874.pdf</a>
+</li><li> Kent M. Pitman (kmp): “The Description of Large Systems”, MIT AI Memo 801, 1984.
+ Available in updated-for-CL form on the web at
+ <a href="http://nhplace.com/kent/Papers/Large-Systems.html">http://nhplace.com/kent/Papers/Large-Systems.html</a>
+</li><li> Dan Weinreb and David Moon:
+ “Lisp Machine Manual”, MIT, 1981.
+ The famous CHINE NUAL describes one of the earliest variants of DEFSYSTEM.
+ <a href="https://bitsavers.trailing-edge.com/pdf/mit/cadr/chinual_4thEd_Jul81.pdf">https://bitsavers.trailing-edge.com/pdf/mit/cadr/chinual_4thEd_Jul81.pdf</a>
+</li></ul>
</span>
<span style="color: #000000;background-color: #ffdddd">-<!-- -->
-<p><a name="Concept-Index"></a>
</span>
<span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Concept-Index"></a>
+<a name="Concept-Index-1"></a>
</span> <h2 class="unnumbered">Concept Index</h2>
<span style="color: #000000;background-color: #ffdddd">-<ul class="index-cp" compact>
-<li><a href="#index-g_t_003aaround_002dcompile-69">:around-compile</a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-g_t_003aasdf-5">:asdf</a>: <a href="#Introduction">Introduction</a></li>
-<li><a href="#index-g_t_003aasdf2-6">:asdf2</a>: <a href="#Introduction">Introduction</a></li>
-<li><a href="#index-g_t_003aasdf3-7">:asdf3</a>: <a href="#Introduction">Introduction</a></li>
-<li><a href="#index-g_t_003acompile_002dcheck-72">:compile-check</a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-g_t_003adefsystem_002ddepends_002don-21">:defsystem-depends-on</a>: <a href="#The-defsystem-grammar">The defsystem grammar</a></li>
-<li><a href="#index-g_t_003aversion-25">:version</a>: <a href="#The-defsystem-grammar">The defsystem grammar</a></li>
-<li><a href="#index-g_t_003aversion-46">:version</a>: <a href="#Common-attributes-of-components">Common attributes of components</a></li>
-<li><a href="#index-g_t_003aversion-20">:version</a>: <a href="#The-defsystem-form">The defsystem form</a></li>
-<li><a href="#index-g_t_003aweakly_002ddepends_002don-22">:weakly-depends-on</a>: <a href="#The-defsystem-grammar">The defsystem grammar</a></li>
-<li><a href="#index-around_002dcompile-keyword-70">around-compile keyword</a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-ASDF-versions-4">ASDF versions</a>: <a href="#Introduction">Introduction</a></li>
-<li><a href="#index-ASDF_002dBINARY_002dLOCATIONS-compatibility-58">ASDF-BINARY-LOCATIONS compatibility</a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
-<li><a href="#index-asdf_002doutput_002dtranslations-56">asdf-output-translations</a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
-<li><a href="#index-ASDF_002drelated-features-1">ASDF-related features</a>: <a href="#Introduction">Introduction</a></li>
-<li><a href="#index-compile_002dcheck-keyword-71">compile-check keyword</a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-component-38">component</a>: <a href="#Components">Components</a></li>
-<li><a href="#index-component-designator-41">component designator</a>: <a href="#Components">Components</a></li>
-<li><a href="#index-link-farm-9">link farm</a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-logical-pathnames-26">logical pathnames</a>: <a href="#The-defsystem-grammar">The defsystem grammar</a></li>
-<li><a href="#index-operation-28">operation</a>: <a href="#Operations">Operations</a></li>
-<li><a href="#index-pathname-specifiers-23">pathname specifiers</a>: <a href="#The-defsystem-grammar">The defsystem grammar</a></li>
-<li><a href="#index-serial-dependencies-27">serial dependencies</a>: <a href="#The-defsystem-grammar">The defsystem grammar</a></li>
-<li><a href="#index-system-39">system</a>: <a href="#Components">Components</a></li>
-<li><a href="#index-system-designator-40">system designator</a>: <a href="#Components">Components</a></li>
-<li><a href="#index-system-directory-designator-14">system directory designator</a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-Testing-for-ASDF-3">Testing for ASDF</a>: <a href="#Introduction">Introduction</a></li>
-<li><a href="#index-version-specifiers-24">version specifiers</a>: <a href="#The-defsystem-grammar">The defsystem grammar</a></li>
- </ul><p><a name="Function-and-Class-Index"></a>
</span><span style="color: #000000;background-color: #ddffdd">+<table><tr><th valign="top">Jump to: </th><td><a class="summary-letter" href="#Concept-Index_cp_symbol-1"><b>*</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_symbol-2"><b>:</b></a>
+
+<br>
+<a class="summary-letter" href="#Concept-Index_cp_letter-A"><b>A</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-B"><b>B</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-C"><b>C</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-D"><b>D</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-E"><b>E</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-I"><b>I</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-L"><b>L</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-M"><b>M</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-O"><b>O</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-P"><b>P</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-R"><b>R</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-S"><b>S</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-T"><b>T</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-V"><b>V</b></a>
+
+</td></tr></table>
+<table class="index-cp" border="0">
+<tr><td></td><th align="left">Index Entry</th><td> </td><th align="left"> Section</th></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_symbol-1">*</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002afeatures_002a">*features*</a>:</td><td> </td><td valign="top"><a href="#How-do-I-detect-the-ASDF-version_003f">How do I detect the ASDF version?</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_symbol-2">:</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aalso_002dexclude-source-config-directive">:also-exclude source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aaround_002dcompile">:around-compile</a>:</td><td> </td><td valign="top"><a href="#Controlling-file-compilation">Controlling file compilation</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aasdf">:asdf</a>:</td><td> </td><td valign="top"><a href="#Introduction">Introduction</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aasdf2">:asdf2</a>:</td><td> </td><td valign="top"><a href="#Introduction">Introduction</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aasdf3">:asdf3</a>:</td><td> </td><td valign="top"><a href="#Introduction">Introduction</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003acompile_002dcheck">:compile-check</a>:</td><td> </td><td valign="top"><a href="#Controlling-file-compilation">Controlling file compilation</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003adefault_002dregistry-source-config-directive">:default-registry source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003adefsystem_002ddepends_002don">:defsystem-depends-on</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003adirectory-source-config-directive">:directory source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aexclude-source-config-directive">:exclude source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aif_002dcomponent_002ddep_002dfails-component-option">:if-component-dep-fails component option</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aif_002dfeature-component-option">:if-feature component option</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aignore_002dinvalid_002dentries-source-config-directive">:ignore-invalid-entries source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003ainclude-source-config-directive">:include source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003ainherit_002dconfiguration-source-config-directive">:inherit-configuration source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003arequire-dependencies">:require dependencies</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003atree-source-config-directive">:tree source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aversion">:version</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-form">The defsystem form</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aversion-1">:version</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aversion-2">:version</a>:</td><td> </td><td valign="top"><a href="#Common-attributes-of-components">Common attributes of components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_003aweakly_002ddepends_002don">:weakly-depends-on</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-A">A</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-also_002dexclude-source-config-directive">also-exclude source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-around_002dcompile-keyword">around-compile keyword</a>:</td><td> </td><td valign="top"><a href="#Controlling-file-compilation">Controlling file compilation</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-ASDF-versions">ASDF versions</a>:</td><td> </td><td valign="top"><a href="#Introduction">Introduction</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-ASDF_002dBINARY_002dLOCATIONS-compatibility">ASDF-BINARY-LOCATIONS compatibility</a>:</td><td> </td><td valign="top"><a href="#Output-Backward-Compatibility">Output Backward Compatibility</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-asdf_002doutput_002dtranslations">asdf-output-translations</a>:</td><td> </td><td valign="top"><a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-ASDF_002drelated-features">ASDF-related features</a>:</td><td> </td><td valign="top"><a href="#Introduction">Introduction</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-asdf_002duser">asdf-user</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-form">The defsystem form</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-ASDF_002dUSER-package">ASDF-USER package</a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-B">B</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-bug-tracker">bug tracker</a>:</td><td> </td><td valign="top"><a href="#Where-do-I-report-a-bug_003f">Where do I report a bug?</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-C">C</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-compile_002dcheck-keyword">compile-check keyword</a>:</td><td> </td><td valign="top"><a href="#Controlling-file-compilation">Controlling file compilation</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-component">component</a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-component-designator">component designator</a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-D">D</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-default_002dregistry-source-config-directive">default-registry source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-DEFSYSTEM-grammar">DEFSYSTEM grammar</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-directory-source-config-directive">directory source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-E">E</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-exclude-source-config-directive">exclude source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-I">I</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-ignore_002dinvalid_002dentries-source-config-directive">ignore-invalid-entries source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-immutable-systems">immutable systems</a>:</td><td> </td><td valign="top"><a href="#Operations">Operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-immutable-systems-1">immutable systems</a>:</td><td> </td><td valign="top"><a href="#Miscellaneous-Functions">Miscellaneous Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-include-source-config-directive">include source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-inherit_002dconfiguration-source-config-directive">inherit-configuration source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-L">L</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-launchpad">launchpad</a>:</td><td> </td><td valign="top"><a href="#Where-do-I-report-a-bug_003f">Where do I report a bug?</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-logical-pathnames">logical pathnames</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-M">M</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-mailing-list">mailing list</a>:</td><td> </td><td valign="top"><a href="#Mailing-list">Mailing list</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-O">O</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-operation">operation</a>:</td><td> </td><td valign="top"><a href="#Operations">Operations</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-P">P</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-pathname-specifiers">pathname specifiers</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-Primary-system-name">Primary system name</a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-R">R</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-readtables">readtables</a>:</td><td> </td><td valign="top"><a href="#How-do-I-work-with-readtables_003f">How do I work with readtables?</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-S">S</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-serial-dependencies">serial dependencies</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-system">system</a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-system-designator">system designator</a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-System-names">System names</a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-T">T</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-Testing-for-ASDF">Testing for ASDF</a>:</td><td> </td><td valign="top"><a href="#Introduction">Introduction</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-tree-source-config-directive">tree source config directive</a>:</td><td> </td><td valign="top"><a href="#Configuration-DSL">Configuration DSL</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Concept-Index_cp_letter-V">V</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-version-specifiers">version specifiers</a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+</table>
+<table><tr><th valign="top">Jump to: </th><td><a class="summary-letter" href="#Concept-Index_cp_symbol-1"><b>*</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_symbol-2"><b>:</b></a>
+
+<br>
+<a class="summary-letter" href="#Concept-Index_cp_letter-A"><b>A</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-B"><b>B</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-C"><b>C</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-D"><b>D</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-E"><b>E</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-I"><b>I</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-L"><b>L</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-M"><b>M</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-O"><b>O</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-P"><b>P</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-R"><b>R</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-S"><b>S</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-T"><b>T</b></a>
+
+<a class="summary-letter" href="#Concept-Index_cp_letter-V"><b>V</b></a>
+
+</td></tr></table>
</span>
<span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Function-and-Class-Index"></a>
+<a name="Function-and-Class-Index-1"></a>
</span> <h2 class="unnumbered">Function and Class Index</h2>
<span style="color: #000000;background-color: #ddffdd">+<table><tr><th valign="top">Jump to: </th><td><a class="summary-letter" href="#Function-and-Class-Index_fn_letter-A"><b>A</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-B"><b>B</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-C"><b>C</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-D"><b>D</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-E"><b>E</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-F"><b>F</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-I"><b>I</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-L"><b>L</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-M"><b>M</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-O"><b>O</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-P"><b>P</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-R"><b>R</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-S"><b>S</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-T"><b>T</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-V"><b>V</b></a>
+
+</td></tr></table>
+<table class="index-fn" border="0">
+<tr><td></td><th align="left">Index Entry</th><td> </td><th align="left"> Section</th></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-A">A</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-already_002dloaded_002dsystems"><code>already-loaded-systems</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-apply_002doutput_002dtranslations"><code>apply-output-translations</code></a>:</td><td> </td><td valign="top"><a href="#Output-location-API">Output location API</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-asdf_002dversion"><code>asdf-version</code></a>:</td><td> </td><td valign="top"><a href="#How-do-I-detect-the-ASDF-version_003f">How do I detect the ASDF version?</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-B">B</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-binary_002dop-_0028obsolete_0029"><code>binary-op (obsolete)</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-C">C</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-clear_002dconfiguration"><code>clear-configuration</code></a>:</td><td> </td><td valign="top"><a href="#Resetting-the-ASDF-configuration">Resetting the ASDF configuration</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-clear_002doutput_002dtranslations"><code>clear-output-translations</code></a>:</td><td> </td><td valign="top"><a href="#Configuring-where-ASDF-stores-object-files">Configuring where ASDF stores object files</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-clear_002doutput_002dtranslations-1"><code>clear-output-translations</code></a>:</td><td> </td><td valign="top"><a href="#Output-location-API">Output location API</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-clear_002dsource_002dregistry"><code>clear-source-registry</code></a>:</td><td> </td><td valign="top"><a href="#Configuration-API">Configuration API</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-clear_002dsystem"><code>clear-system</code></a>:</td><td> </td><td valign="top"><a href="#Miscellaneous-Functions">Miscellaneous Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-coerce_002dname"><code>coerce-name</code></a>:</td><td> </td><td valign="top"><a href="#Creating-new-operations">Creating new operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-coerce_002dname-1"><code>coerce-name</code></a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-coerce_002dname-2"><code>coerce-name</code></a>:</td><td> </td><td valign="top"><a href="#Common-attributes-of-components">Common attributes of components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-compile_002dbundle_002dop-1"><code>compile-bundle-op</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-compile_002dbundle_002dop"><code><code>compile-bundle-op</code></code></a>:</td><td> </td><td valign="top"><a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-compile_002dfile_002a"><code>compile-file*</code></a>:</td><td> </td><td valign="top"><a href="#Controlling-file-compilation">Controlling file compilation</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-compile_002dop"><code><code>compile-op</code></code></a>:</td><td> </td><td valign="top"><a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-compile_002dsystem"><code>compile-system</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-component-1"><code>component</code></a>:</td><td> </td><td valign="top"><a href="#The-object-model-of-ASDF">The object model of ASDF</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-component_002ddepends_002don"><code>component-depends-on</code></a>:</td><td> </td><td valign="top"><a href="#Creating-new-operations">Creating new operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-component_002dpathname"><code>component-pathname</code></a>:</td><td> </td><td valign="top"><a href="#Common-attributes-of-components">Common attributes of components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-concatenate_002dsource_002dop"><code><code>concatenate-source-op</code></code></a>:</td><td> </td><td valign="top"><a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-D">D</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-defsystem"><code>defsystem</code></a>:</td><td> </td><td valign="top"><a href="#The-defsystem-form">The defsystem form</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-defsystem-1"><code>defsystem</code></a>:</td><td> </td><td valign="top"><a href="#A-more-involved-example">A more involved example</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-defsystem-2"><code>defsystem</code></a>:</td><td> </td><td valign="top"><a href="#The-defsystem-grammar">The defsystem grammar</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-deliver_002dasd_002dop"><code>deliver-asd-op</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-disable_002doutput_002dtranslations"><code>disable-output-translations</code></a>:</td><td> </td><td valign="top"><a href="#Output-location-API">Output location API</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-E">E</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-enable_002dasdf_002dbinary_002dlocations_002dcompatibility"><code>enable-asdf-binary-locations-compatibility</code></a>:</td><td> </td><td valign="top"><a href="#Output-Backward-Compatibility">Output Backward Compatibility</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-ensure_002doutput_002dtranslations"><code>ensure-output-translations</code></a>:</td><td> </td><td valign="top"><a href="#Output-location-API">Output location API</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-ensure_002dsource_002dregistry"><code>ensure-source-registry</code></a>:</td><td> </td><td valign="top"><a href="#Configuration-API">Configuration API</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-F">F</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-fasl_002dop-_0028obsolete_0029"><code>fasl-op (obsolete)</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-file_002dtype"><code>file-type</code></a>:</td><td> </td><td valign="top"><a href="#Pitfalls-of-the-transition-to-ASDF-2">Pitfalls of the transition to ASDF 2</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-find_002dcomponent"><code>find-component</code></a>:</td><td> </td><td valign="top"><a href="#Creating-new-operations">Creating new operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-find_002dcomponent-1"><code>find-component</code></a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-find_002dsystem"><code>find-system</code></a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-I">I</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-initialize_002doutput_002dtranslations"><code>initialize-output-translations</code></a>:</td><td> </td><td valign="top"><a href="#Output-location-API">Output location API</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-initialize_002dsource_002dregistry"><code>initialize-source-registry</code></a>:</td><td> </td><td valign="top"><a href="#Configuration-API">Configuration API</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-input_002dfiles"><code>input-files</code></a>:</td><td> </td><td valign="top"><a href="#Creating-new-operations">Creating new operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-input_002dfiles-1"><code>input-files</code></a>:</td><td> </td><td valign="top"><a href="#Creating-new-operations">Creating new operations</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-L">L</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-load_002dasd"><code>load-asd</code></a>:</td><td> </td><td valign="top"><a href="#The-defsystem-form">The defsystem form</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-load_002dbundle_002dop"><code>load-bundle-op</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-load_002dfasl_002dop-_0028obsolete_0029"><code>load-fasl-op (obsolete)</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-load_002dop"><code><code>load-op</code></code></a>:</td><td> </td><td valign="top"><a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-load_002dsource_002dop"><code><code>load-source-op</code></code></a>:</td><td> </td><td valign="top"><a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-load_002dsystem"><code>load-system</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-load_002dsystem-1"><code>load-system</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-locate_002dsystem"><code>locate-system</code></a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-M">M</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-make"><code>make</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-merge_002dpathnames_002a"><code>merge-pathnames*</code></a>:</td><td> </td><td valign="top"><a href="#Some-Utility-Functions">Some Utility Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-module"><code>module</code></a>:</td><td> </td><td valign="top"><a href="#Pre_002ddefined-subclasses-of-component">Pre-defined subclasses of component</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-monolithic_002dbinary_002dop-_0028obsolete_0029"><code>monolithic-binary-op (obsolete)</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-monolithic_002dcompile_002dbundle_002dop"><code>monolithic-compile-bundle-op</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-monolithic_002ddeliver_002dasd_002dop"><code>monolithic-deliver-asd-op</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-monolithic_002dfasl_002dop-_0028obsolete_0029"><code>monolithic-fasl-op (obsolete)</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-monolithic_002dload_002dbundle_002dop"><code>monolithic-load-bundle-op</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-monolithic_002dload_002dfasl_002dop-_0028obsolete_0029"><code>monolithic-load-fasl-op (obsolete)</code></a>:</td><td> </td><td valign="top"><a href="#What-happened-to-the-bundle-operations">What happened to the bundle operations</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-O">O</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-oos"><code>oos</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-oos-1"><code><code>oos</code></code></a>:</td><td> </td><td valign="top"><a href="#Operations">Operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-operate"><code>operate</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-operate-1"><code><code>operate</code></code></a>:</td><td> </td><td valign="top"><a href="#Operations">Operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-operation-1"><code>operation</code></a>:</td><td> </td><td valign="top"><a href="#The-object-model-of-ASDF">The object model of ASDF</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-operation_002ddone_002dp"><code>operation-done-p</code></a>:</td><td> </td><td valign="top"><a href="#Creating-new-operations">Creating new operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-OPERATION_002dERROR"><code>OPERATION-ERROR</code></a>:</td><td> </td><td valign="top"><a href="#Error-handling">Error handling</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-output_002dfiles"><code>output-files</code></a>:</td><td> </td><td valign="top"><a href="#Creating-new-operations">Creating new operations</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-P">P</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-parse_002dunix_002dnamestring"><code>parse-unix-namestring</code></a>:</td><td> </td><td valign="top"><a href="#Some-Utility-Functions">Some Utility Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-perform"><code>perform</code></a>:</td><td> </td><td valign="top"><a href="#Creating-new-operations">Creating new operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-prepare_002dop"><code><code>prepare-op</code></code></a>:</td><td> </td><td valign="top"><a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-primary_002dsystem_002dname"><code>primary-system-name</code></a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-primary_002dsystem_002dname-1"><code>primary-system-name</code></a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-R">R</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-register_002dimmutable_002dsystem"><code>register-immutable-system</code></a>:</td><td> </td><td valign="top"><a href="#Operations">Operations</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-register_002dimmutable_002dsystem-1"><code>register-immutable-system</code></a>:</td><td> </td><td valign="top"><a href="#Miscellaneous-Functions">Miscellaneous Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-register_002dpreloaded_002dsystem"><code>register-preloaded-system</code></a>:</td><td> </td><td valign="top"><a href="#Miscellaneous-Functions">Miscellaneous Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-require_002dsystem"><code>require-system</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-require_002dsystem-1"><code>require-system</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-run_002dprogram"><code>run-program</code></a>:</td><td> </td><td valign="top"><a href="#Some-Utility-Functions">Some Utility Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-run_002dshell_002dcommand"><code>run-shell-command</code></a>:</td><td> </td><td valign="top"><a href="#Miscellaneous-Functions">Miscellaneous Functions</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-S">S</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-slurp_002dinput_002dstream"><code>slurp-input-stream</code></a>:</td><td> </td><td valign="top"><a href="#Some-Utility-Functions">Some Utility Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-source_002dfile"><code>source-file</code></a>:</td><td> </td><td valign="top"><a href="#Pre_002ddefined-subclasses-of-component">Pre-defined subclasses of component</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-source_002dfile_002dtype"><code>source-file-type</code></a>:</td><td> </td><td valign="top"><a href="#Pitfalls-of-the-transition-to-ASDF-2">Pitfalls of the transition to ASDF 2</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-subpathname"><code>subpathname</code></a>:</td><td> </td><td valign="top"><a href="#Some-Utility-Functions">Some Utility Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-subpathname_002a"><code>subpathname*</code></a>:</td><td> </td><td valign="top"><a href="#Some-Utility-Functions">Some Utility Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-system-1"><code>system</code></a>:</td><td> </td><td valign="top"><a href="#Pre_002ddefined-subclasses-of-component">Pre-defined subclasses of component</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-SYSTEM_002dDEFINITION_002dERROR"><code>SYSTEM-DEFINITION-ERROR</code></a>:</td><td> </td><td valign="top"><a href="#Error-handling">Error handling</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-system_002ddefsystem_002ddepends_002don"><code>system-defsystem-depends-on</code></a>:</td><td> </td><td valign="top"><a href="#Information-about-system-dependencies">Information about system dependencies</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-system_002ddepends_002don"><code>system-depends-on</code></a>:</td><td> </td><td valign="top"><a href="#Information-about-system-dependencies">Information about system dependencies</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-system_002drelative_002dpathname"><code>system-relative-pathname</code></a>:</td><td> </td><td valign="top"><a href="#Miscellaneous-Functions">Miscellaneous Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-system_002dsource_002ddirectory"><code>system-source-directory</code></a>:</td><td> </td><td valign="top"><a href="#Miscellaneous-Functions">Miscellaneous Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-system_002dweakly_002ddepends_002don"><code>system-weakly-depends-on</code></a>:</td><td> </td><td valign="top"><a href="#Information-about-system-dependencies">Information about system dependencies</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-T">T</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-test_002dop"><code><code>test-op</code></code></a>:</td><td> </td><td valign="top"><a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-test_002dsystem"><code>test-system</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-traverse"><code>traverse</code></a>:</td><td> </td><td valign="top"><a href="#Operations">Operations</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Function-and-Class-Index_fn_letter-V">V</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-version_002dsatisfies"><code>version-satisfies</code></a>:</td><td> </td><td valign="top"><a href="#Common-attributes-of-components">Common attributes of components</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-version_002dsatisfies-1"><code>version-satisfies</code></a>:</td><td> </td><td valign="top"><a href="#Functions">Functions</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+</table>
+<table><tr><th valign="top">Jump to: </th><td><a class="summary-letter" href="#Function-and-Class-Index_fn_letter-A"><b>A</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-B"><b>B</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-C"><b>C</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-D"><b>D</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-E"><b>E</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-F"><b>F</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-I"><b>I</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-L"><b>L</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-M"><b>M</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-O"><b>O</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-P"><b>P</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-R"><b>R</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-S"><b>S</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-T"><b>T</b></a>
+
+<a class="summary-letter" href="#Function-and-Class-Index_fn_letter-V"><b>V</b></a>
+
+</td></tr></table>
</span>
<span style="color: #000000;background-color: #ffdddd">-
-<ul class="index-fn" compact>
-<li><a href="#index-already_002dloaded_002dsystems-19"><code>already-loaded-systems</code></a>: <a href="#Using-ASDF">Using ASDF</a></li>
-<li><a href="#index-apply_002doutput_002dtranslations-64"><code>apply-output-translations</code></a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
-<li><a href="#index-clear_002dconfiguration-18"><code>clear-configuration</code></a>: <a href="#Using-ASDF">Using ASDF</a></li>
-<li><a href="#index-clear_002doutput_002dtranslations-17"><code>clear-output-translations</code></a>: <a href="#Configuring-ASDF">Configuring ASDF</a></li>
-<li><a href="#index-clear_002doutput_002dtranslations-62"><code>clear-output-translations</code></a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
-<li><a href="#index-clear_002dsource_002dregistry-54"><code>clear-source-registry</code></a>: <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a></li>
-<li><a href="#index-clear_002dsystem-76"><code>clear-system</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-compile_002dfile_002a-73"><code>compile-file*</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-g_t_0040code_007bcompile_002dop_007d-31"><code>compile-op</code></a>: <a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></li>
-<li><a href="#index-compile_002dsystem-12"><code>compile-system</code></a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-g_t_0040code_007bconcatenate_002dsource_002dop_007d-37"><code>concatenate-source-op</code></a>: <a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></li>
-<li><a href="#index-disable_002doutput_002dtranslations-61"><code>disable-output-translations</code></a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
-<li><a href="#index-enable_002dasdf_002dbinary_002dlocations_002dcompatibility-59"><code>enable-asdf-binary-locations-compatibility</code></a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
-<li><a href="#index-ensure_002doutput_002dtranslations-63"><code>ensure-output-translations</code></a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
-<li><a href="#index-ensure_002dsource_002dregistry-55"><code>ensure-source-registry</code></a>: <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a></li>
-<li><a href="#index-g_t_0040code_007bfasl_002dop_007d-36"><code>fasl-op</code></a>: <a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></li>
-<li><a href="#index-find_002dcomponent-44"><code>find-component</code></a>: <a href="#Components">Components</a></li>
-<li><a href="#index-find_002dsystem-43"><code>find-system</code></a>: <a href="#Components">Components</a></li>
-<li><a href="#index-initialize_002doutput_002dtranslations-60"><code>initialize-output-translations</code></a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
-<li><a href="#index-initialize_002dsource_002dregistry-53"><code>initialize-source-registry</code></a>: <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a></li>
-<li><a href="#index-g_t_0040code_007bload_002dop_007d-32"><code>load-op</code></a>: <a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></li>
-<li><a href="#index-g_t_0040code_007bload_002dsource_002dop_007d-34"><code>load-source-op</code></a>: <a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></li>
-<li><a href="#index-load_002dsystem-10"><code>load-system</code></a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-merge_002dpathnames_002a-80"><code>merge-pathnames*</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-module-48"><code>module</code></a>: <a href="#Pre_002ddefined-subclasses-of-component">Pre-defined subclasses of component</a></li>
-<li><a href="#index-g_t_0040code_007boos_007d-30"><code>oos</code></a>: <a href="#Operations">Operations</a></li>
-<li><a href="#index-oos-16"><code>oos</code></a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-g_t_0040code_007boperate_007d-29"><code>operate</code></a>: <a href="#Operations">Operations</a></li>
-<li><a href="#index-operate-15"><code>operate</code></a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-OPERATION_002dERROR-66"><code>OPERATION-ERROR</code></a>: <a href="#Error-handling">Error handling</a></li>
-<li><a href="#index-parse_002dunix_002dnamestring-79"><code>parse-unix-namestring</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-g_t_0040code_007bprepare_002dop_007d-33"><code>prepare-op</code></a>: <a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></li>
-<li><a href="#index-register_002dpreloaded_002dsystem-77"><code>register-preloaded-system</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-require_002dsystem-11"><code>require-system</code></a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-run_002dprogram-83"><code>run-program</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-run_002dshell_002dcommand-78"><code>run-shell-command</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-slurp_002dinput_002dstream-84"><code>slurp-input-stream</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-source_002dfile-47"><code>source-file</code></a>: <a href="#Pre_002ddefined-subclasses-of-component">Pre-defined subclasses of component</a></li>
-<li><a href="#index-source_002dfile_002dtype-85"><code>source-file-type</code></a>: <a href="#FAQ">FAQ</a></li>
-<li><a href="#index-subpathname-81"><code>subpathname</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-subpathname_002a-82"><code>subpathname*</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-system-49"><code>system</code></a>: <a href="#Pre_002ddefined-subclasses-of-component">Pre-defined subclasses of component</a></li>
-<li><a href="#index-SYSTEM_002dDEFINITION_002dERROR-65"><code>SYSTEM-DEFINITION-ERROR</code></a>: <a href="#Error-handling">Error handling</a></li>
-<li><a href="#index-system_002drelative_002dpathname-74"><code>system-relative-pathname</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-system_002dsource_002ddirectory-75"><code>system-source-directory</code></a>: <a href="#Miscellaneous-additional-functionality">Miscellaneous additional functionality</a></li>
-<li><a href="#index-g_t_0040code_007btest_002dop_007d-35"><code>test-op</code></a>: <a href="#Predefined-operations-of-ASDF">Predefined operations of ASDF</a></li>
-<li><a href="#index-test_002dsystem-13"><code>test-system</code></a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-g_t_0040var_007bversion_007d-51"><var>version</var></a>: <a href="#Functions">Functions</a></li>
-<li><a href="#index-version_002dsatisfies-50"><code>version-satisfies</code></a>: <a href="#Functions">Functions</a></li>
-<li><a href="#index-version_002dsatisfies-45"><code>version-satisfies</code></a>: <a href="#Common-attributes-of-components">Common attributes of components</a></li>
- </ul><p><a name="Variable-Index"></a>
-
</span><span style="color: #000000;background-color: #ddffdd">+<hr>
+<a name="Variable-Index"></a>
+<a name="Variable-Index-1"></a>
</span> <h2 class="unnumbered">Variable Index</h2>
<span style="color: #000000;background-color: #ffdddd">-
-
-<ul class="index-vr" compact>
-<li><a href="#index-g_t_002acentral_002dregistry_002a-8"><code>*central-registry*</code></a>: <a href="#Loading-ASDF">Loading ASDF</a></li>
-<li><a href="#index-g_t_002acompile_002dfile_002derrors_002dbehavior_002a-68"><code>*compile-file-errors-behavior*</code></a>: <a href="#Error-handling">Error handling</a></li>
-<li><a href="#index-g_t_002acompile_002dfile_002dwarnings_002dbehaviour_002a-67"><code>*compile-file-warnings-behaviour*</code></a>: <a href="#Error-handling">Error handling</a></li>
-<li><a href="#index-g_t_002adefault_002dsource_002dregistry_002dexclusions_002a-52"><code>*default-source-registry-exclusions*</code></a>: <a href="#Controlling-where-ASDF-searches-for-systems">Controlling where ASDF searches for systems</a></li>
-<li><a href="#index-g_t_002afeatures_002a-2"><code>*features*</code></a>: <a href="#Introduction">Introduction</a></li>
-<li><a href="#index-g_t_002asystem_002ddefinition_002dsearch_002dfunctions_002a-42"><code>*system-definition-search-functions*</code></a>: <a href="#Components">Components</a></li>
-<li><a href="#index-ASDF_005fOUTPUT_005fTRANSLATIONS-57"><code>ASDF_OUTPUT_TRANSLATIONS</code></a>: <a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></li>
- </ul><div class="footnote">
</span><span style="color: #000000;background-color: #ddffdd">+<table><tr><th valign="top">Jump to: </th><td><a class="summary-letter" href="#Variable-Index_vr_symbol-1"><b>*</b></a>
+
+<br>
+<a class="summary-letter" href="#Variable-Index_vr_letter-A"><b>A</b></a>
+
+</td></tr></table>
+<table class="index-vr" border="0">
+<tr><td></td><th align="left">Index Entry</th><td> </td><th align="left"> Section</th></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Variable-Index_vr_symbol-1">*</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002acompile_002dfile_002dfailure_002dbehaviour_002a"><code>*compile-file-failure-behaviour*</code></a>:</td><td> </td><td valign="top"><a href="#Error-handling">Error handling</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002acompile_002dfile_002dwarnings_002dbehaviour_002a"><code>*compile-file-warnings-behaviour*</code></a>:</td><td> </td><td valign="top"><a href="#Error-handling">Error handling</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002adefault_002dsource_002dregistry_002dexclusions_002a"><code>*default-source-registry-exclusions*</code></a>:</td><td> </td><td valign="top"><a href="#Search-Algorithm">Search Algorithm</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002afeatures_002a-1"><code>*features*</code></a>:</td><td> </td><td valign="top"><a href="#Introduction">Introduction</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002aimage_002ddump_002dhook_002a"><code>*image-dump-hook*</code></a>:</td><td> </td><td valign="top"><a href="#Resetting-the-ASDF-configuration">Resetting the ASDF configuration</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002aload_002dsystem_002doperation_002a"><code>*load-system-operation*</code></a>:</td><td> </td><td valign="top"><a href="#Convenience-Functions">Convenience Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002anil_002dpathname_002a"><code>*nil-pathname*</code></a>:</td><td> </td><td valign="top"><a href="#Some-Utility-Functions">Some Utility Functions</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002aoldest_002dforward_002dcompatible_002dasdf_002dversion_002a"><code>*oldest-forward-compatible-asdf-version*</code></a>:</td><td> </td><td valign="top"><a href="#Pitfalls-of-the-upgrade-to-ASDF-3">Pitfalls of the upgrade to ASDF 3</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002asource_002dregistry_002dparameter_002a"><code>*source-registry-parameter*</code></a>:</td><td> </td><td valign="top"><a href="#g_t_002asource_002dregistry_002dparameter_002a-variable">*source-registry-parameter* variable</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-_002asystem_002ddefinition_002dsearch_002dfunctions_002a"><code>*system-definition-search-functions*</code></a>:</td><td> </td><td valign="top"><a href="#Components">Components</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+<tr><th><a name="Variable-Index_vr_letter-A">A</a></th><td></td><td></td></tr>
+<tr><td></td><td valign="top"><a href="#index-asdf_003a_003a_002auser_002dcache_002a"><code><code>asdf::*user-cache*</code></code></a>:</td><td> </td><td valign="top"><a href="#Output-Configuration-DSL">Output Configuration DSL</a></td></tr>
+<tr><td></td><td valign="top"><a href="#index-ASDF_005fOUTPUT_005fTRANSLATIONS"><code>ASDF_OUTPUT_TRANSLATIONS</code></a>:</td><td> </td><td valign="top"><a href="#Controlling-where-ASDF-saves-compiled-files">Controlling where ASDF saves compiled files</a></td></tr>
+<tr><td colspan="4"> <hr></td></tr>
+</table>
+<table><tr><th valign="top">Jump to: </th><td><a class="summary-letter" href="#Variable-Index_vr_symbol-1"><b>*</b></a>
+
+<br>
+<a class="summary-letter" href="#Variable-Index_vr_letter-A"><b>A</b></a>
+
+</td></tr></table>
+
+<div class="footnote">
</span> <hr>
<span style="color: #000000;background-color: #ffdddd">-<a name="texinfo-footnotes-in-document"></a><h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small>
-It is possible to further customize
-the system definition file search.
-That's considered advanced use, and covered later:
</span><span style="color: #000000;background-color: #ddffdd">+<h4 class="footnotes-heading">Footnotes</h4>
+
+<h3><a name="FOOT1" href="#DOCF1">(1)</a></h3>
+<p>NB: all implementations except GNU CLISP also accept
+<code>(require "ASDF")</code>, <code>(require 'asdf)</code> and <code>(require :asdf)</code>.
+For portability’s sake, you should use <code>(require "asdf")</code>.
+</p>
+<h3><a name="FOOT2" href="#DOCF2">(2)</a></h3>
+<p><samp>~/common-lisp/</samp> is only included in
+ the default configuration
+ starting with ASDF 3.1.2 or later.
+ If your implementation provides an earlier variant of ASDF,
+ you may need to explicitly configure it to use this path,
+ as further explained.
+</p>
+<h3><a name="FOOT3" href="#DOCF3">(3)</a></h3>
+<p>For Windows users, and starting with ASDF 3.1.5, start from your
+ <samp>%LOCALAPPDATA%</samp>, which is usually <samp>~/AppData/Local/</samp>
+ (but you can ask in a <code>CMD.EXE</code> terminal
+ <code>echo %LOCALAPPDATA%</code> to make sure)
+ and underneath create a subpath
+ <samp>config/common-lisp/source-registry.conf.d/</samp>.
+</p>
+<h3><a name="FOOT4" href="#DOCF4">(4)</a></h3>
+<p>By requiring the <samp>.conf</samp>
+ extension, and ignoring other files, ASDF allows you to have disabled files,
+ editor backups, etc. in the same directory with your active
+ configuration files.
+</p>
+<p>ASDF will also ignore files whose names start with a <samp>.</samp> character.
+</p>
+<p>It is customary to start the filename with two digits, to control the
+ sorting of the <code>conf</code> files in the source registry directory, and
+ thus the order in which the directories will be scanned.
+</p>
+<h3><a name="FOOT5" href="#DOCF5">(5)</a></h3>
+<p>It is possible to further customize
+the system definition file search.
+That’s considered advanced use, and covered later:
</span> search forward for
<span style="color: #000000;background-color: #ffdddd">-<code>*system-definition-search-functions*</code>.
</span><span style="color: #000000;background-color: #ddffdd">+<code>*system-definition-search-functions*</code>.
</span> See <a href="#Defining-systems-with-defsystem">Defining systems with defsystem</a>.</p>
<span style="color: #000000;background-color: #ffdddd">-
- <p class="footnote"><small>[<a name="fn-2" href="#fnd-2">2</a>]</small>
-ASDF will indeed call <code>eval</code> on each entry.
-It will also skip entries that evaluate to <code>nil</code>.
-
- <p>Strings and pathname objects are self-evaluating,
</span><span style="color: #000000;background-color: #ddffdd">+<h3><a name="FOOT6" href="#DOCF6">(6)</a></h3>
+<p>ASDF will indeed call <code>eval</code> on each entry.
+It will skip entries that evaluate to <code>nil</code>.
+</p>
+<p>Strings and pathname objects are self-evaluating,
</span> in which case the <code>eval</code> step does nothing;
<span style="color: #000000;background-color: #ffdddd">-but you may push arbitrary SEXP onto the central registry,
-that will be evaluated to compute e.g. things that depend
</span><span style="color: #000000;background-color: #ddffdd">+but you may push arbitrary s-expressions onto the central registry.
+These s-expressions may be evaluated to compute context-dependent
+entries, e.g. things that depend
</span> on the value of shell variables or the identity of the user.
<span style="color: #000000;background-color: #ffdddd">-
- <p>The variable <code>asdf:*central-registry*</code> is thus a list of
-“system directory designators”.
-A <dfn>system directory designator</dfn> is a form
</span><span style="color: #000000;background-color: #ddffdd">+</p>
+<p>The variable <code>asdf:*central-registry*</code> is thus a list of
+“system directory designators”.
+A <em>system directory designator</em> is a form
</span> which will be evaluated whenever a system is to be found,
<span style="color: #000000;background-color: #ffdddd">-and must evaluate to a directory to look in.
-By “directory” here, we mean
-“designator for a pathname with a supplied DIRECTORY component”.
</span><span style="color: #000000;background-color: #ddffdd">+and must evaluate to a directory to look in (or <code>NIL</code>).
+By “directory”, we mean
+“designator for a pathname with a non-empty DIRECTORY component”.
</span> </p>
<span style="color: #000000;background-color: #ddffdd">+<h3><a name="FOOT7" href="#DOCF7">(7)</a></h3>
+<p>On Windows, you can use Windows shortcuts instead of POSIX symlinks.
+ if you try aliases under MacOS, we are curious to hear about your experience.
+</p>
+<h3><a name="FOOT8" href="#DOCF8">(8)</a></h3>
+<p>For the curious, the option is <code>:force-not (already-loaded-systems)</code>.
+</p>
+<h3><a name="FOOT9" href="#DOCF9">(9)</a></h3>
+<p>ASDF 1 and 2 (up until 2.26)
+ used to dynamically create and delete temporary packages <code>asdf<em>N</em></code>,
+ one for each <samp>.asd</samp> file, in a misguided attempt to thereby reduce name clashes;
+ but it failed at that goal and only made things more complex.
+ ASDF 3 just uses a shared package <code>asdf-user</code> instead,
+ and relies on the usual Common Lisp conventions to avoid clashes.
+ As far as package oddities go, you may just notice that
+ the <code>asdf-user</code> package also uses <code>uiop/common-lisp</code>,
+ a variant of the <code>common-lisp</code> package that papers over
+ deficiencies in more obscure Common Lisp implementations;
+ but unless you care about Corman Lisp, GCL, Genera or MCL, you shouldn’t be concerned.
+</p>
+<h3><a name="FOOT10" href="#DOCF10">(10)</a></h3>
+<p>Historically, the function that built a plan was
+ called <code>traverse</code>, and returned a list of actions;
+ it was deprecated in favor of <code>make-plan</code> (that returns a plan object)
+ when the <code>plan</code> objects were introduced with ASDF 3;
+ the old function is kept for backward compatibility and debugging purposes only,
+ and may be removed in the near future.
+</p>
+<h3><a name="FOOT11" href="#DOCF11">(11)</a></h3>
+<p>The term <em>action</em>
+ was used by Kent Pitman in his article, “The Description of Large Systems,”
+ (see <a href="#Bibliography">Bibliography</a>),
+ and we suspect might be traced to <code>make</code>.
+ Although the term was only used by ASDF hackers starting with ASDF 2,
+ the concept was there since the very beginning of ASDF 1,
+ just not clearly articulated.
+</p>
+<h3><a name="FOOT12" href="#DOCF12">(12)</a></h3>
+<p>Note that between releases 2.27 and 3.0.3, only <code>UIOP/PACKAGE</code>,
+not all of <code>UIOP</code>, was used; if you want your code to work
+with releases earlier than 3.1.2, you may have to explicitly define a package
+that uses <code>UIOP</code>, or use proper package prefix to your symbols, as in
+<code>uiop:version<</code>.</p>
+<h3><a name="FOOT13" href="#DOCF13">(13)</a></h3>
+<p>ASDF 2.26 and earlier versions
+do not support this primary system name convention.
+With these versions of ASDF
+you must explicitly load <samp>foo.asd</samp>
+before you can use system <var>foo/bar</var> defined therein,
+e.g. using <code>(asdf:find-system "foo")</code>.
+We do not support ASDF 2, and recommend that you should upgrade to ASDF 3.
+</p>
+<h3><a name="FOOT14" href="#DOCF14">(14)</a></h3>
+<p>“FASL” is short for “FASt Loading.”</p>
+<h3><a name="FOOT15" href="#DOCF15">(15)</a></h3>
+<p>A <code>CLEAN-OP</code> would be a partial solution to this problem.</p>
+<h3><a name="FOOT16" href="#DOCF16">(16)</a></h3>
+<p>Alternatively, you could touch <code>foo.asd</code> or
+remove the corresponding fasls from the output file cache.</p>
+<h3><a name="FOOT17" href="#DOCF17">(17)</a></h3>
+<a name="index-_002aoldest_002dforward_002dcompatible_002dasdf_002dversion_002a"></a>
+<p>Forward incompatibility can be determined using the variable
+<code>asdf/upgrade::*oldest-forward-compatible-asdf-version*</code>,
+which is 2.33 at the time of this writing.</p>
+</div>
+<hr>
</span>
<span style="color: #000000;background-color: #ffdddd">- <p class="footnote"><small>[<a name="fn-3" href="#fnd-3">3</a>]</small>
-It is possible, though almost never necessary, to override this behaviour.</p>
-
- <hr></div>
</span>
<span style="color: #000000;background-color: #ffdddd">-</body></html>
</span>
<span style="color: #000000;background-color: #ddffdd">+</body>
+</html>
</span></code></pre>
<br>
</li>
<li id='diff-2'>
<a href='https://gitlab.common-lisp.net/cmucl/cmucl/compare/b239ce3f44b62821701e3447437705d3d914a5b4...1d034d24f6c87575de73422e32cdca5501d37ef5#diff-2'>
<strong>
src/contrib/asdf/doc/asdf.info
</strong>
</a>
<hr>
<pre class="highlight"><code><span style="color: #000000;background-color: #ffdddd">--- a/src/contrib/asdf/doc/asdf.info
</span><span style="color: #000000;background-color: #ddffdd">+++ b/src/contrib/asdf/doc/asdf.info
</span><span style="color: #aaaaaa">@@ -1,22 +1,17 @@
</span><span style="color: #000000;background-color: #ffdddd">-This is asdf.info, produced by makeinfo version 4.13 from asdf.texinfo.
</span><span style="color: #000000;background-color: #ddffdd">+This is asdf.info, produced by makeinfo version 5.2 from asdf.texinfo.
</span>
<span style="color: #000000;background-color: #ffdddd">-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* asdf: (asdf). Another System Definition Facility (for Common Lisp)
-END-INFO-DIR-ENTRY
-
- This manual describes ASDF, a system definition facility for Common
-Lisp programs and libraries.
</span><span style="color: #000000;background-color: #ddffdd">+This manual describes ASDF, a system definition facility for Common Lisp
+programs and libraries.
</span>
You can find the latest version of this manual at
<span style="color: #000000;background-color: #ffdddd">-`http://common-lisp.net/project/asdf/asdf.html'.
</span><span style="color: #000000;background-color: #ddffdd">+<https://common-lisp.net/project/asdf/asdf.html>.
</span>
<span style="color: #000000;background-color: #ffdddd">- ASDF Copyright (C) 2001-2013 Daniel Barlow and contributors.
</span><span style="color: #000000;background-color: #ddffdd">+ ASDF Copyright (C) 2001-2015 Daniel Barlow and contributors.
</span>
<span style="color: #000000;background-color: #ffdddd">- This manual Copyright (C) 2001-2013 Daniel Barlow and contributors.
</span><span style="color: #000000;background-color: #ddffdd">+ This manual Copyright (C) 2001-2015 Daniel Barlow and contributors.
</span>
<span style="color: #000000;background-color: #ffdddd">- This manual revised (C) 2009-2013 Robert P. Goldman and
-Francois-Rene Rideau.
</span><span style="color: #000000;background-color: #ddffdd">+ This manual revised (C) 2009-2015 Robert P. Goldman and Francois-Rene
+Rideau.
</span>
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
<span style="color: #aaaaaa">@@ -37,24 +32,31 @@ CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
</span> TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
<span style="color: #000000;background-color: #ddffdd">+INFO-DIR-SECTION Software development
+START-INFO-DIR-ENTRY
+* asdf: (asdf). Another System Definition Facility (for Common Lisp)
+END-INFO-DIR-ENTRY
+
</span>
File: asdf.info, Node: Top, Next: Introduction, Prev: (dir), Up: (dir)
<span style="color: #000000;background-color: #ffdddd">-asdf: another system definition facility
</span><span style="color: #000000;background-color: #ddffdd">+ASDF: Another System Definition Facility
</span> ****************************************
<span style="color: #000000;background-color: #ffdddd">-This manual describes ASDF, a system definition facility for Common
</span><span style="color: #000000;background-color: #ddffdd">+Manual for Version 3.1.6
+
+ This manual describes ASDF, a system definition facility for Common
</span> Lisp programs and libraries.
You can find the latest version of this manual at
<span style="color: #000000;background-color: #ffdddd">-`http://common-lisp.net/project/asdf/asdf.html'.
</span><span style="color: #000000;background-color: #ddffdd">+<https://common-lisp.net/project/asdf/asdf.html>.
</span>
<span style="color: #000000;background-color: #ffdddd">- ASDF Copyright (C) 2001-2013 Daniel Barlow and contributors.
</span><span style="color: #000000;background-color: #ddffdd">+ ASDF Copyright (C) 2001-2015 Daniel Barlow and contributors.
</span>
<span style="color: #000000;background-color: #ffdddd">- This manual Copyright (C) 2001-2013 Daniel Barlow and contributors.
</span><span style="color: #000000;background-color: #ddffdd">+ This manual Copyright (C) 2001-2015 Daniel Barlow and contributors.
</span>
<span style="color: #000000;background-color: #ffdddd">- This manual revised (C) 2009-2013 Robert P. Goldman and
-Francois-Rene Rideau.
</span><span style="color: #000000;background-color: #ddffdd">+ This manual revised (C) 2009-2015 Robert P. Goldman and Francois-Rene
+Rideau.
</span>
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
<span style="color: #aaaaaa">@@ -78,6 +80,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
</span> * Menu:
* Introduction::
<span style="color: #000000;background-color: #ddffdd">+* Quick start summary::
</span> * Loading ASDF::
* Configuring ASDF::
* Using ASDF::
<span style="color: #aaaaaa">@@ -89,452 +92,664 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
</span> * Miscellaneous additional functionality::
* Getting the latest version::
* FAQ::
<span style="color: #000000;background-color: #ffdddd">-* TODO list::
-* Inspiration::
</span><span style="color: #000000;background-color: #ddffdd">+* Ongoing Work::
+* Bibliography::
</span> * Concept Index::
* Function and Class Index::
<span style="color: #000000;background-color: #ffdddd">-* Variable Index::
</span><span style="color: #000000;background-color: #ddffdd">+* Variable Index::
+
+ -- The Detailed Node Listing --
+
+Loading ASDF
+
+* Loading a pre-installed ASDF::
+* Checking whether ASDF is loaded::
+* Upgrading ASDF::
+* Replacing your implementation's ASDF::
+* Loading ASDF from source::
+
+Configuring ASDF
+
+* Configuring ASDF to find your systems::
+* Configuring ASDF to find your systems --- old style::
+* Configuring where ASDF stores object files::
+* Resetting the ASDF configuration::
+
+Using ASDF
+
+* Loading a system::
+* Convenience Functions::
+* Moving on::
+
+Defining systems with defsystem
+
+* The defsystem form::
+* A more involved example::
+* The defsystem grammar::
+* Other code in .asd files::
+* The package-inferred-system extension::
+
+The Object model of ASDF
+
+* Operations::
+* Components::
+* Dependencies::
+* Functions::
+
+Operations
+
+* Predefined operations of ASDF::
+* Creating new operations::
+
+Components
+
+* Common attributes of components::
+* Pre-defined subclasses of component::
+* Creating new component types::
+
+properties
+
+* Pre-defined subclasses of component::
+* Creating new component types::
+
+Controlling where ASDF searches for systems
+
+* Configurations::
+* Truenames and other dangers::
+* XDG base directory::
+* Backward Compatibility::
+* Configuration DSL::
+* Configuration Directories::
+* Shell-friendly syntax for configuration::
+* Search Algorithm::
+* Caching Results::
+* Configuration API::
+* Introspection::
+* Status::
+* Rejected ideas::
+* TODO::
+* Credits for the source-registry::
+
+Configuration Directories
+
+* The here directive::
+
+Introspection
+
+* *source-registry-parameter* variable::
+* Information about system dependencies::
+
+Controlling where ASDF saves compiled files
+
+* Output Configurations::
+* Output Backward Compatibility::
+* Output Configuration DSL::
+* Output Configuration Directories::
+* Output Shell-friendly syntax for configuration::
+* Semantics of Output Translations::
+* Output Caching Results::
+* Output location API::
+* Credits for output translations::
+
+Miscellaneous additional functionality
+
+* Controlling file compilation::
+* Controlling source file character encoding::
+* Miscellaneous Functions::
+* Some Utility Functions::
+
+FAQ
+
+* Where do I report a bug?::
+* Mailing list::
+* What has changed between ASDF 1 ASDF 2 and ASDF 3?::
+* Issues with installing the proper version of ASDF::
+* Issues with configuring ASDF::
+* Issues with using and extending ASDF to define systems::
+* ASDF development FAQs::
+
+"What has changed between ASDF 1, ASDF 2, and ASDF 3?"
+
+* What are ASDF 1 2 3?::
+* How do I detect the ASDF version?::
+* ASDF can portably name files in subdirectories::
+* Output translations::
+* Source Registry Configuration::
+* Usual operations are made easier to the user::
+* Many bugs have been fixed::
+* ASDF itself is versioned::
+* ASDF can be upgraded::
+* Decoupled release cycle::
+* Pitfalls of the transition to ASDF 2::
+* Pitfalls of the upgrade to ASDF 3::
+* What happened to the bundle operations::
+
+Issues with installing the proper version of ASDF
+
+* My Common Lisp implementation comes with an outdated version of ASDF. What to do?::
+* I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?::
+
+Issues with configuring ASDF
+
+* How can I customize where fasl files are stored?::
+* How can I wholly disable the compiler output cache?::
+
+Issues with using and extending ASDF to define systems
+
+* How can I cater for unit-testing in my system?::
+* How can I cater for documentation generation in my system?::
+* How can I maintain non-Lisp (e.g. C) source files?::
+* I want to put my module's files at the top level. How do I do this?::
+* How do I create a system definition where all the source files have a .cl extension?::
+* How do I mark a source file to be loaded only and not compiled?::
+* How do I work with readtables?::
+
+ASDF development FAQs
+
+* How do I run the tests interactively in a REPL?::
+
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: Introduction, Next: Loading ASDF, Prev: Top, Up: Top
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: Introduction, Next: Quick start summary, Prev: Top, Up: Top
</span>
1 Introduction
**************
ASDF is Another System Definition Facility: a tool for specifying how
<span style="color: #000000;background-color: #ffdddd">-systems of Common Lisp software are comprised of components
-(sub-systems and files), and how to operate on these components in the
-right order so that they can be compiled, loaded, tested, etc.
</span><span style="color: #000000;background-color: #ddffdd">+systems of Common Lisp software are made up of components (sub-systems
+and files), and how to operate on these components in the right order so
+that they can be compiled, loaded, tested, etc. If you are new to ASDF,
+*note the quick start guide: Quick start summary.
</span>
ASDF presents three faces: one for users of Common Lisp software who
want to reuse other people's code, one for writers of Common Lisp
<span style="color: #000000;background-color: #ffdddd">-software who want to specify how to build their systems, one for
</span><span style="color: #000000;background-color: #ddffdd">+software who want to specify how to build their systems, and one for
</span> implementers of Common Lisp extensions who want to extend the build
<span style="color: #000000;background-color: #ffdddd">-system. *Note Loading a system: Using ASDF, to learn how to use ASDF
-to load a system. *Note Defining systems with defsystem::, to learn
-how to define a system of your own. *Note The object model of ASDF::,
-for a description of the ASDF internals and how to extend ASDF.
-
- _Nota Bene_: We have released ASDF 2.000 on May 31st 2010, and ASDF
-3.0 on January 31st 2013. Releases of ASDF 2 and later have since then
-been included in all actively maintained CL implementations that used
-to bundle ASDF 1, plus some implementations that didn't use to, and has
-been made to work with all actively used CL implementations and a few
-more. *Note "What has changed between ASDF 1 and ASDF 2?": FAQ.
-Furthermore, it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3
-on the fly. For this reason, we have stopped supporting ASDF 1 and
-ASDF 2. If you are using ASDF 1 or ASDF 2 and are experiencing any
-kind of issues or limitations, we recommend you upgrade to ASDF 3 --
-and we explain how to do that. *Note Loading ASDF::.
-
- Also note that ASDF is not to be confused with ASDF-Install.
-ASDF-Install is not part of ASDF, but a separate piece of software.
-ASDF-Install is also unmaintained and obsolete. We recommend you use
-Quicklisp instead, which works great and is being actively maintained.
-If you want to download software from version control instead of
-tarballs, so you may more easily modify it, we recommend clbuild.
</span><span style="color: #000000;background-color: #ddffdd">+system. For more specifics, *note Using ASDF::, to learn how to use
+ASDF to load a system. *Note Defining systems with defsystem::, to
+learn how to define a system of your own. *Note The object model of
+ASDF::, for a description of the ASDF internals and how to extend ASDF.
+
+ Note that ASDF is _not_ a tool for library and system _installation_;
+it plays a role like 'make' or 'ant', not like a package manager. In
+particular, ASDF should not to be confused with Quicklisp or
+ASDF-Install, that attempt to find and download ASDF systems for you.
+Despite what the name might suggest, ASDF-Install is not part of ASDF,
+but a separate piece of software. ASDF-Install is also unmaintained and
+obsolete. We recommend you use Quicklisp (<http://www.quicklisp.org/>)
+instead, a Common Lisp package manager which works well and is being
+actively maintained. If you want to download software from version
+control instead of tarballs, so you may more easily modify it, we
+recommend clbuild (<http://common-lisp.net/project/clbuild/>). We
+recommend '~/common-lisp/' as a place into which to install Common Lisp
+software; starting with ASDF 3.1.2, it is included in the default
+source-registry configuration.
+
+ Finally, note that this manual is incomplete. All the bases are
+covered, but many advanced topics are only barely alluded to, and there
+is not much in terms of examples. The source code remains the ultimate
+source of information, free software systems in Quicklisp remain the
+best source of examples, and the mailing-list the best place to ask for
+help.
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: Loading ASDF, Next: Configuring ASDF, Prev: Introduction, Up: Top
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: Quick start summary, Next: Loading ASDF, Prev: Introduction, Up: Top
+
+2 Quick start summary
+*********************
+
+ * To load an ASDF system:
+
+ * Load ASDF itself into your Lisp image, using '(require
+ "asdf")'. Check that you have a recent version using
+ '(asdf:asdf-version)'. For more details, or if any of the
+ above fails, *note Loading ASDF::.
+
+ * Make sure software is installed where ASDF can find it. The
+ simplest way is to put all your Lisp code in subdirectories of
+ '~/common-lisp/' (starting with ASDF 3.1.2), or
+ '~/.local/share/common-lisp/source/' (for ASDF 2 and later, or
+ if you want to keep source in a hidden directory). For more
+ details, *note Configuring ASDF to find your systems::.
</span>
<span style="color: #000000;background-color: #ffdddd">-2 Loading ASDF
</span><span style="color: #000000;background-color: #ddffdd">+ * Load your system with '(asdf:load-system "MY-SYSTEM")'. *Note
+ Using ASDF::.
+
+ * To make your own ASDF system:
+
+ * As above, load and configure ASDF.
+
+ * Make a new directory for your system, 'MY-SYSTEM/', again in a
+ location where ASDF can find it. All else being equal, the
+ easiest location is probably '~/common-lisp/my-system/'.
+ *Note Configuring ASDF to find your systems::.
+
+ * Create an ASDF system definition listing the dependencies of
+ your system, its components, and their interdependencies, and
+ put it in 'MY-SYSTEM.asd'. This file must have the same name
+ as your system, all lowercase. *Note Defining systems with
+ defsystem::.
+
+ * Use '(asdf:load-system "MY-SYSTEM")' to make sure it's all
+ working properly. *Note Using ASDF::.
+
+
+File: asdf.info, Node: Loading ASDF, Next: Configuring ASDF, Prev: Quick start summary, Up: Top
+
+3 Loading ASDF
</span> **************
<span style="color: #000000;background-color: #ffdddd">-2.1 Loading a pre-installed ASDF
-================================
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* Loading a pre-installed ASDF::
+* Checking whether ASDF is loaded::
+* Upgrading ASDF::
+* Replacing your implementation's ASDF::
+* Loading ASDF from source::
</span>
<span style="color: #000000;background-color: #ffdddd">-Most recent Lisp implementations include a copy of ASDF 2, and soon
-ASDF 3. You can usually load this copy using Common Lisp's `require'
-function:
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Loading a pre-installed ASDF, Next: Checking whether ASDF is loaded, Prev: Loading ASDF, Up: Loading ASDF
</span>
<span style="color: #000000;background-color: #ddffdd">+3.1 Loading a pre-installed ASDF
+================================
+
+The recommended way to load ASDF is via:
</span> (require "asdf")
<span style="color: #000000;background-color: #ddffdd">+ All actively maintained Lisp implementations now include a copy of
+ASDF 3 that you can load this way using Common Lisp's 'require'
+function.(1)
+
+ If the implementation you are using doesn't provide a recent ASDF 3,
+we recommend you upgrade it. If for some reason you would rather not
+upgrade it, we recommend you replace your implementation's ASDF. *Note
+Replacing your implementation's ASDF::. If all else fails, see *note
+Loading ASDF from source:: below.
+
+ If you use an actively maintained implementation that fails to
+provide an up-to-date enough stable release of ASDF, you may also send a
+bug report to your Lisp vendor and complain about it -- or you may fix
+the issue yourself if it's free software.
+
</span> As of the writing of this manual, the following implementations
<span style="color: #000000;background-color: #ffdddd">-provide ASDF 2 this way: abcl allegro ccl clisp cmucl ecl lispworks
-mkcl sbcl xcl. The following implementation doesn't provide it yet but
-will in an upcoming release: scl. The following implementations are
-obsolete, not actively maintained, and most probably will never bundle
-it: cormanlisp gcl genera mcl.
-
- If the implementation you are using doesn't provide ASDF 2 or ASDF 3,
-see *note Loading an otherwise installed ASDF: Loading ASDF. below. If
-that implementation is still actively maintained, you may also send a
-bug report to your Lisp vendor and complain about their failing to
-provide ASDF.
-
- NB: all implementations except clisp also accept `(require "ASDF")',
-`(require 'asdf)' and `(require :asdf)'. For portability's sake, you
-probably want to use `(require "asdf")'.
-
-2.2 Checking whether ASDF is loaded
</span><span style="color: #000000;background-color: #ddffdd">+provide ASDF 3 this way: ABCL, Allegro CL, CLASP, Clozure CL, CMUCL,
+ECL, GNU CLISP, LispWorks, MKCL, SBCL. The following implementations
+only provide ASDF 2: MOCL, XCL. The following implementations don't
+provide ASDF: Corman CL, GCL, Genera, MCL, SCL. The latter
+implementations are not actively maintained (except maybe GCL); if some
+of them are ever released again, they probably will include ASDF 3.
+
+ For maximum convenience you might want to have ASDF loaded whenever
+you start your Lisp implementation, for example by loading it from the
+startup script or dumping a custom core -- check your Lisp
+implementation's manual for details. SLIME notably sports a
+'slime-asdf' contrib that makes life easier with ASDF.
+
+ ---------- Footnotes ----------
+
+ (1) NB: all implementations except GNU CLISP also accept '(require
+"ASDF")', '(require 'asdf)' and '(require :asdf)'. For portability's
+sake, you should use '(require "asdf")'.
+
+
+File: asdf.info, Node: Checking whether ASDF is loaded, Next: Upgrading ASDF, Prev: Loading a pre-installed ASDF, Up: Loading ASDF
+
+3.2 Checking whether ASDF is loaded
</span> ===================================
<span style="color: #000000;background-color: #ffdddd">-To check whether ASDF is properly loaded in your current Lisp image,
-you can run this form:
</span><span style="color: #000000;background-color: #ddffdd">+To check that ASDF is properly loaded, you can run this form:
</span>
(asdf:asdf-version)
<span style="color: #000000;background-color: #ffdddd">- If it returns a string, that is the version of ASDF that is
-currently installed.
</span><span style="color: #000000;background-color: #ddffdd">+ If it returns a string, that is the version of ASDF that is currently
+installed. If that version is suitably recent (say, 3.1.2 or later),
+then you can skip directly to next chapter: *Note Configuring ASDF::.
</span>
If it raises an error, then either ASDF is not loaded, or you are
<span style="color: #000000;background-color: #ffdddd">-using an old version of ASDF.
-
- You can check whether an old version is loaded by checking if the
-ASDF package is present. The form below will allow you to
-programmatically determine whether a recent version is loaded, an old
-version is loaded, or none at all:
-
- (when (find-package :asdf)
- (let ((ver (symbol-value (or (find-symbol (string :*asdf-version*) :asdf)
- (find-symbol (string :*asdf-revision*) :asdf)))))
- (etypecase ver
- (string ver)
- (cons (with-output-to-string (s)
- (loop for (n . m) on ver do (princ n s) (when m (princ "." s)))))
- (null "1.0"))))
</span><span style="color: #000000;background-color: #ddffdd">+using a very old version of ASDF, and need to install ASDF 3.
</span>
<span style="color: #000000;background-color: #ffdddd">- If it returns `nil' then ASDF is not installed. Otherwise it should
-return a string. If it returns `"1.0"', then it can actually be any
-version before 1.77 or so, or some buggy variant of 1.x.
</span><span style="color: #000000;background-color: #ddffdd">+ For more precision in detecting versions old and new, *note How do I
+detect the ASDF version?::.
</span>
If you are experiencing problems with ASDF, please try upgrading to
the latest released version, using the method below, before you contact
us and raise an issue.
<span style="color: #000000;background-color: #ffdddd">-2.3 Upgrading ASDF
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Upgrading ASDF, Next: Replacing your implementation's ASDF, Prev: Checking whether ASDF is loaded, Up: Loading ASDF
+
+3.3 Upgrading ASDF
</span> ==================
<span style="color: #000000;background-color: #ffdddd">-If your implementation provides ASDF 3 or later, you only need to
-`(require "asdf")': ASDF will automatically look whether an updated
-version of itself is available amongst the regularly configured
-systems, before it compiles anything else. See *note Configuring
-ASDF:: below.
</span><span style="color: #000000;background-color: #ddffdd">+If your implementation already provides ASDF 3 or later (and it should),
+but you want a more recent ASDF version than your implementation
+provides, then you just need to ensure the more recent ASDF is installed
+in a configured path, like any other system. We recommend you download
+an official tarball or checkout a release from git into
+'~/common-lisp/asdf/'. (*note Configuring ASDF to find your systems::).
</span>
<span style="color: #000000;background-color: #ffdddd">- If your implementation does provide ASDF 2 or later, but not ASDF 3
-or later, and you want to upgrade to a more recent version, you need to
-install and configure your ASDF as above, and additionally, you need to
-explicitly tell ASDF to load itself, right after you require your
-implementation's old ASDF 2:
</span><span style="color: #000000;background-color: #ddffdd">+ Once the source code for ASDF is installed, you don't need any extra
+step to load it beyond the usual '(require "asdf")': ASDF 3 will
+automatically look whether an updated version of itself is available
+amongst the regularly configured systems, before it compiles anything
+else.
</span>
<span style="color: #000000;background-color: #ffdddd">- (require "asdf")
- (asdf:load-system :asdf)
</span><span style="color: #000000;background-color: #ddffdd">+ If your implementation fails to provide ASDF 3 or later, *note
+Replacing your implementation's ASDF::.
+
+
+File: asdf.info, Node: Replacing your implementation's ASDF, Next: Loading ASDF from source, Prev: Upgrading ASDF, Up: Loading ASDF
+
+3.4 Replacing your implementation's ASDF
+========================================
+
+All maintained implementations now provide ASDF 3 in their latest
+release. If your doesn't, we recommend you upgrade it.
+
+ Now, if you insist on using an old implementation that didn't provide
+ASDF or provided an old version, we recommend installing a recent ASDF,
+as explained below, into your implementation's installation directory.
+Thus your modified implementation will now provide ASDF 3. This
+requires proper write permissions and may necessitate execution as a
+system administrator.
+
+ The ASDF source repository contains a tool to help you upgrade your
+implementation's ASDF. You can invoke it from the shell command-line as
+'tools/asdf-tools install-asdf lispworks' (where you can replace
+'lispworks' by the name of the relevant implementation), or you can
+'(load "tools/install-asdf.lisp")' from your Lisp REPL.
+
+ This script works on Allegro CL, Clozure CL, CMU CL, ECL, GCL, GNU
+CLISP, LispWorks, MKCL, SBCL, SCL, XCL. It doesn't work on ABCL, Corman
+CL, Genera, MCL, MOCL. Happily, ABCL is usually pretty up to date and
+shouldn't need that script. GCL requires a very recent version, and
+hasn't been tested much. Corman CL, Genera, MCL are obsolete anyway.
+MOCL is incomplete.
</span>
<span style="color: #000000;background-color: #ffdddd">- If on the other hand, your implementation only provides an old ASDF,
-you will require a special configuration step and an old-style loading.
-Take special attention to not omit the trailing directory separator `/'
-at the end of your pathname:
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Loading ASDF from source, Prev: Replacing your implementation's ASDF, Up: Loading ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">- (require "asdf")
- (push #p"/PATH/TO/NEW/ASDF/" asdf:*central-registry*)
- (asdf:oos 'asdf:load-op :asdf)
-
- Note that ASDF 1 won't redirect its output files, or at least won't
-do it according to your usual ASDF 2 configuration. You therefore need
-write access on the directory where you install the new ASDF, and make
-sure you're not using it for multiple mutually incompatible
-implementations. At worst, you may have to have multiple copies of the
-new ASDF, e.g. one per implementation installation, to avoid clashes.
-Note that to our knowledge all implementations that provide ASDF
-provide ASDF 2 in their latest release, so you may want to upgrade your
-implementation rather than go through that hoop.
-
- Finally, if you are using an unmaintained implementation that does
-not provide ASDF at all, see *note Loading an otherwise installed ASDF:
-Loading ASDF. below.
-
- Note that there are some limitations to upgrading ASDF:
- * Previously loaded ASDF extension becomes invalid, and will need to
- be reloaded. This applies to e.g. CFFI-Grovel, or to hacks used
- by ironclad, etc. Since it isn't possible to automatically detect
- what extensions are present that need to be invalidated, ASDF will
- actually invalidate all previously loaded systems when it is
- loaded on top of a different ASDF version, starting with ASDF
- 2.014.8 (as far as releases go, 2.015); and it will automatically
- attempt this self-upgrade as its very first step starting with
- ASDF 3.
-
- * For this an many other reasons, it important reason to load,
- configure and upgrade ASDF (if needed) as one of the very first
- things done by your build and startup scripts. Until all
- implementations provide ASDF 3 or later, it is safer if you
- upgrade ASDF and its extensions as a special step at the very
- beginning of whatever script you are running, before you start
- using ASDF to load anything else; even afterwards, it is still a
- good idea, to avoid having to load and reload code twice as it
- gets invalidated.
-
- * Until all implementations provide ASDF 3 or later, it is unsafe to
- upgrade ASDF as part of loading a system that depends on a more
- recent version of ASDF, since the new one might shadow the old one
- while the old one is running, and the running old one will be
- confused when extensions are loaded into the new one. In the
- meantime, we recommend that your systems should _not_ specify
- `:depends-on (:asdf)', or `:depends-on ((:version :asdf "2.010"))',
- but instead that they check that a recent enough ASDF is installed,
- with such code as:
- (unless (or #+asdf2 (asdf:version-satisfies
- (asdf:asdf-version) *required-asdf-version*))
- (error "FOO requires ASDF ~A or later." *required-asdf-version*))
-
- * Until all implementations provide ASDF 3 or later, it is unsafe
- for a system to transitively depend on ASDF and not directly
- depend on ASDF; if any of the system you use either depends-on
- asdf, system-depends-on asdf, or transitively does, you should
- also do as well.
-
-2.4 Loading an otherwise installed ASDF
-=======================================
-
-If your implementation doesn't include ASDF, if for some reason the
-upgrade somehow fails, does not or cannot apply to your case, you will
-have to install the file `asdf.lisp' somewhere and load it with:
</span><span style="color: #000000;background-color: #ddffdd">+3.5 Loading ASDF from source
+============================
+
+If you write build scripts that must remain portable to old machines
+with old implementations that you cannot ensure have been upgraded or
+modified to provide a recent ASDF, you may have to install the file
+'asdf.lisp' somewhere and load it with:
</span>
(load "/path/to/your/installed/asdf.lisp")
<span style="color: #000000;background-color: #ffdddd">- The single file `asdf.lisp' is all you normally need to use ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+ The single file 'asdf.lisp' is all you normally need to use ASDF.
</span>
You can extract this file from latest release tarball on the ASDF
<span style="color: #000000;background-color: #ffdddd">-website (http://common-lisp.net/project/asdf/). If you are daring and
</span><span style="color: #000000;background-color: #ddffdd">+website (https://common-lisp.net/project/asdf/). If you are daring and
</span> willing to report bugs, you can get the latest and greatest version of
ASDF from its git repository. *Note Getting the latest version::.
<span style="color: #000000;background-color: #ffdddd">- For maximum convenience you might want to have ASDF loaded whenever
-you start your Lisp implementation, for example by loading it from the
-startup script or dumping a custom core -- check your Lisp
-implementation's manual for details.
</span><span style="color: #000000;background-color: #ddffdd">+ For scripts that try to use ASDF simply via 'require' at first, and
+make heroic attempts to load it the hard way if at first they don't
+succeed, see 'tools/load-asdf.lisp' distributed with the ASDF source
+repository, or the code of 'cl-launch' (https://cliki.net/cl-launch).
</span>
File: asdf.info, Node: Configuring ASDF, Next: Using ASDF, Prev: Loading ASDF, Up: Top
<span style="color: #000000;background-color: #ffdddd">-3 Configuring ASDF
</span><span style="color: #000000;background-color: #ddffdd">+4 Configuring ASDF
</span> ******************
<span style="color: #000000;background-color: #ffdddd">-3.1 Configuring ASDF to find your systems
-=========================================
-
-So it may compile and load your systems, ASDF must be configured to find
-the `.asd' files that contain system definitions.
-
- Since ASDF 2, the preferred way to configure where ASDF finds your
-systems is the `source-registry' facility, fully described in its own
-chapter of this manual. *Note Controlling where ASDF searches for
-systems::.
</span><span style="color: #000000;background-color: #ddffdd">+For standard use cases, ASDF should work pretty much out of the box. We
+recommend you skim the sections on configuring ASDF to find your systems
+and choose the method of installing Lisp software that works best for
+you. Then skip directly to *Note Using ASDF::. That will probably be
+enough. You are unlikely to have to worry about the way ASDF stores
+object files, and resetting the ASDF configuration is usually only
+needed in corner cases.
</span>
<span style="color: #000000;background-color: #ffdddd">- The default location for a user to install Common Lisp software is
-under `~/.local/share/common-lisp/source/'. If you install software
-there (it can be a symlink), you don't need further configuration. If
-you're installing software yourself at a location that isn't standard,
-you have to tell ASDF where you installed it. See below. If you're
-using some tool to install software (e.g. Quicklisp), the authors of
-that tool should already have configured ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
</span>
<span style="color: #000000;background-color: #ffdddd">- The simplest way to add a path to your search path, say
-`/home/luser/.asd-link-farm/' is to create the directory
-`~/.config/common-lisp/source-registry.conf.d/' and there create a file
-with any name of your choice, and with the type `conf', for instance
-`42-asd-link-farm.conf' containing the line:
</span><span style="color: #000000;background-color: #ddffdd">+* Configuring ASDF to find your systems::
+* Configuring ASDF to find your systems --- old style::
+* Configuring where ASDF stores object files::
+* Resetting the ASDF configuration::
</span>
<span style="color: #000000;background-color: #ffdddd">- `(:directory "/home/luser/.asd-link-farm/")'
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Configuring ASDF to find your systems, Next: Configuring ASDF to find your systems --- old style, Prev: Configuring ASDF, Up: Configuring ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">- If you want all the subdirectories under `/home/luser/lisp/' to be
-recursively scanned for `.asd' files, instead use:
</span><span style="color: #000000;background-color: #ddffdd">+4.1 Configuring ASDF to find your systems
+=========================================
</span>
<span style="color: #000000;background-color: #ffdddd">- `(:tree "/home/luser/lisp/")'
</span><span style="color: #000000;background-color: #ddffdd">+In order to compile and load your systems, ASDF must be configured to
+find the '.asd' files that contain system definitions.
+
+ There are a number of different techniques for setting yourself up
+with ASDF, starting from easiest to the most complex:
+
+ * Put all of your systems in one of the standard locations,
+ subdirectories of
+ * '~/common-lisp/' or
+ * '~/.local/share/common-lisp/source/'.
+ If you install software there, you don't need further
+ configuration.(1) You can then skip to the next section. *Note
+ Loading a system::.
+
+ * If you're using some tool to install software (e.g. Quicklisp),
+ the authors of that tool should already have configured ASDF.
+
+ * If you have more specific desires about how to lay out your
+ software on disk, the preferred way to configure where ASDF finds
+ your systems is the 'source-registry' facility, fully described in
+ its own chapter of this manual. *Note Controlling where ASDF
+ searches for systems::. Here is a quick recipe for getting
+ started.
+
+ First create the directory
+ '~/.config/common-lisp/source-registry.conf.d/'(2); there create a
+ file with any name of your choice but with the type 'conf'(3), for
+ instance '50-luser-lisp.conf'; in this file, add the following line
+ to tell ASDF to recursively scan all the subdirectories under
+ '/home/luser/lisp/' for '.asd' files: '(:tree "/home/luser/lisp/")'
+
+ That's enough. You may replace '/home/luser/lisp/' by wherever you
+ want to install your source code. You don't actually need to
+ specify anything if you use the default '~/common-lisp/' as above
+ and your implementation provides ASDF 3.1.2 or later. If your
+ implementation provides an earlier variant of ASDF 3, you might
+ want to specify '(:tree (:home "common-lisp/"))' for bootstrap
+ purposes, then install a recent source tree of ASDF under
+ '~/common-lisp/asdf/'.
+
+ If you prefer to use a "link farm", which is faster to use but
+ costlier to manage than a recursive traversal, say at
+ '/home/luser/.asd-link-farm/', then you may instead (or
+ additionally) create a file '42-asd-link-farm.conf', containing the
+ line: '(:directory "/home/luser/.asd-link-farm/")'
+
+ ASDF will automatically read your configuration the first time you
+ try to find a system. If necessary, you can reset the
+ source-registry configuration with:
+
+ (asdf:clear-source-registry)
+
+ * In earlier versions of ASDF, the system source registry was
+ configured using a global variable, 'asdf:*central-registry*'. For
+ more details about this, see the following section, *note
+ Configuring ASDF to find your systems --- old style::. Unless you
+ need to understand this, skip directly to *note Configuring where
+ ASDF stores object files::.
</span>
Note that your Operating System distribution or your system
administrator may already have configured system-managed libraries for
you.
<span style="color: #000000;background-color: #ffdddd">- The required `.conf' extension allows you to have disabled files or
-editor backups (ending in `~'), and works portably (for instance, it is
-a pain to allow both empty and non-empty extension on CLISP). Excluded
-are files the name of which start with a `.' character. It is
-customary to start the filename with two digits that specify the order
-in which the directories will be scanned.
</span><span style="color: #000000;background-color: #ddffdd">+ ---------- Footnotes ----------
+
+ (1) '~/common-lisp/' is only included in the default configuration
+starting with ASDF 3.1.2 or later. If your implementation provides an
+earlier variant of ASDF, you may need to explicitly configure it to use
+this path, as further explained.
+
+ (2) For Windows users, and starting with ASDF 3.1.5, start from your
+'%LOCALAPPDATA%', which is usually '~/AppData/Local/' (but you can ask
+in a 'CMD.EXE' terminal 'echo %LOCALAPPDATA%' to make sure) and
+underneath create a subpath
+'config/common-lisp/source-registry.conf.d/'.
+
+ (3) By requiring the '.conf' extension, and ignoring other files,
+ASDF allows you to have disabled files, editor backups, etc. in the
+same directory with your active configuration files.
</span>
<span style="color: #000000;background-color: #ffdddd">- ASDF will automatically read your configuration the first time you
-try to find a system. You can reset the source-registry configuration
-with:
</span><span style="color: #000000;background-color: #ddffdd">+ ASDF will also ignore files whose names start with a '.' character.
</span>
<span style="color: #000000;background-color: #ffdddd">- (asdf:clear-source-registry)
</span><span style="color: #000000;background-color: #ddffdd">+ It is customary to start the filename with two digits, to control the
+sorting of the 'conf' files in the source registry directory, and thus
+the order in which the directories will be scanned.
</span>
<span style="color: #000000;background-color: #ffdddd">- And you probably should do so before you dump your Lisp image, if
-the configuration may change between the machine where you save it at
-the time you save it and the machine you resume it at the time you
-resume it. Actually, you should use `(asdf:clear-configuration)'
-before you dump your Lisp image, which includes the above.
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Configuring ASDF to find your systems --- old style, Next: Configuring where ASDF stores object files, Prev: Configuring ASDF to find your systems, Up: Configuring ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">-3.2 Configuring ASDF to find your systems -- old style
</span><span style="color: #000000;background-color: #ddffdd">+4.2 Configuring ASDF to find your systems -- old style
</span> ======================================================
<span style="color: #000000;background-color: #ffdddd">-The old way to configure ASDF to find your systems is by `push'ing
-directory pathnames onto the variable `asdf:*central-registry*'.
</span><span style="color: #000000;background-color: #ddffdd">+The old way to configure ASDF to find your systems is by 'push'ing
+directory pathnames onto the variable 'asdf:*central-registry*'.
</span>
You must configure this variable between the time you load ASDF and
the time you first try to use it. Loading and configuring ASDF
presumably happen as part of some initialization script that builds or
<span style="color: #000000;background-color: #ffdddd">-starts your Common Lisp software system. (For instance, some SBCL
-users used to put it in their `~/.sbclrc'.)
</span><span style="color: #000000;background-color: #ddffdd">+starts your Common Lisp software system. (For instance, some SBCL users
+used to put it in their '~/.sbclrc'.)
</span>
<span style="color: #000000;background-color: #ffdddd">- The `asdf:*central-registry*' is empty by default in ASDF 2 or ASDF
</span><span style="color: #000000;background-color: #ddffdd">+ The 'asdf:*central-registry*' is empty by default in ASDF 2 or ASDF
</span> 3, but is still supported for compatibility with ASDF 1. When used, it
<span style="color: #000000;background-color: #ffdddd">-takes precedence over the above source-registry(1).
</span><span style="color: #000000;background-color: #ddffdd">+takes precedence over the above source-registry.(1)
</span>
<span style="color: #000000;background-color: #ffdddd">- For instance, if you wanted ASDF to find the `.asd' file
-`/home/me/src/foo/foo.asd' your initialization script could after it
-loads ASDF with `(require "asdf")' configure it with:
</span><span style="color: #000000;background-color: #ddffdd">+ For example, let's say you want ASDF to find the '.asd' file
+'/home/me/src/foo/foo.asd'. In your lisp initialization file, you could
+have the following:
</span>
<span style="color: #000000;background-color: #ddffdd">+ (require "asdf")
</span> (push "/home/me/src/foo/" asdf:*central-registry*)
Note the trailing slash: when searching for a system, ASDF will
evaluate each entry of the central registry and coerce the result to a
<span style="color: #000000;background-color: #ffdddd">-pathname(2) at which point the presence of the trailing directory name
-separator is necessary to tell Lisp that you're discussing a directory
-rather than a file.
-
- Typically, however, there are a lot of `.asd' files, and a common
-idiom was to have to put a bunch of _symbolic links_ to `.asd' files in
-a common directory and push _that_ directory (the "link farm") to the
-`asdf:*central-registry*' instead of pushing each of the many involved
-directories to the `asdf:*central-registry*'. ASDF knows how to follow
-such _symlinks_ to the actual file location when resolving the paths of
-system components (on Windows, you can use Windows shortcuts instead of
-POSIX symlinks; if you try aliases under MacOS, we are curious to hear
-about your experience).
-
- For example, if `#p"/home/me/cl/systems/"' (note the trailing slash)
-is a member of `*central-registry*', you could set up the system FOO
-for loading with asdf with the following commands at the shell:
</span><span style="color: #000000;background-color: #ddffdd">+pathname.(2) The trailing directory name separator is necessary to tell
+Lisp that you're discussing a directory rather than a file. If you
+leave it out, ASDF is likely to look in '/home/me/src/' instead of
+'/home/me/src/foo/' as you intended, and fail to find your system
+definition.
+
+ Typically there are a lot of '.asd' files, and a common idiom was to
+put _symbolic links_ to all of one's '.asd' files in a common directory
+and push _that_ directory (the "link farm") onto
+'asdf:*central-registry*', instead of pushing each individual system
+directory.
+
+ ASDF knows to follow _symlinks_ to the actual location of the
+systems.(3)
+
+ For example, if '#p"/home/me/cl/systems/"' is an element of
+'*central-registry*', you could set up the system FOO as follows:
</span>
$ cd /home/me/cl/systems/
$ ln -s ~/src/foo/foo.asd .
This old style for configuring ASDF is not recommended for new users,
<span style="color: #000000;background-color: #ffdddd">-but it is supported for old users, and for users who want to
-programmatically control what directories are added to the ASDF search
-path.
</span><span style="color: #000000;background-color: #ddffdd">+but it is supported for old users, and for users who want a simple way
+to programmatically control what directories are added to the ASDF
+search path.
</span>
<span style="color: #000000;background-color: #ffdddd">-3.3 Configuring where ASDF stores object files
-==============================================
</span><span style="color: #000000;background-color: #ddffdd">+ ---------- Footnotes ----------
</span>
<span style="color: #000000;background-color: #ffdddd">-ASDF lets you configure where object files will be stored. Sensible
-defaults are provided and you shouldn't normally have to worry about it.
</span><span style="color: #000000;background-color: #ddffdd">+ (1) It is possible to further customize the system definition file
+search. That's considered advanced use, and covered later: search
+forward for '*system-definition-search-functions*'. *Note Defining
+systems with defsystem::.
</span>
<span style="color: #000000;background-color: #ffdddd">- This allows the same source code repository may be shared between
-several versions of several Common Lisp implementations, between
-several users using different compilation options and without write
-privileges on shared source directories, etc. This also allows to keep
-source directories uncluttered by plenty of object files.
</span><span style="color: #000000;background-color: #ddffdd">+ (2) ASDF will indeed call 'eval' on each entry. It will skip entries
+that evaluate to 'nil'.
</span>
<span style="color: #000000;background-color: #ffdddd">- Starting with ASDF 2, the `asdf-output-translations' facility was
-added to ASDF itself, that controls where object files will be stored.
-This facility is fully described in a chapter of this manual, *note
-Controlling where ASDF saves compiled files::.
</span><span style="color: #000000;background-color: #ddffdd">+ Strings and pathname objects are self-evaluating, in which case the
+'eval' step does nothing; but you may push arbitrary s-expressions onto
+the central registry. These s-expressions may be evaluated to compute
+context-dependent entries, e.g. things that depend on the value of
+shell variables or the identity of the user.
</span>
<span style="color: #000000;background-color: #ffdddd">- The simplest way to add a translation to your search path, say from
-`/foo/bar/baz/quux/' to `/where/i/want/my/fasls/' is to create the
-directory `~/.config/common-lisp/asdf-output-translations.conf.d/' and
-there create a file with any name of your choice and the type `conf',
-for instance `42-bazquux.conf' containing the line:
</span><span style="color: #000000;background-color: #ddffdd">+ The variable 'asdf:*central-registry*' is thus a list of "system
+directory designators". A "system directory designator" is a form which
+will be evaluated whenever a system is to be found, and must evaluate to
+a directory to look in (or 'NIL'). By "directory", we mean "designator
+for a pathname with a non-empty DIRECTORY component".
</span>
<span style="color: #000000;background-color: #ffdddd">- `("/foo/bar/baz/quux/" "/where/i/want/my/fasls/")'
</span><span style="color: #000000;background-color: #ddffdd">+ (3) On Windows, you can use Windows shortcuts instead of POSIX
+symlinks. if you try aliases under MacOS, we are curious to hear about
+your experience.
</span>
<span style="color: #000000;background-color: #ffdddd">- To disable output translations for source under a given directory,
-say `/toto/tata/' you can create a file `40-disable-toto.conf' with the
-line:
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Configuring where ASDF stores object files, Next: Resetting the ASDF configuration, Prev: Configuring ASDF to find your systems --- old style, Up: Configuring ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">- `("/toto/tata/")'
</span><span style="color: #000000;background-color: #ddffdd">+4.3 Configuring where ASDF stores object files
+==============================================
</span>
<span style="color: #000000;background-color: #ffdddd">- To wholly disable output translations for all directories, you can
-create a file `00-disable.conf' with the line:
</span><span style="color: #000000;background-color: #ddffdd">+ASDF lets you configure where object files will be stored. Sensible
+defaults are provided and you shouldn't normally have to worry about it.
</span>
<span style="color: #000000;background-color: #ffdddd">- `(t t)'
</span><span style="color: #000000;background-color: #ddffdd">+ This allows the same source code repository to be shared between
+several versions of several Common Lisp implementations, between several
+users using different compilation options, with users who lack write
+privileges on shared source directories, etc. This also keeps source
+directories from being cluttered with object/fasl files.
</span>
<span style="color: #000000;background-color: #ffdddd">- Note that your Operating System distribution or your system
-administrator may already have configured translations for you. In
-absence of any configuration, the default is to redirect everything
-under an implementation-dependent subdirectory of
-`~/.cache/common-lisp/'. *Note Controlling where ASDF searches for
-systems::, for full details.
-
- The required `.conf' extension allows you to have disabled files or
-editor backups (ending in `~'), and works portably (for instance, it is
-a pain to allow both empty and non-empty extension on CLISP). Excluded
-are files the name of which start with a `.' character. It is
-customary to start the filename with two digits that specify the order
-in which the directories will be scanned.
-
- ASDF will automatically read your configuration the first time you
-try to find a system. You can reset the source-registry configuration
-with:
-
- (asdf:clear-output-translations)
-
- And you probably should do so before you dump your Lisp image, if
-the configuration may change between the machine where you save it at
-the time you save it and the machine you resume it at the time you
-resume it. (Once again, you should use `(asdf:clear-configuration)'
-before you dump your Lisp image, which includes the above.)
-
- Finally note that before ASDF 2, other ASDF add-ons offered the same
</span><span style="color: #000000;background-color: #ddffdd">+ Starting with ASDF 2, the 'asdf-output-translations' facility was
+added to ASDF itself. This facility controls where object files will be
+stored. This facility is fully described in a chapter of this manual,
+*note Controlling where ASDF saves compiled files::.
+
+ Note that before ASDF 2, other ASDF add-ons offered the same
</span> functionality, each in subtly different and incompatible ways:
ASDF-Binary-Locations, cl-launch, common-lisp-controller.
ASDF-Binary-Locations is now not needed anymore and should not be used.
cl-launch 3.000 and common-lisp-controller 7.2 have been updated to
<span style="color: #000000;background-color: #ffdddd">-just delegate this functionality to ASDF.
-
- ---------- Footnotes ----------
-
- (1) It is possible to further customize the system definition file
-search. That's considered advanced use, and covered later: search
-forward for `*system-definition-search-functions*'. *Note Defining
-systems with defsystem::.
-
- (2) ASDF will indeed call `eval' on each entry. It will also skip
-entries that evaluate to `nil'.
-
- Strings and pathname objects are self-evaluating, in which case the
-`eval' step does nothing; but you may push arbitrary SEXP onto the
-central registry, that will be evaluated to compute e.g. things that
-depend on the value of shell variables or the identity of the user.
-
- The variable `asdf:*central-registry*' is thus a list of "system
-directory designators". A "system directory designator" is a form
-which will be evaluated whenever a system is to be found, and must
-evaluate to a directory to look in. By "directory" here, we mean
-"designator for a pathname with a supplied DIRECTORY component".
</span><span style="color: #000000;background-color: #ddffdd">+delegate object file placement to ASDF.
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: Using ASDF, Next: Defining systems with defsystem, Prev: Configuring ASDF, Up: Top
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: Resetting the ASDF configuration, Prev: Configuring where ASDF stores object files, Up: Configuring ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">-3.4 Resetting Configuration
-===========================
</span><span style="color: #000000;background-color: #ddffdd">+4.4 Resetting the ASDF configuration
+====================================
</span>
When you dump and restore an image, or when you tweak your
configuration, you may want to reset the ASDF configuration. For that
you may use the following function:
-- Function: clear-configuration
<span style="color: #000000;background-color: #ffdddd">- undoes any ASDF configuration, regarding source-registry or
</span><span style="color: #000000;background-color: #ddffdd">+ Undoes any ASDF configuration regarding source-registry or
</span> output-translations.
<span style="color: #000000;background-color: #ffdddd">- If you use SBCL, CMUCL or SCL, you may use this snippet so that the
-ASDF configuration be cleared automatically as you dump an image:
-
- #+(or cmu sbcl scl)
- (pushnew 'clear-configuration
- #+(or cmu scl) ext:*before-save-initializations*
- #+sbcl sb-ext:*save-hooks*)
</span><span style="color: #000000;background-color: #ddffdd">+ This function is pushed onto the 'uiop:*image-dump-hook*' by default,
+which means that if you save an image using 'uiop:dump-image', or via
+'asdf:image-op' and 'asdf:program-op', it will be automatically called
+to clear your configuration. If for some reason you prefer to call your
+implementation's underlying functionality, be sure to call
+'clear-configuration' manually, or push it into your implementation's
+equivalent of 'uiop:*image-dump-hook*', e.g. 'sb-ext:*save-hooks*' on
+SBCL, or 'ext:*before-save-initializations*' on CMUCL and SCL, etc.
</span>
<span style="color: #000000;background-color: #ffdddd">- For compatibility with all Lisp implementations, however, you might
-want instead your build script to explicitly call
-`(asdf:clear-configuration)' at an appropriate moment before dumping.
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Using ASDF, Next: Defining systems with defsystem, Prev: Configuring ASDF, Up: Top
</span>
<span style="color: #000000;background-color: #ffdddd">-4 Using ASDF
</span><span style="color: #000000;background-color: #ddffdd">+5 Using ASDF
</span> ************
<span style="color: #000000;background-color: #ffdddd">-4.1 Loading a system
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* Loading a system::
+* Convenience Functions::
+* Moving on::
+
+
+File: asdf.info, Node: Loading a system, Next: Convenience Functions, Prev: Using ASDF, Up: Using ASDF
+
+5.1 Loading a system
</span> ====================
The system FOO is loaded (and compiled, if necessary) by evaluating the
<span style="color: #aaaaaa">@@ -542,72 +757,90 @@ following Lisp form:
</span>
(asdf:load-system :FOO)
<span style="color: #000000;background-color: #ffdddd">- On some implementations (namely recent versions of ABCL, Allegro CL,
-Clozure CL, CMUCL, ECL, GNU CLISP, LispWorks, MKCL, SBCL and XCL), ASDF
-hooks into the `CL:REQUIRE' facility and you can just use:
</span><span style="color: #000000;background-color: #ddffdd">+ On some implementations (*note Convenience Functions::), ASDF hooks
+into the 'cl:require' facility and you can just use:
</span>
(require :FOO)
<span style="color: #000000;background-color: #ffdddd">- In older versions of ASDF, you needed to use `(asdf:oos
-'asdf:load-op :FOO)'. If your ASDF is too old to provide
-`asdf:load-system' though we recommend that you upgrade to ASDF 3.
-*Note Loading an otherwise installed ASDF: Loading ASDF.
-
- Note the name of a system is specified as a string or a symbol,
-typically a keyword. If a symbol (including a keyword), its name is
-taken and lowercased. The name must be a suitable value for the
-`:name' initarg to `make-pathname' in whatever filesystem the system is
-to be found. The lower-casing-symbols behaviour is unconventional, but
-was selected after some consideration. Observations suggest that the
-type of systems we want to support either have lowercase as customary
-case (unix, mac, windows) or silently convert lowercase to uppercase
-(lpns), so this makes more sense than attempting to use `:case :common',
-which is reported not to work on some implementations
-
-4.2 Other Operations
-====================
</span><span style="color: #000000;background-color: #ddffdd">+ Note that the canonical name of a system is a string, conventionally
+lowercase. A system name can also be specified as a symbol (including a
+keyword), in which case its 'symbol-name' is taken and lowercased. The
+name must be a suitable value for the ':name' initarg to 'make-pathname'
+in whatever filesystem the system is to be found.
</span>
<span style="color: #000000;background-color: #ffdddd">-ASDF provides three commands for the most common system operations:
-`load-system', `compile-system' or `test-system'. It also provides
-`require-system', a version of `load-system' that skips trying to
-update systems that are already loaded.
</span><span style="color: #000000;background-color: #ddffdd">+ The lower-casing-symbols behaviour is unconventional, but was
+selected after some consideration. The type of systems we want to
+support either have lowercase as customary case (Unix, Mac, Windows) or
+silently convert lowercase to uppercase (lpns).
</span>
<span style="color: #000000;background-color: #ffdddd">- Because ASDF is an extensible system for defining _operations_ on
-_components_, it also provides a generic function `operate' (which is
-usually abbreviated by `oos'). You'll use `oos' whenever you want to
-do something beyond compiling, loading and testing.
-
- Output from ASDF and ASDF extensions are supposed to be sent to the
-CL stream `*standard-output*', and so rebinding that stream around
-calls to `asdf:operate' should redirect all output from ASDF operations.
-
- Reminder: before ASDF can operate on a system, however, it must be
-able to find and load that system's definition. *Note Configuring ASDF
-to find your systems: Configuring ASDF.
-
- For the advanced users, note that `require-system' calls
-`load-system' with keyword arguments `:force-not
-(already-loaded-systems)'. `already-loaded-systems' returns a list of
-the names of loaded systems. `load-system' applies `operate' with the
-operation from `*load-system-operation*', which by default is `load-op',
-the system, and any provided keyword arguments.
-
-4.3 Summary
-===========
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Convenience Functions, Next: Moving on, Prev: Loading a system, Up: Using ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">-To use ASDF:
</span><span style="color: #000000;background-color: #ddffdd">+5.2 Convenience Functions
+=========================
+
+ASDF provides three commands for the most common system operations:
+'load-system', 'compile-system', and 'test-system'. It also provides
+'require-system', a version of 'load-system' that skips trying to update
+systems that are already loaded. And it provides 'make', a function
+that uses whichever operation was specified by the author of the target
+system, which by default behaves like 'load-system'.
</span>
<span style="color: #000000;background-color: #ffdddd">- * Load ASDF itself into your Lisp image, either through `(require
- "asdf")' or else through `(load "/path/to/asdf.lisp")'.
</span><span style="color: #000000;background-color: #ddffdd">+ Because ASDF is an extensible system for defining _operations_ on
+_components_, it also provides a generic function 'operate', so you may
+arbitrarily operate on your systems beyond the default operations. (At
+the interactive REPL, users often use its shorter alias 'oos', which
+stands for operate-on-system, a name inherited from 'mk-defsystem'.)
+You'll use 'operate' whenever you want to do something beyond compiling,
+loading and testing.
+
+ Note that output from ASDF and ASDF extensions are sent to the CL
+stream '*standard-output*', so rebinding that stream around calls to
+'asdf:operate' should redirect all output from ASDF operations.
+
+ 'load-system' applies 'operate' with the operation from
+'*load-system-operation*' the system, and any provided keyword
+arguments. '*load-system-operation*' by default is 'load-op'; it would
+be 'load-bundle-op' by default on ECL, if only an implementation bug
+were fixed.
+
+ 'require-system' skips any update to systems that have already been
+loaded, in the spirit of 'cl:require'. It does it by calling
+'load-system' with a keyword option excluding already loaded
+systems.(1). On actively maintained free software implementations
+(namely recent versions of ABCL, Clozure CL, CMUCL, ECL, GNU CLISP, MKCL
+and SBCL), once ASDF itself is loaded, 'cl:require' too can load ASDF
+systems, by falling back on 'require-system' for module names not
+recognized by the implementation.
+
+ Note that 'cl:require' and 'require-system' are appropriate to load
+code that is not being modified during the current programming session.
+This notably includes the implementation-provided extension modules that
+'cl:require' can load. This also includes any number of ASDF systems
+that the user isn't either developing or debugging, for which a
+previously installed version is deemed to be satisfactory.
+'require-system' and through it 'cl:require' can load these systems
+without any problem. But for code that you are actively developing,
+debugging, or otherwise modifying, you should use 'load-system', so ASDF
+will pick on your modifications and transitively re-build the modified
+files and everything that depends on them.
+
+ Finally, starting with ASDF 3.1, a function 'make' is also available,
+that does "The Right Thing" with your system. The default behaviour is
+to load the system as if by 'load-system'; but instead of this default,
+system authors can specify the intended use of their system by
+specifying their desired operation with a ':build-operation' argument in
+the system definition.
</span>
<span style="color: #000000;background-color: #ffdddd">- * Make sure ASDF can find system definitions thanks to proper
- source-registry configuration.
</span><span style="color: #000000;background-color: #ddffdd">+ ---------- Footnotes ----------
</span>
<span style="color: #000000;background-color: #ffdddd">- * Load a system with `(asdf:load-system :my-system)' or use some
- other operation on some system of your choice.
</span><span style="color: #000000;background-color: #ddffdd">+ (1) For the curious, the option is ':force-not
+(already-loaded-systems)'.
</span>
<span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Moving on, Prev: Convenience Functions, Up: Using ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">-4.4 Moving on
</span><span style="color: #000000;background-color: #ddffdd">+5.3 Moving on
</span> =============
That's all you need to know to use ASDF to load systems written by
<span style="color: #aaaaaa">@@ -618,10 +851,10 @@ ASDF to define new operation and component types.
</span>
File: asdf.info, Node: Defining systems with defsystem, Next: The object model of ASDF, Prev: Using ASDF, Up: Top
<span style="color: #000000;background-color: #ffdddd">-5 Defining systems with defsystem
</span><span style="color: #000000;background-color: #ddffdd">+6 Defining systems with defsystem
</span> *********************************
<span style="color: #000000;background-color: #ffdddd">-This chapter describes how to use asdf to define systems and develop
</span><span style="color: #000000;background-color: #ddffdd">+This chapter describes how to use ASDF to define systems and develop
</span> software.
* Menu:
<span style="color: #aaaaaa">@@ -630,143 +863,249 @@ software.
</span> * A more involved example::
* The defsystem grammar::
* Other code in .asd files::
<span style="color: #000000;background-color: #ddffdd">+* The package-inferred-system extension::
</span>
File: asdf.info, Node: The defsystem form, Next: A more involved example, Prev: Defining systems with defsystem, Up: Defining systems with defsystem
<span style="color: #000000;background-color: #ffdddd">-5.1 The defsystem form
</span><span style="color: #000000;background-color: #ddffdd">+6.1 The defsystem form
</span> ======================
<span style="color: #000000;background-color: #ffdddd">-Systems can be constructed programmatically by instantiating components
-using `make-instance'. Most of the time, however, it is much more
-practical to use a static `defsystem' form. This section begins with
-an example of a system definition, then gives the full grammar of
-`defsystem'.
</span><span style="color: #000000;background-color: #ddffdd">+This section begins with an example of a system definition, then gives
+the full grammar of 'defsystem'.
</span>
<span style="color: #000000;background-color: #ffdddd">- Let's look at a simple system. This is a complete file that would
-usually be saved as `hello-lisp.asd':
</span><span style="color: #000000;background-color: #ddffdd">+ Let's look at a simple system. This is a complete file that should
+be saved as 'hello-lisp.asd' (in order that ASDF can find it when
+ordered to operate on the system named '"hello-lisp"').
</span>
<span style="color: #000000;background-color: #ffdddd">- (in-package :asdf)
</span><span style="color: #000000;background-color: #ddffdd">+ ;; Usual Lisp comments are allowed here
</span>
(defsystem "hello-lisp"
:description "hello-lisp: a sample Lisp system."
<span style="color: #000000;background-color: #ffdddd">- :version "0.2.1"
</span><span style="color: #000000;background-color: #ddffdd">+ :version "0.0.1"
</span> :author "Joe User <joe@example.com>"
:licence "Public Domain"
<span style="color: #000000;background-color: #ddffdd">+ :depends-on ("optima.ppcre" "command-line-arguments")
</span> :components ((:file "packages")
(:file "macros" :depends-on ("packages"))
(:file "hello" :depends-on ("macros"))))
Some notes about this example:
<span style="color: #000000;background-color: #ffdddd">- * The file starts with an `in-package' form to use package `asdf'.
- You could instead start your definition by using a qualified name
- `asdf:defsystem'.
-
- * If in addition to simply using `defsystem', you are going to
- define functions, create ASDF extension, globally bind symbols,
- etc., it is recommended that to avoid namespace pollution between
- systems, you should create your own package for that purpose, for
- instance replacing the above `(in-package :asdf)' with:
-
- (defpackage :foo-system
- (:use :cl :asdf))
-
- (in-package :foo-system)
-
- * The `defsystem' form defines a system named `hello-lisp' that
- contains three source files: `packages', `macros' and `hello'.
-
- * The file `macros' depends on `packages' (presumably because the
- package it's in is defined in `packages'), and the file `hello'
- depends on `macros' (and hence, transitively on `packages'). This
- means that ASDF will compile and load `packages' and `macros'
- before starting the compilation of file `hello'.
-
- * The files are located in the same directory as the file with the
- system definition. ASDF resolves symbolic links (or Windows
- shortcuts) before loading the system definition file and stores
- its location in the resulting system(1). This is a good thing
- because the user can move the system sources without having to
- edit the system definition.
-
- * Make sure you know how the `:version' numbers will be parsed!
- They are parsed as period-separated lists of integers. I.e., in
- the example, `0.2.1' is to be interpreted, roughly speaking, as
- `(0 2 1)'. In particular, version `0.2.1' is interpreted the same
- as `0.0002.1' and is strictly version-less-than version `0.20.1',
- even though the two are the same when interpreted as decimal
- fractions. Instead of a string representing the version, the
- `:version' argument can be an expression that is resolved to such
- a string using the following trivial domain-specific language: in
- addition to being a literal string, it can be an expression of the
- form `(:read-file-form <pathname-or-string> :at
- <access-at-specifier>)', which will be resolved by reading a form
- in the specified pathname (read as a subpathname of the current
- system if relative or a unix-namestring). You may use a
- `uiop:access-at' specifier with the (optional) `:at' keyword, by
- default the specifier is `0', meaning the first form is returned.
-
-
- ---------- Footnotes ----------
-
- (1) It is possible, though almost never necessary, to override this
-behaviour.
</span><span style="color: #000000;background-color: #ddffdd">+ * The 'defsystem' form defines a system named 'hello-lisp' that
+ contains three source files: 'packages.lisp', 'macros.lisp' and
+ 'hello.lisp'.
+
+ * The '.lisp' suffix is implicit for Lisp source files. The source
+ files are located in the same directory as the '.asd' file with the
+ system definition.
+
+ * The file 'macros' depends on 'packages' (presumably because the
+ package it's in is defined in 'packages'), and the file 'hello'
+ depends on 'macros' (and hence, transitively on 'packages'). This
+ means that ASDF will compile and load 'packages' then 'macros'
+ before starting the compilation of file 'hello'.
+
+ * This example system has external dependencies on two other systems,
+ 'optima.ppcre' (that provides a friendly interface to matching
+ regular expressions), and 'command-line-arguments' (that provides a
+ way to parse arguments passed from the shell command line). To use
+ this system, ASDF must be configured to find installed copies of
+ these systems; it will load them before it tries to compile and
+ load 'hello-lisp'.
+
+ * This system also defines a bunch of metadata. While it is optional
+ to define these fields (and other fields like ':bug-tracker',
+ ':mailto', ':long-name', ':long-description', ':source-control'),
+ it is strongly recommended to define the fields ':description',
+ ':version', ':author', and ':licence', especially if you intend
+ your software to be eventually included in Quicklisp.
+
+ * Make sure you know how the ':version' numbers will be parsed! Only
+ period-separated non-negative integers are accepted at present.
+ See below Version specifiers in *note The defsystem grammar::.
+
+ * This file contains a single form, the 'defsystem' declaration. No
+ 'in-package' form, no 'asdf:' package prefix, no nothing. Just the
+ one naked 'defsystem' form. This is what we recommend. More
+ complex system definition files are possible with arbitrary Lisp
+ code, but we recommend that you keep it simple if you can. This
+ will make your system definitions more robust and more
+ future-proof.
+
+ This is all you need to know to define simple systems. The next
+example is much more involved, to give you a glimpse of how you can do
+more complex things. However, since it's ultimately arbitrary Lisp
+code, there is no bottom to the rabbit hole.
</span>
File: asdf.info, Node: A more involved example, Next: The defsystem grammar, Prev: The defsystem form, Up: Defining systems with defsystem
<span style="color: #000000;background-color: #ffdddd">-5.2 A more involved example
</span><span style="color: #000000;background-color: #ddffdd">+6.2 A more involved example
</span> ===========================
<span style="color: #000000;background-color: #ffdddd">-Let's illustrate some more involved uses of `defsystem' via a slightly
</span><span style="color: #000000;background-color: #ddffdd">+Let's illustrate some more involved uses of 'defsystem' via a slightly
</span> convoluted example:
<span style="color: #000000;background-color: #ddffdd">+ (in-package :asdf-user)
+
</span> (defsystem "foo"
<span style="color: #000000;background-color: #ffdddd">- :version "1.0.0"
- :components ((:module "mod"
- :components ((:file "bar")
- (:file"baz")
- (:file "quux"))
- :perform (compile-op :after (op c)
- (do-something c))
- :explain (compile-op :after (op c)
- (explain-something c)))
- (:file "blah")))
-
- The `:module' component named `"mod"' is a collection of three files,
-which will be located in a subdirectory of the main code directory named
-`mod' (this location can be overridden; see the discussion of the
-`:pathname' option in *note The defsystem grammar::).
-
- The method-form tokens provide a shorthand for defining methods on
-particular components. This part
-
- :perform (compile-op :after (op c)
- (do-something c))
- :explain (compile-op :after (op c)
- (explain-something c))
-
- has the effect of
-
- (defmethod perform :after ((op compile-op) (c (eql ...)))
- (do-something c))
- (defmethod explain :after ((op compile-op) (c (eql ...)))
- (explain-something c))
-
- where `...' is the component in question. In this case `...' would
-expand to something like
-
- (find-component "foo" "mod")
-
- For more details on the syntax of such forms, see *note The
-defsystem grammar::. For more details on what these methods do, *note
-Operations:: in *note The object model of ASDF::.
</span><span style="color: #000000;background-color: #ddffdd">+ :version (:read-file-form "variables" :at (3 2))
+ :components
+ ((:file "package")
+ (:file "variables" :depends-on ("package"))
+ (:module "mod"
+ :depends-on ("package")
+ :serial t
+ :components ((:file "utils")
+ (:file "reader")
+ (:file "cooker")
+ (:static-file "data.raw"))
+ :output-files (compile-op (o c) (list "data.cooked"))
+ :perform (compile-op :after (o c)
+ (cook-data
+ :in (component-pathname (find-component c "data.raw"))
+ :out (first (output-files o c)))))
+ (:file "foo" :depends-on ("mod"))))
+
+ (defmethod action-description
+ ((o compile-op) (c (eql (find-component "foo" "mod"))))
+ "cooking data")
+
+ Here are some notes about this example:
+
+ * The main thing this file does is define a system 'foo'. It also
+ contains other Lisp forms, which we'll examine below.
+
+ * Besides Lisp source files, this system contains a ':module'
+ component named '"mod"', which is a collection of three Lisp source
+ files 'utils.lisp', 'reader.lisp', 'cooker.lisp' and 'data.raw'
+
+ * Note that the ':static-file' does not have an implicit file type,
+ unlike the Lisp source files.
+
+ * This files will be located in a subdirectory of the main code
+ directory named 'mod/' (this location could have been overridden to
+ be in the same directory, or in a different subdirectory; see the
+ discussion of the ':pathname' option in *note The defsystem
+ grammar::).
+
+ * The ':serial t' says that each sub-component of 'mod' depends on
+ the previous components, so that 'cooker.lisp' depends-on
+ 'utils.lisp', which depends-on 'reader.lisp'. Also 'data.raw'
+ depends on all of them, but that doesn't matter since it's a static
+ file; on the other hand, if it appeared first, then all the Lisp
+ files would be recompiled when the data is modified, which is
+ probably not what is desired in this case.
+
+ * The method-form tokens provide a shorthand for defining methods on
+ particular components. This part
+
+ :output-files (compile-op (o c) (list "data.cooked"))
+ :perform (compile-op :after (o c)
+ (cook-data
+ :in (component-pathname (find-component c "data.raw"))
+ :out (first (output-files o c))))
+
+ has the effect of
+
+ (defmethod output-files ((o compile-op) (c (eql ...)))
+ (list "data.cooked"))
+ (defmethod perform :after ((o compile-op) (c (eql ...)))
+ (cook-data
+ :in (component-pathname (find-component c "data.raw"))
+ :out (first (output-files o c))))
+
+ where '...' is the component in question. In this case '...' would
+ expand to something like
+
+ (find-component "foo" "mod")
+
+ For more details on the syntax of such forms, *note The defsystem
+ grammar::. For more details on what these methods do, *note
+ Operations:: in *note The object model of ASDF::.
+
+ * There is an additional 'defmethod' with a similar effect, because
+ ASDF (as of ASDF 3.1.5) fails to accept inline-methods as above for
+ 'action-description', instead only supporting the deprecated
+ 'explain' interface.
+
+ * In this case, these methods describe how this module defines code
+ that it then uses to cook some data.
+
+ * Importantly, ASDF is told about the input and output files used by
+ the data cooker, and to make sure everyone agrees, the cooking
+ function explicitly uses ASDF to access pathnames to the input and
+ output data.
+
+ * The file starts with a form '(in-package :asdf-user)', but it is
+ actually redundant, not necessary and not recommended. But yet
+ more complex cases (also not recommended) may usefully use an
+ 'in-package' form.
+
+ * Indeed, ASDF does not load '.asd' files simply with 'cl:load', and
+ neither should you. You should let ASDF find and load them when
+ you operate on systems. If you somehow _must_ load a '.asd' file,
+ use the same function 'asdf:load-asd' that ASDF uses. Among other
+ things, it already binds the '*package*' to 'asdf-user'. Recent
+ versions of SLIME (2013-02 and later) know to do that when you 'C-c
+ C-k' when you use the 'slime-asdf' contrib.
+
+ * You shouldn't use an 'in-package' form if you're keeping things
+ simple. You should only use 'in-package' (and before it, a
+ 'defpackage') when you're going to define new classes, functions,
+ variables, macros, etc., in the '.asd' file, and want to thereby
+ avoid name clashes. Manuals for old versions of ASDF recommended
+ use of such an idiom in '.asd' files, but as of ASDF 3, we
+ recommend that you don't do that anymore, and instead define any
+ ASDF extensions in their own system, on which you can then declare
+ a dependency using ':defsystem-depends-on'. *Note The defsystem
+ grammar::.
+
+ * More generally, you can always rely on symbols from packages
+ 'asdf', 'common-lisp' and 'uiop' being available in '.asd' files --
+ most importantly including 'defsystem'. It is therefore redundant
+ and in bad taste to use a package-prefixed 'asdf:defsystem' symbol
+ in a '.asd' file. Just use '(defsystem ...)'. Only package-prefix
+ it when somehow dynamically generating system definitions from a
+ package that doesn't already use the ASDF package.
+
+ * 'asdf-user' is actually only available starting since ASDF 3, but
+ then again, ASDF 1 and 2 did crazy things with packages that ASDF 3
+ has stopped doing(1), and since all implementations provide ASDF 3,
+ you shouldn't care about compatibility with ASDF 2. We do not
+ support ASDF 2 anymore, and we recommend that neither should you.
+
+ * Starting with ASDF 3.1, 'asdf-user' uses 'uiop', whereas in earlier
+ variants of ASDF 3 it only used 'uiop/package'. We recommend you
+ either prefix use of UIOP functions with the package prefix
+ 'uiop:', or make sure your system ':depends-on ((:version "asdf"
+ "3.1.2"))' or has a '#-asdf3.1 (error "MY-SYSTEM requires ASDF
+ 3.1.2")'.
+
+ * Finally, we elided most metadata, but showed how you can have ASDF
+ automatically extract the system's version from a source file. In
+ this case, the 3rd subform of the 4th form (note that Lisp uses
+ 0-based indexing, English uses 1-based indexing). Presumably, the
+ 4th form looks like '(defparameter *foo-version* "5.6.7")'.
+
+ ---------- Footnotes ----------
+
+ (1) ASDF 1 and 2 (up until 2.26) used to dynamically create and
+delete temporary packages 'asdf_N_', one for each '.asd' file, in a
+misguided attempt to thereby reduce name clashes; but it failed at that
+goal and only made things more complex. ASDF 3 just uses a shared
+package 'asdf-user' instead, and relies on the usual Common Lisp
+conventions to avoid clashes. As far as package oddities go, you may
+just notice that the 'asdf-user' package also uses 'uiop/common-lisp', a
+variant of the 'common-lisp' package that papers over deficiencies in
+more obscure Common Lisp implementations; but unless you care about
+Corman Lisp, GCL, Genera or MCL, you shouldn't be concerned.
</span>
File: asdf.info, Node: The defsystem grammar, Next: Other code in .asd files, Prev: A more involved example, Up: Defining systems with defsystem
<span style="color: #000000;background-color: #ffdddd">-5.3 The defsystem grammar
</span><span style="color: #000000;background-color: #ddffdd">+6.3 The defsystem grammar
</span> =========================
system-definition := ( defsystem system-designator SYSTEM-OPTION* )
<span style="color: #aaaaaa">@@ -774,9 +1113,20 @@ File: asdf.info, Node: The defsystem grammar, Next: Other code in .asd files,
</span> system-option := :defsystem-depends-on system-list
| :weakly-depends-on SYSTEM-LIST
| :class class-name (see discussion below)
<span style="color: #000000;background-color: #ddffdd">+ | system-option
</span> | module-option
| option
<span style="color: #000000;background-color: #ddffdd">+ # These are only available since ASDF 3 (actually its alpha release 2.27)
+ system-option := :homepage string
+ | :bug-tracker string
+ | :mailto string
+ | :long-name string
+ | :source-control source-control
+ | :version version-specifier
+
+ source-control := (keyword string)
+
</span> module-option := :components component-list
| :serial [ t | nil ]
<span style="color: #aaaaaa">@@ -800,19 +1150,20 @@ File: asdf.info, Node: The defsystem grammar, Next: Other code in .asd files,
</span>
component-type := :module | :file | :static-file | other-component-type
<span style="color: #000000;background-color: #ffdddd">- other-component-type := symbol-by-name (*note Component types: The defsystem grammar.)
</span><span style="color: #000000;background-color: #ddffdd">+ other-component-type := symbol-by-name
+ (*note Component types: The defsystem grammar.)
</span>
# This is used in :depends-on, as opposed to ``dependency,''
# which is used in :in-order-to
dependency-def := simple-component-name
<span style="color: #000000;background-color: #ffdddd">- | (feature FEATURE-NAME)
- | ( :version simple-component-name version-specifier)
</span><span style="color: #000000;background-color: #ddffdd">+ | ( :feature FEATURE-EXPRESSION dependency-def )
+ | ( :version simple-component-name version-specifier )
+ | ( :require module-name )
</span>
# ``dependency'' is used in :in-order-to, as opposed to
# ``dependency-def''
dependency := (dependent-op REQUIREMENT+)
requirement := (required-op REQUIRED-COMPONENT+)
<span style="color: #000000;background-color: #ffdddd">- | (:feature FEATURE-NAME)
</span> dependent-op := operation-name
required-op := operation-name
<span style="color: #aaaaaa">@@ -826,65 +1177,66 @@ File: asdf.info, Node: The defsystem grammar, Next: Other code in .asd files,
</span>
component-dep-fail-option := :fail | :try-next | :ignore
<span style="color: #000000;background-color: #ffdddd">- feature-expression := keyword | (:and FEATURE-EXPRESSION*)
- | (:or FEATURE-EXPRESSION*) | (:not FEATURE-EXPRESSION)
</span><span style="color: #000000;background-color: #ddffdd">+ feature-expression := keyword
+ | (:and FEATURE-EXPRESSION*)
+ | (:or FEATURE-EXPRESSION*)
+ | (:not FEATURE-EXPRESSION)
</span>
<span style="color: #000000;background-color: #ffdddd">-5.3.1 Component names
</span><span style="color: #000000;background-color: #ddffdd">+6.3.1 Component names
</span> ---------------------
<span style="color: #000000;background-color: #ffdddd">-Component names (`simple-component-name') may be either strings or
</span><span style="color: #000000;background-color: #ddffdd">+Component names ('simple-component-name') may be either strings or
</span> symbols.
<span style="color: #000000;background-color: #ffdddd">-5.3.2 Component types
</span><span style="color: #000000;background-color: #ddffdd">+6.3.2 Component types
</span> ---------------------
Component type names, even if expressed as keywords, will be looked up
by name in the current package and in the asdf package, if not found in
<span style="color: #000000;background-color: #ffdddd">-the current package. So a component type `my-component-type', in the
-current package `my-system-asd' can be specified as
-`:my-component-type', or `my-component-type'.
</span><span style="color: #000000;background-color: #ddffdd">+the current package. So a component type 'my-component-type', in the
+current package 'my-system-asd' can be specified as
+':my-component-type', or 'my-component-type'.
</span>
<span style="color: #000000;background-color: #ffdddd">- `system' and its subclasses are _not_ allowed as component types for
</span><span style="color: #000000;background-color: #ddffdd">+ 'system' and its subclasses are _not_ allowed as component types for
</span> such children components.
<span style="color: #000000;background-color: #ffdddd">-5.3.3 System class names
</span><span style="color: #000000;background-color: #ddffdd">+6.3.3 System class names
</span> ------------------------
A system class name will be looked up in the same way as a Component
<span style="color: #000000;background-color: #ffdddd">-type (see above), except that only `system' and its subclasses are
</span><span style="color: #000000;background-color: #ddffdd">+type (see above), except that only 'system' and its subclasses are
</span> allowed. Typically, one will not need to specify a system class name,
<span style="color: #000000;background-color: #ffdddd">-unless using a non-standard system class defined in some ASDF
-extension, typically loaded through `DEFSYSTEM-DEPENDS-ON', see below.
-For such class names in the ASDF package, we recommend that the
-`:class' option be specified using a keyword symbol, such as
</span><span style="color: #000000;background-color: #ddffdd">+unless using a non-standard system class defined in some ASDF extension,
+typically loaded through 'DEFSYSTEM-DEPENDS-ON', see below. For such
+class names in the ASDF package, we recommend that the ':class' option
+be specified using a keyword symbol, such as
</span>
:class :MY-NEW-SYSTEM-SUBCLASS
This practice will ensure that package name conflicts are avoided.
<span style="color: #000000;background-color: #ffdddd">-Otherwise, the symbol `MY-NEW-SYSTEM-SUBCLASS' will be read into the
</span><span style="color: #000000;background-color: #ddffdd">+Otherwise, the symbol 'MY-NEW-SYSTEM-SUBCLASS' will be read into the
</span> current package _before_ it has been exported from the ASDF extension
<span style="color: #000000;background-color: #ffdddd">-loaded by `:defsystem-depends-on', causing a name conflict in the
</span><span style="color: #000000;background-color: #ddffdd">+loaded by ':defsystem-depends-on', causing a name conflict in the
</span> current package.
<span style="color: #000000;background-color: #ffdddd">-5.3.4 Defsystem depends on
</span><span style="color: #000000;background-color: #ddffdd">+6.3.4 Defsystem depends on
</span> --------------------------
<span style="color: #000000;background-color: #ffdddd">-The `:defsystem-depends-on' option to `defsystem' allows the programmer
</span><span style="color: #000000;background-color: #ddffdd">+The ':defsystem-depends-on' option to 'defsystem' allows the programmer
</span> to specify another ASDF-defined system or set of systems that must be
loaded _before_ the system definition is processed. Typically this is
used to load an ASDF extension that is used in the system definition.
<span style="color: #000000;background-color: #ffdddd">-5.3.5 Weakly depends on
</span><span style="color: #000000;background-color: #ddffdd">+6.3.5 Weakly depends on
</span> -----------------------
<span style="color: #000000;background-color: #ffdddd">-We do _NOT_ recommend you use this feature. If you are tempted to
-write a system FOO that weakly-depends-on a system BAR, we recommend
-that you should instead write system FOO in a parametric way, and offer
-some special variable and/or some hook to specialize its behavior; then
-you should write a system FOO+BAR that does the hooking of things
-together.
</span><span style="color: #000000;background-color: #ddffdd">+We do _NOT_ recommend you use this feature. If you are tempted to write
+a system FOO that weakly-depends-on a system BAR, we recommend that you
+should instead write system FOO in a parametric way, and offer some
+special variable and/or some hook to specialize its behaviour; then you
+should write a system FOO+BAR that does the hooking of things together.
</span>
<span style="color: #000000;background-color: #ffdddd">- The (deprecated) `:weakly-depends-on' option to `defsystem' allows
</span><span style="color: #000000;background-color: #ddffdd">+ The (deprecated) ':weakly-depends-on' option to 'defsystem' allows
</span> the programmer to specify another ASDF-defined system or set of systems
that ASDF should _try_ to load, but need not load in order to be
successful. Typically this is used if there are a number of systems
<span style="color: #aaaaaa">@@ -892,99 +1244,101 @@ that, if present, could provide additional functionality, but which are
</span> not necessary for basic function.
Currently, although it is specified to be an option only to
<span style="color: #000000;background-color: #ffdddd">-`defsystem', this option is accepted at any component, but it probably
-only makes sense at the `defsystem' level. Programmers are cautioned
-not to use this component option except at the `defsystem' level, as
-this anomalous behavior may be removed without warning.
-
- Finally, you might look into the `asdf-system-connections' extension,
-that will let you define additional code to be loaded when two systems
-are simultaneously loaded. It may or may not be considered good style,
-but at least it can be used in a way that has deterministic behavior
-independent of load order, unlike `weakly-depends-on'.
-
-5.3.6 Pathname specifiers
</span><span style="color: #000000;background-color: #ddffdd">+'defsystem', this option is accepted at any component, but it probably
+only makes sense at the 'defsystem' level. Programmers are cautioned
+not to use this component option except at the 'defsystem' level, as
+this anomalous behaviour may be removed without warning.
+
+6.3.6 Pathname specifiers
</span> -------------------------
<span style="color: #000000;background-color: #ffdddd">-A pathname specifier (`pathname-specifier') may be a pathname, a string
-or a symbol. When no pathname specifier is given for a component,
-which is the usual case, the component name itself is used.
</span><span style="color: #000000;background-color: #ddffdd">+A pathname specifier ('pathname-specifier') may be a pathname, a string
+or a symbol. When no pathname specifier is given for a component, which
+is the usual case, the component name itself is used.
</span>
If a string is given, which is the usual case, the string will be
<span style="color: #000000;background-color: #ffdddd">-interpreted as a Unix-style pathname where `/' characters will be
</span><span style="color: #000000;background-color: #ddffdd">+interpreted as a Unix-style pathname where '/' characters will be
</span> interpreted as directory separators. Usually, Unix-style relative
<span style="color: #000000;background-color: #ffdddd">-pathnames are used (i.e. not starting with `/', as opposed to absolute
</span><span style="color: #000000;background-color: #ddffdd">+pathnames are used (i.e. not starting with '/', as opposed to absolute
</span> pathnames); they are relative to the path of the parent component.
<span style="color: #000000;background-color: #ffdddd">-Finally, depending on the `component-type', the pathname may be
</span><span style="color: #000000;background-color: #ddffdd">+Finally, depending on the 'component-type', the pathname may be
</span> interpreted as either a file or a directory, and if it's a file, a file
<span style="color: #000000;background-color: #ffdddd">-type may be added corresponding to the `component-type', or else it
-will be extracted from the string itself (if applicable).
-
- For instance, the `component-type' `:module' wants a directory
-pathname, and so a string `"foo/bar"' will be interpreted as the
-pathname `#p"foo/bar/"'. On the other hand, the `component-type'
-`:file' wants a file of type `lisp', and so a string `"foo/bar"' will
-be interpreted as the pathname `#p"foo/bar.lisp"', and a string
-`"foo/bar.quux"' will be interpreted as the pathname
-`#p"foo/bar.quux.lisp"'. Finally, the `component-type' `:static-file'
-wants a file without specifying a type, and so a string `"foo/bar"'
-will be interpreted as the pathname `#p"foo/bar"', and a string
-`"foo/bar.quux"' will be interpreted as the pathname `#p"foo/bar.quux"'.
-
- ASDF does not interpret the string `".."' to designate the parent
-directory. This string will be passed through to the underlying
-operating system for interpretation. We _believe_ that this will work
-on all platforms where ASDF is deployed, but do not guarantee this
-behavior. A pathname object with a relative directory component of
-`:up' or `:back' is the only guaranteed way to specify a parent
-directory.
</span><span style="color: #000000;background-color: #ddffdd">+type may be added corresponding to the 'component-type', or else it will
+be extracted from the string itself (if applicable).
+
+ For instance, the 'component-type' ':module' wants a directory
+pathname, and so a string '"foo/bar"' will be interpreted as the
+pathname '#p"foo/bar/"'. On the other hand, the 'component-type'
+':file' wants a file of type 'lisp', and so a string '"foo/bar"' will be
+interpreted as the pathname '#p"foo/bar.lisp"', and a string
+'"foo/bar.quux"' will be interpreted as the pathname
+'#p"foo/bar.quux.lisp"'. Finally, the 'component-type' ':static-file'
+wants a file without specifying a type, and so a string '"foo/bar"' will
+be interpreted as the pathname '#p"foo/bar"', and a string
+'"foo/bar.quux"' will be interpreted as the pathname '#p"foo/bar.quux"'.
+
+ ASDF interprets the string '".."' as the pathname directory component
+word ':back', which when merged, goes back one level in the directory
+hierarchy.
</span>
If a symbol is given, it will be translated into a string, and
downcased in the process. The downcasing of symbols is unconventional,
but was selected after some consideration. Observations suggest that
the type of systems we want to support either have lowercase as
customary case (Unix, Mac, windows) or silently convert lowercase to
<span style="color: #000000;background-color: #ffdddd">-uppercase (lpns), so this makes more sense than attempting to use
-`:case :common' as argument to `make-pathname', which is reported not
-to work on some implementations.
</span><span style="color: #000000;background-color: #ddffdd">+uppercase (lpns), so this makes more sense than attempting to use ':case
+:common' as argument to 'make-pathname', which is reported not to work
+on some implementations.
</span>
Pathname objects may be given to override the path for a component.
<span style="color: #000000;background-color: #ffdddd">-Such objects are typically specified using reader macros such as `#p'
-or `#.(make-pathname ...)'. Note however, that `#p...' is a shorthand
-for `#.(parse-namestring ...)' and that the behavior of
-`parse-namestring' is completely non-portable, unless you are using
-Common Lisp `logical-pathname's, which themselves involve other
-non-portable behavior (*note Using logical pathnames: The defsystem
-grammar, below). Pathnames made with `#.(make-pathname ...)' can
-usually be done more easily with the string syntax above. The only
-case that you really need a pathname object is to override the
-component-type default file type for a given component. Therefore,
-pathname objects should only rarely be used. Unhappily, ASDF 1 didn't
-properly support parsing component names as strings specifying paths
-with directories, and the cumbersome `#.(make-pathname ...)' syntax had
-to be used. An alternative to `#.' read-time evaluation is to use
-`(eval `(defsystem ... ,pathname ...))'.
</span><span style="color: #000000;background-color: #ddffdd">+Such objects are typically specified using reader macros such as '#p' or
+'#.(make-pathname ...)'. Note however, that '#p...' is a shorthand for
+'#.(parse-namestring ...)' and that the behaviour of 'parse-namestring'
+is completely non-portable, unless you are using Common Lisp
+'logical-pathname's, which themselves involve other non-portable
+behaviour (*note Using logical pathnames: The defsystem grammar, below).
+Pathnames made with '#.(make-pathname ...)' can usually be done more
+easily with the string syntax above. The only case that you really need
+a pathname object is to override the component-type default file type
+for a given component. Therefore, pathname objects should only rarely
+be used. Unhappily, ASDF 1 used not to properly support parsing
+component names as strings specifying paths with directories, and the
+cumbersome '#.(make-pathname ...)' syntax had to be used. An
+alternative to '#.' read-time evaluation is to use '(eval `(defsystem
+... ,pathname ...))'.
</span>
Note that when specifying pathname objects, ASDF does not do any
<span style="color: #000000;background-color: #ffdddd">-special interpretation of the pathname influenced by the component
-type, unlike the procedure for pathname-specifying strings. On the one
-hand, you have to be careful to provide a pathname that correctly
-fulfills whatever constraints are required from that component type
-(e.g. naming a directory or a file with appropriate type); on the other
-hand, you can circumvent the file type that would otherwise be forced
-upon you if you were specifying a string.
-
-5.3.7 Version specifiers
</span><span style="color: #000000;background-color: #ddffdd">+special interpretation of the pathname influenced by the component type,
+unlike the procedure for pathname-specifying strings. On the one hand,
+you have to be careful to provide a pathname that correctly fulfills
+whatever constraints are required from that component type (e.g. naming
+a directory or a file with appropriate type); on the other hand, you can
+circumvent the file type that would otherwise be forced upon you if you
+were specifying a string.
+
+6.3.7 Version specifiers
</span> ------------------------
<span style="color: #000000;background-color: #ffdddd">-Version specifiers are strings to be parsed as period-separated lists
-of integers. I.e., in the example, `"0.2.1"' is to be interpreted,
-roughly speaking, as `(0 2 1)'. In particular, version `"0.2.1"' is
-interpreted the same as `"0.0002.1"', though the latter is not
-canonical and may lead to a warning being issued. Also, `"1.3"' and
-`"1.4"' are both strictly `uiop:version<' to `"1.30"', quite unlike
-what would have happened had the version strings been interpreted as
-decimal fractions.
</span><span style="color: #000000;background-color: #ddffdd">+Version specifiers are strings to be parsed as period-separated lists of
+integers. I.e., in the example, '"0.2.1"' is to be interpreted, roughly
+speaking, as '(0 2 1)'. In particular, version '"0.2.1"' is interpreted
+the same as '"0.0002.1"', though the latter is not canonical and may
+lead to a warning being issued. Also, '"1.3"' and '"1.4"' are both
+strictly 'uiop:version<' to '"1.30"', quite unlike what would have
+happened had the version strings been interpreted as decimal fractions.
+
+ Instead of a string representing the version, the ':version' argument
+can be an expression that is resolved to such a string using the
+following trivial domain-specific language: in addition to being a
+literal string, it can be an expression of the form '(:read-file-form
+<pathname-or-string> :at <access-at-specifier>)', which will be resolved
+by reading a form in the specified pathname (read as a subpathname of
+the current system if relative or a unix-namestring). You may use a
+'uiop:access-at' specifier with the (optional) ':at' keyword, by default
+the specifier is '0', meaning the first form is returned; subforms can
+also be specified, with e.g. '(1 2 2)' specifying "the third subform
+(index 2) of the third subform (index 2) of the second form (index 1)"
+in the file (mind the off-by-one error in the English language).
</span>
System definers are encouraged to use version identifiers of the form
X.Y.Z for major version, minor version and patch level, where
<span style="color: #aaaaaa">@@ -993,7 +1347,17 @@ number.
</span>
*Note Common attributes of components::.
<span style="color: #000000;background-color: #ffdddd">-5.3.8 Using logical pathnames
</span><span style="color: #000000;background-color: #ddffdd">+6.3.8 Require
+-------------
+
+Use the implementation's own 'require' to load the MODULE-NAME.
+
+ It is good taste to use ':if-feature _:implementation-name_' rather
+than '#+_implementation-name_' to only depend on the specified module on
+the specific implementation that provides it. *Note
+if-feature-option::.
+
+6.3.9 Using logical pathnames
</span> -----------------------------
We do not generally recommend the use of logical pathnames, especially
<span style="color: #aaaaaa">@@ -1001,17 +1365,17 @@ not so to newcomers to Common Lisp. However, we do support the use of
</span> logical pathnames by old timers, when such is their preference.
To use logical pathnames, you will have to provide a pathname object
<span style="color: #000000;background-color: #ffdddd">-as a `:pathname' specifier to components that use it, using such syntax
-as `#p"LOGICAL-HOST:absolute;path;to;component.lisp"'.
</span><span style="color: #000000;background-color: #ddffdd">+as a ':pathname' specifier to components that use it, using such syntax
+as '#p"LOGICAL-HOST:absolute;path;to;component.lisp"'.
</span>
You only have to specify such logical pathname for your system or
<span style="color: #000000;background-color: #ffdddd">-some top-level component. Sub-components' relative pathnames,
-specified using the string syntax for names, will be properly merged
-with the pathnames of their parents. The specification of a logical
-pathname host however is _not_ otherwise directly supported in the ASDF
-syntax for pathname specifiers as strings.
</span><span style="color: #000000;background-color: #ddffdd">+some top-level component. Sub-components' relative pathnames, specified
+using the string syntax for names, will be properly merged with the
+pathnames of their parents. The specification of a logical pathname
+host however is _not_ otherwise directly supported in the ASDF syntax
+for pathname specifiers as strings.
</span>
<span style="color: #000000;background-color: #ffdddd">- The `asdf-output-translation' layer will avoid trying to resolve and
</span><span style="color: #000000;background-color: #ddffdd">+ The 'asdf-output-translation' layer will avoid trying to resolve and
</span> translate logical pathnames. The advantage of this is that you can
define yourself what translations you want to use with the logical
pathname facility. The disadvantage is that if you do not define such
<span style="color: #aaaaaa">@@ -1023,7 +1387,7 @@ translations yourself before they may be used. ASDF currently provides
</span> no specific support for defining logical pathname translations.
Note that the reasons we do not recommend logical pathnames are that
<span style="color: #000000;background-color: #ffdddd">-(1) there is no portable way to set up logical pathnames before they
</span><span style="color: #000000;background-color: #ddffdd">+(1) there is no portable way to set up logical pathnames _before_ they
</span> are used, (2) logical pathnames are limited to only portably use a
single character case, digits and hyphens. While you can solve the
first issue on your own, describing how to do it on each of fifteen
<span style="color: #aaaaaa">@@ -1039,12 +1403,12 @@ are shared with software written in different programming languages
</span> where conventions include the use of underscores, dots or CamelCase in
pathnames.
<span style="color: #000000;background-color: #ffdddd">-5.3.9 Serial dependencies
--------------------------
</span><span style="color: #000000;background-color: #ddffdd">+6.3.10 Serial dependencies
+--------------------------
</span>
<span style="color: #000000;background-color: #ffdddd">-If the `:serial t' option is specified for a module, ASDF will add
</span><span style="color: #000000;background-color: #ddffdd">+If the ':serial t' option is specified for a module, ASDF will add
</span> dependencies for each child component, on all the children textually
<span style="color: #000000;background-color: #ffdddd">-preceding it. This is done as if by `:depends-on'.
</span><span style="color: #000000;background-color: #ddffdd">+preceding it. This is done as if by ':depends-on'.
</span>
:serial t
:components ((:file "a") (:file "b") (:file "c"))
<span style="color: #aaaaaa">@@ -1055,608 +1419,810 @@ preceding it. This is done as if by `:depends-on'.
</span> (:file "b" :depends-on ("a"))
(:file "c" :depends-on ("a" "b")))
<span style="color: #000000;background-color: #ffdddd">-5.3.10 Source location
-----------------------
</span><span style="color: #000000;background-color: #ddffdd">+6.3.11 Source location (':pathname')
+------------------------------------
</span>
<span style="color: #000000;background-color: #ffdddd">-The `:pathname' option is optional in all cases for systems defined via
-`defsystem', and in the usual case the user is recommended not to
-supply it.
</span><span style="color: #000000;background-color: #ddffdd">+The ':pathname' option is optional in all cases for systems defined via
+'defsystem', and generally is unnecessary. In the simple case, source
+files will be found in the same directory as the system or, in the case
+of modules, in a subdirectory with the same name as the module.
</span>
<span style="color: #000000;background-color: #ffdddd">- Instead, ASDF follows a hairy set of rules that are designed so that
- 1. `find-system' will load a system from disk and have its pathname
</span><span style="color: #000000;background-color: #ddffdd">+ More specifically, ASDF follows a hairy set of rules that are
+designed so that
+ 1. 'find-system' will load a system from disk and have its pathname
</span> default to the right place.
2. This pathname information will not be overwritten with
<span style="color: #000000;background-color: #ffdddd">- `*default-pathname-defaults*' (which could be somewhere else
- altogether) if the user loads up the `.asd' file into his editor
</span><span style="color: #000000;background-color: #ddffdd">+ '*default-pathname-defaults*' (which could be somewhere else
+ altogether) if the user loads up the '.asd' file into his editor
</span> and interactively re-evaluates that form.
If a system is being loaded for the first time, its top-level
pathname will be set to:
<span style="color: #000000;background-color: #ffdddd">- * The host/device/directory parts of `*load-truename*', if it is
</span><span style="color: #000000;background-color: #ddffdd">+ * The host/device/directory parts of '*load-truename*', if it is
</span> bound.
<span style="color: #000000;background-color: #ffdddd">-
- * `*default-pathname-defaults*', otherwise.
</span><span style="color: #000000;background-color: #ddffdd">+ * '*default-pathname-defaults*', otherwise.
</span>
If a system is being redefined, the top-level pathname will be
<span style="color: #000000;background-color: #ffdddd">- * changed, if explicitly supplied or obtained from `*load-truename*'
</span><span style="color: #000000;background-color: #ddffdd">+ * changed, if explicitly supplied or obtained from '*load-truename*'
</span> (so that an updated source location is reflected in the system
definition)
* changed if it had previously been set from
<span style="color: #000000;background-color: #ffdddd">- `*default-pathname-defaults*'
</span><span style="color: #000000;background-color: #ddffdd">+ '*default-pathname-defaults*'
</span>
* left as before, if it had previously been set from
<span style="color: #000000;background-color: #ffdddd">- `*load-truename*' and `*load-truename*' is currently unbound (so
- that a developer can evaluate a `defsystem' form from within an
</span><span style="color: #000000;background-color: #ddffdd">+ '*load-truename*' and '*load-truename*' is currently unbound (so
+ that a developer can evaluate a 'defsystem' form from within an
</span> editor without clobbering its source location)
<span style="color: #000000;background-color: #ffdddd">-5.3.11 if-feature option
</span><span style="color: #000000;background-color: #ddffdd">+6.3.12 if-feature option
</span> ------------------------
This option allows you to specify a feature expression to be evaluated
<span style="color: #000000;background-color: #ffdddd">-as if by `#+' to conditionally include a component in your build. If
</span><span style="color: #000000;background-color: #ddffdd">+as if by '#+' to conditionally include a component in your build. If
</span> the expression is false, the component is dropped as well as any
<span style="color: #000000;background-color: #ffdddd">-dependency pointing to it. As compared to using `#+' which is expanded
</span><span style="color: #000000;background-color: #ddffdd">+dependency pointing to it. As compared to using '#+' which is expanded
</span> at read-time, this allows you to have an object in your component
hierarchy that can be used for manipulations beside building your
<span style="color: #000000;background-color: #ffdddd">-project. This option was added in ASDF 3.
</span><span style="color: #000000;background-color: #ddffdd">+project, and that is accessible to outside code that wishes to reason
+about system structure.
</span>
<span style="color: #000000;background-color: #ffdddd">-5.3.12 if-component-dep-fails option
</span><span style="color: #000000;background-color: #ddffdd">+ Programmers should be careful to consider *when* the ':if-feature' is
+evaluated. Recall that ASDF first computes a build plan, and then
+executes that plan. ASDF will check to see whether or not a feature is
+present *at planning time*, not during the build. It follows that one
+cannot use ':if-feature' to check features that are set during the
+course of the build. It can only be used to check the state of features
+before any build operations have been performed.
+
+ This option was added in ASDF 3. For more information, *Note
+Required features: required-features.
+
+6.3.13 if-component-dep-fails option
</span> ------------------------------------
<span style="color: #000000;background-color: #ffdddd">-This option was removed in ASDF 3. Its semantics was limited in
-purpose and dubious to explain, and its implementation was breaking a
-hole into the ASDF object model. Please use the `if-feature' option
-instead.
</span><span style="color: #000000;background-color: #ddffdd">+This option was removed in ASDF 3. Its semantics was limited in purpose
+and dubious to explain, and its implementation was breaking a hole into
+the ASDF object model. Please use the 'if-feature' option instead.
+
+6.3.14 feature requirement
+--------------------------
+
+This requirement was removed in ASDF 3.1. Please do not use it. In
+most cases, ':if-feature' (*note if-feature-option::) will provide an
+adequate substitute.
+
+ The 'feature' requirement used to ensure that a chain of component
+dependencies would fail when a key feature was absent. Used in
+conjunction with ':if-component-dep-fails' this provided a roundabout
+way to express conditional compilation.
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: Other code in .asd files, Prev: The defsystem grammar, Up: Defining systems with defsystem
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: Other code in .asd files, Next: The package-inferred-system extension, Prev: The defsystem grammar, Up: Defining systems with defsystem
</span>
<span style="color: #000000;background-color: #ffdddd">-5.4 Other code in .asd files
</span><span style="color: #000000;background-color: #ddffdd">+6.4 Other code in .asd files
</span> ============================
<span style="color: #000000;background-color: #ffdddd">-Files containing `defsystem' forms are regular Lisp files that are
-executed by `load'. Consequently, you can put whatever Lisp code you
-like into these files. However, it is recommended to keep such forms
-to a minimal, and to instead define `defsystem' extensions that you use
-with `:defsystem-depends-on'.
</span><span style="color: #000000;background-color: #ddffdd">+Files containing 'defsystem' forms are regular Lisp files that are
+executed by 'load'. Consequently, you can put whatever Lisp code you
+like into these files. However, it is recommended to keep such forms to
+a minimal, and to instead define 'defsystem' extensions that you use
+with ':defsystem-depends-on'.
</span>
<span style="color: #000000;background-color: #ffdddd">- If however, you might insist on including code in the `.asd' file
</span><span style="color: #000000;background-color: #ddffdd">+ If however, you might insist on including code in the '.asd' file
</span> itself, e.g., to examine and adjust the compile-time environment,
<span style="color: #000000;background-color: #ffdddd">-possibly adding appropriate features to `*features*'. If so, here are
</span><span style="color: #000000;background-color: #ddffdd">+possibly adding appropriate features to '*features*'. If so, here are
</span> some conventions we recommend you follow, so that users can control
<span style="color: #000000;background-color: #ffdddd">-certain details of execution of the Lisp in `.asd' files:
</span><span style="color: #000000;background-color: #ddffdd">+certain details of execution of the Lisp in '.asd' files:
</span>
* Any informative output (other than warnings and errors, which are
the condition system's to dispose of) should be sent to the
<span style="color: #000000;background-color: #ffdddd">- standard CL stream `*standard-output*', so that users can easily
</span><span style="color: #000000;background-color: #ddffdd">+ standard CL stream '*standard-output*', so that users can easily
</span> control the disposition of output from ASDF operations.
<span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: The package-inferred-system extension, Prev: Other code in .asd files, Up: Defining systems with defsystem
+
+6.5 The package-inferred-system extension
+=========================================
+
+Starting with release 3.1.2, ASDF supports a one-package-per-file style
+of programming, whereby each file is its own system, and dependencies
+are deduced from the 'defpackage' form (or its variant
+'uiop:define-package').
+
+ In this style, packages refer to a system with the same name
+(downcased); and if a system is defined with ':class
+package-inferred-system', then system names that start with that name
+(using the slash '/' separator) refer to files under the filesystem
+hierarchy where the system is defined. For instance, if system 'my-lib'
+is defined in '/foo/bar/my-lib/my-lib.asd', then system
+'my-lib/src/utility' will be found in file
+'/foo/bar/my-lib/src/utility.lisp'.
+
+ This style was made popular by 'faslpath' and 'quick-build' before,
+and at the cost of a stricter package discipline, seems to make for more
+maintainable code. It is used by ASDF itself (starting with ASDF 3), by
+'lisp-interface-library', and a few other libraries.
+
+ To use this style, choose a toplevel system name, e.g. 'my-lib', and
+create a file 'my-lib.asd' with the ':class :package-inferred-system'
+option in its 'defsystem'. For instance:
+ #-asdf3.1 (error "my-lib requires ASDF 3.1")
+ (defsystem "my-lib"
+ :class :package-inferred-system
+ :depends-on ("my-lib/interface/all"
+ "my-lib/src/all"
+ "my-lib/extras/all")
+ :in-order-to ((test-op (load-op "my-lib/test/all")))
+ :perform (test-op (o c) (symbol-call :my-lib/test/all :test-suite)))
+
+ (defsystem "my-lib/test" :depends-on ("my-lib/test/all"))
+
+ (register-system-packages "my-lib/interface/all" '(:my-lib-interface))
+ (register-system-packages "my-lib/src/all" '(:my-lib-implementation))
+ (register-system-packages "my-lib/test/all" '(:my-lib-test))
+
+ (register-system-packages
+ "closer-mop"
+ '(:c2mop :closer-common-lisp :c2cl :closer-common-lisp-user :c2cl-user))
+
+ In the code above, the first line checks that we are using ASDF 3.1,
+which provides 'package-inferred-system'.
+
+ The function 'register-system-packages' has to be called to register
+packages used or provided by your system and its components where the
+name of the system that provides the package is not the downcase of the
+package name.
+
+ Then, file 'interface/order.lisp' under the 'lil' hierarchy, that
+defines abstract interfaces for order comparisons, starts with the
+following form, dependencies being trivially computed from the ':use'
+and ':mix' clauses:
+
+ (uiop:define-package :lil/interface/order
+ (:use :closer-common-lisp
+ :lil/interface/definition
+ :lil/interface/base
+ :lil/interface/eq :lil/interface/group)
+ (:mix :fare-utils :uiop :alexandria)
+ (:export ...))
+
+ ASDF can tell that this file depends on system 'closer-mop'
+(registered above), 'lil/interface/definition', 'lil/interface/base',
+'lil/interface/eq', and 'lil/interface/group' (package and system names
+match, and they will be looked up hierarchically).
+
+ ASDF also detects dependencies from ':import-from' clauses. You may
+thus import a well-defined set of symbols from an existing package as
+loaded from suitably named system; or if you prefer to use any such
+symbol fully qualified by a package prefix, you may declare a dependency
+on such a package and its corresponding system via an ':import-from'
+clause with an empty list of symbols, as in:
+
+ (defpackage :foo/bar
+ (:use :cl)
+ (:import-from :foo/baz #:sym1 #:sym2)
+ (:import-from :foo/quux)
+ (:export ...))
+
+ The form 'uiop:define-package' is supported as well as 'defpackage',
+and has many options that prove useful in this context, such as
+':use-reexport' and ':mix-reexport' that allow for "inheritance" of
+symbols being exported.
+
+ Note that starting with ASDF 3.1.5.6 only, ASDF will look for source
+files under the 'component-pathname' as specified via the ':pathname'
+option, whereas earlier versions ignore this option and use the
+'system-source-directory' where the '.asd' file resides.
+
+
</span> File: asdf.info, Node: The object model of ASDF, Next: Controlling where ASDF searches for systems, Prev: Defining systems with defsystem, Up: Top
<span style="color: #000000;background-color: #ffdddd">-6 The object model of ASDF
</span><span style="color: #000000;background-color: #ddffdd">+7 The Object model of ASDF
</span> **************************
ASDF is designed in an object-oriented way from the ground up. Both a
system's structure and the operations that can be performed on systems
<span style="color: #000000;background-color: #ffdddd">-follow a extensible protocol.
-
- This allows the addition of behaviours: for example, `cffi' adds
-support of special FFI description files to interface with C libraries
-and of wrapper files to embed C code in Lisp; `abcl-jar' supports
-creating Java JAR archives in ABCL; and `poiu' supports for compiling
-code in parallel using background processes.
-
- This chapter deals with `component's and `operation's.
-
- A `component' represents an individual source file or a group of
-source files, and the things that get transformed into. A `system' is
-a component at the top level of the component hierarchy. A
-`source-file' is a component representing a single source-file and the
-successive output files into which it is transformed. A `module' is an
-intermediate component itself grouping several other components,
-themselves source-files or further modules.
-
- An `Operation' represents a transformation that can be performed on
-a component, turning them from source files to intermediate results to
-final outputs.
-
- A pair of an `operation' and a `component' is called an `action'.
-An `action' represents a particular build step to be `perform'ed, after
-all its dependencies have been fulfilled. In the ASDF model, actions
-depend on other actions. The term _action_ itself was used by Kent
-Pitman in his old article, but was only used by ASDF hackers starting
-with the ASDF 2; but the concept is ubiquitous since the very beginning
-of ASDF 1, though previously implicit.
-
- Then, there are many _functions_ available to users, extenders and
-implementers of ASDF to use, define or implement the activities that
-are part of building your software. Though they manipulate `action's,
-most of these functions do not take as an argument a reified pair (a
-`cons' cell) of an operation and a component; instead, they usually
-take two separate arguments, which allows to take advantage of the
-power CLOS-style multiple dispatch for fun and profit.
-
- There are many _hooks_ in which to add functionality, by customizing
-the behavior of existing _functions_.
-
- Last but not least is the notion of _dependency_ between two actions.
-The structure of dependencies between actions is a directed _dependency
-graph_. ASDF is invoked by being told to _operate_ with some
-_operation_ on some toplevel _system_; it will then _traverse_ the
-graph and build a _plan_ that follows its structure. To be
-successfully buildable, this graph of actions but be acyclic. If, as a
-user, extender or implementer of ASDF, you fail to keep the dependency
-graph without cycles, ASDF will fail loudly as it eventually finds one.
-To clearly distinguish the direction of dependencies, ASDF 3 uses the
-words _requiring_ and _required_ as applied to an action depending on
-the other: the requiring action `depends-on' the completion of all
-required actions before it may itself be `perform'ed.
-
- Using the `defsystem' syntax, users may easily express direct
-dependencies along the graph of the object hierarchy: between a
-component and its parent, its children, and its siblings. By defining
-custom CLOS methods, you can express more elaborate dependencies as you
-wish. Most common operations, such as `load-op', `compile-op' or
-`load-source-op' are automatically propagate "downward" the component
-hierarchy and are "covariant" with it: to act the operation on the
-parent module, you must first act it on all the children components,
-with the action on the parent being parent of the action on each child.
-Other operations, such as `prepare-op' and `prepare-source-op'
-(introduced in ASDF 3) are automatically propagated "upward" the
-component hierarchy and are "contravariant" with it: to perform the
-operation of preparing for compilation of a child component, you must
-perform the operation of preparing for compilation of its parent
-component, and so on, ensuring that all the parent's dependencies are
-(compiled and) loaded before the child component may be compiled and
-loaded. Yet other operations, such as `test-op' or `load-fasl-op'
-remain at the system level, and are not propagated along the hierarchy,
-but instead do something global on the system.
</span><span style="color: #000000;background-color: #ddffdd">+follow a extensible protocol, allowing programmers to add new behaviours
+to ASDF. For example, 'cffi' adds support for special FFI description
+files that interface with C libraries and for wrapper files that embed C
+code in Lisp. 'abcl-jar' supports creating Java JAR archives in ABCL.
+'poiu' supports compiling code in parallel using background processes.
+
+ The key classes in ASDF are 'component' and 'operation'. A
+'component' represents an individual source file or a group of source
+files, and the products (e.g., fasl files) produced from it. An
+'operation' represents a transformation that can be performed on a
+component, turning them from source files to intermediate results to
+final outputs. Components are related by _dependencies_, specified in
+system definitions.
+
+ When ordered to 'operate' with some operation on a component (usually
+a system), ASDF will first compute a _plan_ by traversing the dependency
+graph using function 'make-plan'.(1) The resulting plan object contains
+an ordered list of _actions_. An action is a pair of an 'operation' and
+a 'component', representing a particular build step to be 'perform'ed.
+The ordering of the plan ensures that no action is performed before all
+its dependencies have been fulfilled.(2)
+
+ In this chapter, we describe ASDF's object-oriented protocol, the
+classes that make it up, and the generic functions on those classes.
+These generic functions often take both an operation and a component as
+arguments: much of the power and configurability of ASDF is provided by
+this use of CLOS's multiple dispatch. We will describe the built-in
+component and operation classes, and explain how to extend the ASDF
+protocol by defining new classes and methods for ASDF's generic
+functions. We will also describe the many _hooks_ that can be
+configured to customize the behaviour of existing _functions_.
</span>
* Menu:
* Operations::
* Components::
<span style="color: #000000;background-color: #ddffdd">+* Dependencies::
</span> * Functions::
<span style="color: #000000;background-color: #ddffdd">+ ---------- Footnotes ----------
+
+ (1) Historically, the function that built a plan was called
+'traverse', and returned a list of actions; it was deprecated in favor
+of 'make-plan' (that returns a plan object) when the 'plan' objects were
+introduced with ASDF 3; the old function is kept for backward
+compatibility and debugging purposes only, and may be removed in the
+near future.
+
+ (2) The term _action_ was used by Kent Pitman in his article, "The
+Description of Large Systems," (*note Bibliography::), and we suspect
+might be traced to 'make'. Although the term was only used by ASDF
+hackers starting with ASDF 2, the concept was there since the very
+beginning of ASDF 1, just not clearly articulated.
+
</span>
File: asdf.info, Node: Operations, Next: Components, Prev: The object model of ASDF, Up: The object model of ASDF
<span style="color: #000000;background-color: #ffdddd">-6.1 Operations
</span><span style="color: #000000;background-color: #ddffdd">+7.1 Operations
</span> ==============
An "operation" object of the appropriate type is instantiated whenever
the user wants to do something with a system like
* compile all its files
<span style="color: #000000;background-color: #ffdddd">-
</span> * load the files into a running lisp environment
<span style="color: #000000;background-color: #ffdddd">-
</span> * copy its source files somewhere else
Operations can be invoked directly, or examined to see what their
effects would be without performing them. There are a bunch of methods
specialised on operation and component type that actually do the grunt
<span style="color: #000000;background-color: #ffdddd">-work.
</span><span style="color: #000000;background-color: #ddffdd">+work. Operations are invoked on systems via 'operate' (*note
+operate::).
+
+ ASDF contains a number of pre-defined operation classes for common,
+and even fairly uncommon tasks that you might want to do with it. In
+addition, ASDF contains "abstract" operation classes that programmers
+can use as building blocks to define ASDF extensions. We discuss these
+in turn below.
</span>
<span style="color: #000000;background-color: #ffdddd">- The operation object contains whatever state is relevant for this
-purpose (perhaps a list of visited nodes, for example) but primarily is
-a nice thing to specialise operation methods on and easier than having
-them all be `EQL' methods.
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
</span>
<span style="color: #000000;background-color: #ffdddd">- Operations are invoked on systems via `operate'.
</span><span style="color: #000000;background-color: #ddffdd">+* Predefined operations of ASDF::
+* Creating new operations::
</span>
<span style="color: #000000;background-color: #ffdddd">- -- Generic function: `operate' OPERATION SYSTEM &rest INITARGS &key
- `force' `force-not' `verbose' &allow-other-keys
- -- Generic function: `oos' OPERATION SYSTEM &rest INITARGS &key
</span><span style="color: #000000;background-color: #ddffdd">+ Operations are invoked on systems via 'operate'.
+ -- Generic function: 'operate' OPERATION COMPONENT &rest INITARGS &key
+ 'force' 'force-not' 'verbose' &allow-other-keys
+ -- Generic function: 'oos' OPERATION COMPONENT &rest INITARGS &key
</span> &allow-other-keys
<span style="color: #000000;background-color: #ffdddd">- `operate' invokes OPERATION on SYSTEM. `oos' is a synonym for
- `operate'.
</span><span style="color: #000000;background-color: #ddffdd">+ 'operate' invokes OPERATION on SYSTEM. 'oos' is a synonym for
+ 'operate' (it stands for operate-on-system).
</span>
OPERATION is a symbol that is passed, along with the supplied
<span style="color: #000000;background-color: #ffdddd">- INITARGS, to `make-instance' to create the operation object.
- SYSTEM is a system designator.
</span><span style="color: #000000;background-color: #ddffdd">+ INITARGS, to 'make-operation' (which will call 'make-instance') to
+ create the operation object. COMPONENT is a component designator,
+ usually a string or symbol that designates a system, sometimes a
+ list of strings or symbols that designate a subcomponent of a
+ system.
</span>
<span style="color: #000000;background-color: #ffdddd">- The INITARGS are passed to the `make-instance' call when creating
</span><span style="color: #000000;background-color: #ddffdd">+ The INITARGS are passed to the 'make-instance' call when creating
</span> the operation object. Note that dependencies may cause the
operation to invoke other operations on the system or its
components: the new operations will be created with the same
INITARGS as the original one.
<span style="color: #000000;background-color: #ffdddd">- If FORCE is `:all', then all systems are forced to be recompiled
- even if not modified since last compilation. If FORCE is `t',
- then only the system being loaded is forced to be recompiled even
- if not modified since last compilation, but other systems are not
</span><span style="color: #000000;background-color: #ddffdd">+ If FORCE is ':all', then all systems are forced to be recompiled
+ even if not modified since last compilation. If FORCE is 't', then
+ only the system being loaded is forced to be recompiled even if not
+ modified since last compilation, but other systems are not
</span> affected. If FORCE is a list, then it specifies a list of systems
that are forced to be recompiled even if not modified since last
<span style="color: #000000;background-color: #ffdddd">- compilation. If FORCE-NOT is `:all', then all systems are forced
</span><span style="color: #000000;background-color: #ddffdd">+ compilation. If FORCE-NOT is ':all', then all systems are forced
</span> not to be recompiled even if modified since last compilation. If
<span style="color: #000000;background-color: #ffdddd">- FORCE-NOT is `t', then only the system being loaded is forced not
- to be recompiled even if modified since last compilation, but
- other systems are not affected. If FORCE-NOT is a list, then it
- specifies a list of systems that are forced not to be recompiled
- even if modified since last compilation. FORCE takes precedences
- over FORCE-NOT; both of them apply to systems that are
- dependencies and were already compiled.
-
- To see what `operate' would do, you can use:
</span><span style="color: #000000;background-color: #ddffdd">+ FORCE-NOT is 't', then all systems but the system being loaded are
+ forced not to be recompiled even if modified since last compilation
+ (note: this was changed in ASDF 3.1.2). If FORCE-NOT is a list,
+ then it specifies a list of systems that are forced not to be
+ recompiled even if modified since last compilation.
+
+ Both FORCE and FORCE-NOT apply to systems that are dependencies and
+ were already compiled. FORCE-NOT takes precedences over FORCE, as
+ it should, really, but unhappily only since ASDF 3.1.2. Moreover,
+ systems which have been registered as immutable by
+ 'register-immutable-system' (since ASDF 3.1.5) are always
+ considered FORCED-NOT, and even their '.asd' are not refreshed from
+ the filesystem. *Note Miscellaneous Functions::.
+
+ To see what 'operate' would do, you can use:
</span> (asdf:traverse operation-class system-name)
<span style="color: #000000;background-color: #ffdddd">-
-* Menu:
-
-* Predefined operations of ASDF::
-* Creating new operations::
-
</span>
File: asdf.info, Node: Predefined operations of ASDF, Next: Creating new operations, Prev: Operations, Up: Operations
<span style="color: #000000;background-color: #ffdddd">-6.1.1 Predefined operations of ASDF
</span><span style="color: #000000;background-color: #ddffdd">+7.1.1 Predefined operations of ASDF
</span> -----------------------------------
<span style="color: #000000;background-color: #ffdddd">-All the operations described in this section are in the `asdf' package.
-They are invoked via the `operate' generic function.
</span><span style="color: #000000;background-color: #ddffdd">+All the operations described in this section are in the 'asdf' package.
+They are invoked via the 'operate' generic function.
</span>
(asdf:operate 'asdf:OPERATION-NAME :SYSTEM-NAME {OPERATION-OPTIONS ...})
<span style="color: #000000;background-color: #ffdddd">- -- Operation: `compile-op'
</span><span style="color: #000000;background-color: #ddffdd">+ -- Operation: 'compile-op'
+
</span> This operation compiles the specified component. A
<span style="color: #000000;background-color: #ffdddd">- `cl-source-file' will be `compile-file''d. All the children and
</span><span style="color: #000000;background-color: #ddffdd">+ 'cl-source-file' will be 'compile-file''d. All the children and
</span> dependencies of a system or module will be recursively compiled by
<span style="color: #000000;background-color: #ffdddd">- `compile-op'.
</span><span style="color: #000000;background-color: #ddffdd">+ 'compile-op'.
</span>
<span style="color: #000000;background-color: #ffdddd">- `compile-op' depends on `prepare-op' which itself depends on a
- `load-op' of all of a component's dependencies, as well as of its
- parent's dependencies. When `operate' is called on `compile-op',
</span><span style="color: #000000;background-color: #ddffdd">+ 'compile-op' depends on 'prepare-op' which itself depends on a
+ 'load-op' of all of a component's dependencies, as well as of its
+ parent's dependencies. When 'operate' is called on 'compile-op',
</span> all these dependencies will be loaded as well as compiled; yet,
some parts of the system main remain unloaded, because nothing
<span style="color: #000000;background-color: #ffdddd">- depends on them. Use `load-op' to load a system.
</span><span style="color: #000000;background-color: #ddffdd">+ depends on them. Use 'load-op' to load a system.
+
+ -- Operation: 'load-op'
</span>
<span style="color: #000000;background-color: #ffdddd">- -- Operation: `load-op'
</span> This operation loads the compiled code for a specified component.
<span style="color: #000000;background-color: #ffdddd">- A `cl-source-file' will have its compiled fasl `load'ed, which
- fasl is the output of `compile-op' that `load-op' depends on. All
- the children and dependencies of a system or module will be
- recursively loaded by `load-op'.
</span><span style="color: #000000;background-color: #ddffdd">+ A 'cl-source-file' will have its compiled fasl 'load'ed, which fasl
+ is the output of 'compile-op' that 'load-op' depends on.
+
+ 'load-op' will recursively load all the children of a system or
+ module.
</span>
<span style="color: #000000;background-color: #ffdddd">- `load-op' depends on `prepare-op' which itself depends on a
- `load-op' of all of a component's dependencies, as well as of its
</span><span style="color: #000000;background-color: #ddffdd">+ 'load-op' also depends on 'prepare-op' which itself depends on a
+ 'load-op' of all of a component's dependencies, as well as of its
</span> parent's dependencies.
<span style="color: #000000;background-color: #ffdddd">- -- Operation: `prepare-op'
- This operation ensures that the dependencies of a component and
- its recursive parents are loaded (as per `load-op'), as a
- prerequisite before `compile-op' and `load-op' operations may be
- performed on a given component.
-
- -- Operation: `load-source-op', `prepare-source-op'
- `load-source-op' will load the source for the files in a module
- rather than they compiled fasl output. It has a
- `prepare-source-op' analog to `prepare-op', that ensures the
- dependencies are themselves loaded via `load-source-op'.
-
- There is no provision in ASDF for ensuring that some components
- are always loaded as source, while others are always compiled.
- While this idea often comes up in discussions, it actually doesn't
- play well with either the linking model of ECL or with various
- bundle operations (see below), and is eventually not workable;
- also the dependency model of ASDF would have to be modified
- incompatibly to allow for such trick. If your code doesn't
- compile cleanly, fix it. If compilation makes it slow, use
- `declaim' or `eval-when' to adjust your compiler settings, or
- eschew compilation by `eval'uating a quoted source form at
- load-time.
-
- -- Operation: `test-op'
</span><span style="color: #000000;background-color: #ddffdd">+ -- Operation: 'prepare-op'
+
+ This operation ensures that the dependencies of a component and its
+ recursive parents are loaded (as per 'load-op'), as a prerequisite
+ before 'compile-op' and 'load-op' operations may be performed on a
+ given component.
+
+ -- Operation: 'load-source-op' , 'prepare-source-op'
+
+ 'load-source-op' will load the source for the files in a module
+ rather than the compiled fasl output. It has a 'prepare-source-op'
+ analog to 'prepare-op', that ensures the dependencies are
+ themselves loaded via 'load-source-op'.
+
+ -- Operation: 'test-op'
+
</span> This operation will perform some tests on the module. The default
method will do nothing. The default dependency is to require
<span style="color: #000000;background-color: #ffdddd">- `load-op' to be performed on the module first. The default
- `operation-done-p' is that the operation is _never_ done -- we
- assume that if you invoke the `test-op', you want to test the
- system, even if you have already done so.
-
- The results of this operation are not defined by ASDF. It has
- proven difficult to define how the test operation should signal
- its results to the user in a way that is compatible with all of
- the various test libraries and test techniques in use in the
- community.
-
- People typically define `test-op' methods like thus:
- (defmethod perform ((o asdf:test-op)
- (s (eql (asdf:find-system :MY-SYSTEM))))
- (asdf:load-system :MY-SYSTEM-TEST)
- (funcall (read-from-string "my-system-test:test-suite")))
-
- Using `load-system' in the perform method rather than an
- `:in-order-to' dependency, is sometimes necessary for backward
- compatibility with ASDF 2 and older, to avoid circular
- dependencies that could arise because of the way these old
- versions propagate dependencies.
-
- If you don't care for compatibility with ASDF 2, you could use the
- following options in your `defsystem' form:
- :in-order-to ((test-op (load-op :my-system-test)))
- :perform (test-op (o c) (symbol-call :my-system-test :test-suite))
-
- -- Operation: `fasl-op', `monolithic-fasl-op', `load-fasl-op',
- `binary-op', `monolithic-binary-op', `lib-op',
- `monolithic-lib-op', `dll-op', `monolithic-dll-op',
- `program-op'
</span><span style="color: #000000;background-color: #ddffdd">+ 'load-op' to be performed on the module first. Its
+ 'operation-done-p' method returns 'nil', which means that the
+ operation is _never_ done - we assume that if you invoke the
+ 'test-op', you want to test the system, even if you have already
+ done so.
+
+ The results of this operation are not defined by ASDF. It has
+ proven difficult to define how the test operation should signal its
+ results to the user in a way that is compatible with all of the
+ various test libraries and test techniques in use in the community,
+ and given the fact that ASDF operations do not return a value
+ indicating success or failure. For those willing to go to the
+ effort, we suggest defining conditions to signal when a 'test-op'
+ fails, and storing in those conditions information that describes
+ which tests fail.
+
+ People typically define a separate test _system_ to hold the tests.
+ Doing this avoids unnecessarily adding a test framework as a
+ dependency on a library. For example, one might have
+ (defsystem "foo"
+ :in-order-to ((test-op (test-op "foo/test")))
+ ...)
+
+ (defsystem "foo/test"
+ :depends-on ("foo" "fiveam") ; fiveam is a test framework library
+ ...)
+
+ Then one defines 'perform' methods on 'test-op' such as the
+ following:
+ (defsystem "foo/test"
+ :depends-on ("foo" "fiveam") ; fiveam is a test framework library
+ :perform (test-op (o s)
+ (uiop:symbol-call :fiveam '#:run!
+ (uiop:find-symbol* '#:foo-test-suite
+ :foo-tests)))
+ ...)
+
+ -- Operation: 'compile-bundle-op' , 'monolithic-compile-bundle-op',
+ 'load-bundle-op', 'monolithic-load-bundle-op',
+ 'deliver-asd-op', 'monolithic-deliver-asd-op', 'lib-op',
+ 'monolithic-lib-op', 'dll-op', 'monolithic-dll-op',
+ 'image-op', 'program-op'
+
</span> These are "bundle" operations, that can create a single-file
"bundle" for all the contents of each system in an application, or
for the entire application.
<span style="color: #000000;background-color: #ffdddd">- `fasl-op' will create a single fasl file for each of the systems
- needed, grouping all its many fasls in one, so you can deliver
- each system as a single fasl. `monolithic-fasl-op' will create a
- single fasl file for target system and all its dependencies, so
- you can deliver your entire application as a single fasl.
- `load-fasl-op' will load the output of `fasl-op' (though if it the
- output is not up-to-date, it will load the intermediate fasls
- indeed as part of building it); this matters a lot on ECL, where
</span><span style="color: #000000;background-color: #ddffdd">+ 'compile-bundle-op' will create a single fasl file for each of the
+ systems needed, grouping all its many fasls in one, so you can
+ deliver each system as a single fasl 'monolithic-compile-bundle-op'
+ will create a single fasl file for the target system and all its
+ dependencies, so you can deliver your entire application as a
+ single fasl. 'load-bundle-op' will load the output of
+ 'compile-bundle-op'. Note that if it the output is not up-to-date,
+ 'compile-bundle-op' may load the intermediate fasls as a
+ side-effect. Bundling fasls together matters a lot on ECL, where
</span> the dynamic linking involved in loading tens of individual fasls
can be noticeably more expensive than loading a single one.
<span style="color: #000000;background-color: #ffdddd">- Once you have created a fasl with `fasl-op', you can use
- `precompiled-system' to deliver it in a way that is compatible
- with clients having dependencies on your system, whether it is
- distributed as source or as a single binary; the `.asd' file to be
</span><span style="color: #000000;background-color: #ddffdd">+ NB: 'compile-bundle-op', 'monolithic-compile-bundle-op',
+ 'load-bundle-op', 'monolithic-load-bundle-op', 'deliver-asd-op',
+ 'monolithic-deliver-asd-op' were respectively called 'fasl-op',
+ 'monolithic-fasl-op', 'load-fasl-op', 'monolithic-load-fasl-op',
+ 'binary-op', 'monolithic-binary-op' before ASDF 3.1. The old names
+ still exist for backward compatibility, though they poorly label
+ what is going on.
+
+ Once you have created a fasl with 'compile-bundle-op', you can use
+ 'precompiled-system' to deliver it in a way that is compatible with
+ clients having dependencies on your system, whether it is
+ distributed as source or as a single binary; the '.asd' file to be
</span> delivered with the fasl will look like this:
(defsystem :mysystem :class :precompiled-system
<span style="color: #000000;background-color: #ffdddd">- :fasl (some expression that will evaluate to a pathname))
- Or you can use `binary-op' to let ASDF create such a system for you
- as well as the `fasl-op' output, or `monolithic-binary-op'. This
- allows you to deliver code for your systems or applications as a
- single file. Of course, if you want to test the result in the
- current image, _before_ you try to use any newly created `.asd'
- files, you should not forget to `(asdf:clear-configuration)' or at
- least `(asdf:clear-source-registry)', so it re-populates the
</span><span style="color: #000000;background-color: #ddffdd">+ :fasl (some expression that will evaluate to a pathname))
+ Or you can use 'deliver-asd-op' to let ASDF create such a system
+ for you as well as the 'compile-bundle-op' output, or
+ 'monolithic-deliver-asd-op'. This allows you to deliver code for
+ your systems or applications as a single file. Of course, if you
+ want to test the result in the current image, _before_ you try to
+ use any newly created '.asd' files, you should not forget to
+ '(asdf:clear-configuration)' or at least
+ '(asdf:clear-source-registry)', so it re-populates the
</span> source-registry from the filesystem.
<span style="color: #000000;background-color: #ffdddd">- The `program-op' operation will create an executable program from
</span><span style="color: #000000;background-color: #ddffdd">+ The 'program-op' operation will create an executable program from
</span> the specified system and its dependencies. You can use UIOP for
its pre-image-dump hooks, its post-image-restore hooks, and its
access to command-line arguments. And you can specify an entry
<span style="color: #000000;background-color: #ffdddd">- point `my-app:main' by specifying in your `defsystem' the option
- `:entry-point "my-app:main"'. Depending on your implementation,
- running `(asdf:operate 'asdf:program-op :my-app)' may quit the
</span><span style="color: #000000;background-color: #ddffdd">+ point 'my-app:main' by specifying in your 'defsystem' the option
+ ':entry-point "my-app:main"'. Depending on your implementation,
+ running '(asdf:operate 'asdf:program-op :my-app)' may quit the
</span> current Lisp image upon completion. See the example in
<span style="color: #000000;background-color: #ffdddd">- `test/hello-world-example.asd' and `test/hello.lisp', as built and
- tested by `test/test-program.script' and
- `test/make-hello-world.lisp'.
-
- There is also `lib-op' for building a linkable `.a' file (Windows:
- `.lib') from all linkable object dependencies (FFI files, and on
</span><span style="color: #000000;background-color: #ddffdd">+ 'test/hello-world-example.asd' and 'test/hello.lisp', as built and
+ tested by 'test/test-program.script' and
+ 'test/make-hello-world.lisp'. 'image-op' will dump an image that
+ may not be standalone and does not start its own function, but
+ follows the usual execution convention of the underlying Lisp, just
+ with more code pre-loaded, for use as an intermediate build result
+ or with a wrapper invocation script.
+
+ There is also 'lib-op' for building a linkable '.a' file (Windows:
+ '.lib') from all linkable object dependencies (FFI files, and on
</span> ECL, Lisp files too), and its monolithic equivalent
<span style="color: #000000;background-color: #ffdddd">- `monolithic-lib-op'. And there is also `dll-op' (respectively its
- monolithic equivalent `monolithic-lib-op') for building a linkable
- `.so' file (Windows: `.dll', MacOS X: `.dynlib') to create a
- single dynamic library for all the extra FFI code to be linked
- into each of your systems (respectively your entire application).
</span><span style="color: #000000;background-color: #ddffdd">+ 'monolithic-lib-op'. And there is also 'dll-op' (respectively its
+ monolithic equivalent 'monolithic-lib-op') for building a linkable
+ '.so' file (Windows: '.dll', MacOS X: '.dynlib') to create a single
+ dynamic library for all the extra FFI code to be linked into each
+ of your systems (respectively your entire application).
</span>
All these "bundle" operations are available since ASDF 3 on all
actively supported Lisp implementations, but may be unavailable on
unmaintained legacy implementations. This functionality was
previously available for select implementations, as part of a
<span style="color: #000000;background-color: #ffdddd">- separate system `asdf-bundle', itself descended from the ECL-only
- `asdf-ecl'.
</span><span style="color: #000000;background-color: #ddffdd">+ separate system 'asdf-bundle', itself descended from the ECL-only
+ 'asdf-ecl'.
</span>
The pathname of the output of bundle operations is subject to
output-translation as usual, unless the operation is equal to the
<span style="color: #000000;background-color: #ffdddd">- `:build-operation' argument to `defsystem'. This behavior is not
</span><span style="color: #000000;background-color: #ddffdd">+ ':build-operation' argument to 'defsystem'. This behaviour is not
</span> very satisfactory and may change in the future. Maybe you have
suggestions on how to better configure it?
<span style="color: #000000;background-color: #ffdddd">- -- Operation: `concatenate-source-op',
- `monolithic-concatenate-source-op',
- `load-concatenated-source-op',
- `compile-concatenated-source-op',
- `load-compiled-concatenated-source-op',
- `monolithic-load-concatenated-source-op',
- `monolithic-compile-concatenated-source-op',
- `monolithic-load-compiled-concatenated-source-op'
- These operation, as their respective names indicate, consist in
- concatenating all `cl-source-file' source files in a system (or in
- a system and all its dependencies, if monolithic), in the order
- defined by dependencies, then loading the result, or compiling
- then loading the result.
-
- These operations are useful to deliver a system or application as
- a single source file, and for testing that said file loads
- properly, or compiles then loads properly.
-
- ASDF itself is notably delivered as a single source file this way
- using `monolithic-concatenate-source-op', transcluding a prelude
- and the `uiop' library before the `asdf/defsystem' system itself.
</span><span style="color: #000000;background-color: #ddffdd">+ -- Operation: 'concatenate-source-op' ,
+ 'monolithic-concatenate-source-op',
+ 'load-concatenated-source-op',
+ 'compile-concatenated-source-op',
+ 'load-compiled-concatenated-source-op',
+ 'monolithic-load-concatenated-source-op',
+ 'monolithic-compile-concatenated-source-op',
+ 'monolithic-load-compiled-concatenated-source-op'
+
+ These operations, as their respective names indicate, will
+ concatenate all the 'cl-source-file' source files in a system (or
+ in a system and all its dependencies, if monolithic), in the order
+ defined by dependencies, then load the result, or compile and then
+ load the result.
+
+ These operations are useful to deliver a system or application as a
+ single source file, and for testing that said file loads properly,
+ or compiles and then loads properly.
+
+ ASDF itself is delivered as a single source file this way, using
+ 'monolithic-concatenate-source-op', prepending a prelude and the
+ 'uiop' library before the 'asdf/defsystem' system itself.
</span>
File: asdf.info, Node: Creating new operations, Prev: Predefined operations of ASDF, Up: Operations
<span style="color: #000000;background-color: #ffdddd">-6.1.2 Creating new operations
</span><span style="color: #000000;background-color: #ddffdd">+7.1.2 Creating new operations
</span> -----------------------------
ASDF was designed to be extensible in an object-oriented fashion. To
teach ASDF new tricks, a programmer can implement the behaviour he wants
<span style="color: #000000;background-color: #ffdddd">-by creating a subclass of `operation'.
</span><span style="color: #000000;background-color: #ddffdd">+by creating a subclass of 'operation'.
</span>
ASDF's pre-defined operations are in no way "privileged", but it is
<span style="color: #000000;background-color: #ffdddd">-requested that developers never use the `asdf' package for operations
</span><span style="color: #000000;background-color: #ddffdd">+requested that developers never use the 'asdf' package for operations
</span> they develop themselves. The rationale for this rule is that we don't
<span style="color: #000000;background-color: #ffdddd">-want to establish a "global asdf operation name registry", but also
-want to avoid name clashes.
</span><span style="color: #000000;background-color: #ddffdd">+want to establish a "global asdf operation name registry", but also want
+to avoid name clashes.
</span>
Your operation _must_ usually provide methods for one or more of the
following generic functions:
<span style="color: #000000;background-color: #ffdddd">- * `perform' Unless your operation, like `prepare-op', is for
</span><span style="color: #000000;background-color: #ddffdd">+ * 'perform' Unless your operation, like 'prepare-op', is for
</span> dependency propagation only, the most important function for which
<span style="color: #000000;background-color: #ffdddd">- to define a method is usually `perform', which will be called to
</span><span style="color: #000000;background-color: #ddffdd">+ to define a method is usually 'perform', which will be called to
</span> perform the operation on a specified component, after all
dependencies have been performed.
<span style="color: #000000;background-color: #ffdddd">- The `perform' method must call `output-files' (see below) to find
- out where to put its files, because the user is allowed to
- override the method or tweak the output-translation mechanism.
- Perform should only use the primary value returned by
- `output-files'. If one and only one output file is expected, it
- can call `output-file' that checks that this is the case and
</span><span style="color: #000000;background-color: #ddffdd">+ The 'perform' method must call 'input-files' and 'output-files'
+ (see below) to locate its inputs and outputs, because the user is
+ allowed to override the method or tweak the output-translation
+ mechanism. Perform should only use the primary value returned by
+ 'output-files'. If one and only one output file is expected, it
+ can call 'output-file' that checks that this is the case and
</span> returns the first and only list element.
<span style="color: #000000;background-color: #ffdddd">- * `output-files' If your perform method has any output, you must
- define a method for this function. for ASDF to determine where
- the outputs of performing operation lie.
</span><span style="color: #000000;background-color: #ddffdd">+ * 'output-files' If your perform method has any output, you must
+ define a method for this function. for ASDF to determine where the
+ outputs of performing operation lie.
</span>
Your method may return two values, a list of pathnames, and a
<span style="color: #000000;background-color: #ffdddd">- boolean. If the boolean is `nil' (or you fail to return multiple
- values), then enclosing `:around' methods may translate these
- pathnames, e.g. to ensure object files are somehow stored in some
- implementation-dependent cache. If the boolean is `t' then the
- pathnames are marked not be translated by the enclosing `:around'
</span><span style="color: #000000;background-color: #ddffdd">+ boolean. If the boolean is 'nil' (or you fail to return multiple
+ values), then enclosing ':around' methods may translate these
+ pathnames, e.g. to ensure object files are somehow stored in some
+ implementation-dependent cache. If the boolean is 't' then the
+ pathnames are marked not be translated by the enclosing ':around'
</span> method.
<span style="color: #000000;background-color: #ffdddd">- * `component-depends-on' If the action of performing the operation
- on a component has dependencies, you must define a method on
- `component-depends-on'.
</span><span style="color: #000000;background-color: #ddffdd">+ * 'component-depends-on' If the action of performing the operation on
+ a component has dependencies, you must define a method on
+ 'component-depends-on'.
</span>
Your method will take as specialized arguments an operation and a
component which together identify an action, and return a list of
<span style="color: #000000;background-color: #ffdddd">- entries describing actions that this action depends on. The
- format of entries is described below.
</span><span style="color: #000000;background-color: #ddffdd">+ entries describing actions that this action depends on. The format
+ of entries is described below.
</span>
It is _strongly_ advised that you should always append the results
<span style="color: #000000;background-color: #ffdddd">- of `(call-next-method)' to the results of your method, or
</span><span style="color: #000000;background-color: #ddffdd">+ of '(call-next-method)' to the results of your method, or
</span> "interesting" failures will likely occur, unless you're a true
specialist of ASDF internals. It is unhappily too late to
<span style="color: #000000;background-color: #ffdddd">- compatibly use the `append' method combination, but conceptually
</span><span style="color: #000000;background-color: #ddffdd">+ compatibly use the 'append' method combination, but conceptually
</span> that's the protocol that is being manually implemented.
<span style="color: #000000;background-color: #ffdddd">- Each entry returned by `component-depends-on' is itself a list.
</span><span style="color: #000000;background-color: #ddffdd">+ Each entry returned by 'component-depends-on' is itself a list.
</span>
<span style="color: #000000;background-color: #ffdddd">- The first element of an entry is an operation designator: either
- an operation object designating itself, or a symbol that names an
</span><span style="color: #000000;background-color: #ddffdd">+ The first element of an entry is an operation designator: either an
+ operation object designating itself, or a symbol that names an
</span> operation class (that ASDF will instantiate using
<span style="color: #000000;background-color: #ffdddd">- `make-operation'). For instance, `load-op', `compile-op' and
- `prepare-op' are common such names, denoting the respective
</span><span style="color: #000000;background-color: #ddffdd">+ 'make-operation'). For instance, 'load-op', 'compile-op' and
+ 'prepare-op' are common such names, denoting the respective
</span> operations.
<span style="color: #000000;background-color: #ffdddd">- The rest of each entry is a list of component designators: either
- a component object designating itself, or an identifier to be used
- with `find-component'. `find-component' will be called with the
</span><span style="color: #000000;background-color: #ddffdd">+ The rest of each entry is a list of component designators: either a
+ component object designating itself, or an identifier to be used
+ with 'find-component'. 'find-component' will be called with the
</span> current component's parent as parent, and the identifier as second
argument. The identifier is typically a string, a symbol (to be
<span style="color: #000000;background-color: #ffdddd">- downcased as per `coerce-name'), or a list of strings or symbols.
- In particular, the empty list `nil' denotes the parent itself.
-
</span><span style="color: #000000;background-color: #ddffdd">+ downcased as per 'coerce-name'), or a list of strings or symbols.
+ In particular, the empty list 'nil' denotes the parent itself.
</span>
An operation _may_ provide methods for the following generic
functions:
<span style="color: #000000;background-color: #ffdddd">- * `input-files' A method for this function is often not needed,
- since ASDF has a pretty clever default `input-files' mechanism.
- You only need create a method if there are multiple ultimate input
- files, and/or the bottom one doesn't depend on the
- `component-pathname' of the component.
</span><span style="color: #000000;background-color: #ddffdd">+ * 'input-files' A method for this function is often not needed, since
+ ASDF has a pretty clever default 'input-files' mechanism. You only
+ need create a method if there are multiple ultimate input files.
+ Most operations inherit from 'selfward-operation', which
+ appropriately sets the input-files to include the source file
+ itself.
</span>
<span style="color: #000000;background-color: #ffdddd">- * `operation-done-p' You only need to define a method on that
- function if you can detect conditions that invalidate previous
- runs of the operation, even though no filesystem timestamp has
- changed, in which case you return `nil' (the default is `t').
</span><span style="color: #000000;background-color: #ddffdd">+ -- Function: input-files operation component
+ Return a list of pathnames that represent the input to
+ OPERATION performed on COMPONENT.
</span>
<span style="color: #000000;background-color: #ffdddd">- For instance, the method for `test-op' always returns `nil', so
- that tests are always run afresh. Of course, the `test-op' for
- your system could depend on a deterministically repeatable
- `test-report-op', and just read the results from the report files,
- in which case you could have this method return `t'.
</span><span style="color: #000000;background-color: #ddffdd">+ * 'operation-done-p' You only need to define a method on that
+ function if you can detect conditions that invalidate previous runs
+ of the operation, even though no filesystem timestamp has changed,
+ in which case you return 'nil' (the default is 't').
</span>
<span style="color: #000000;background-color: #ddffdd">+ For instance, the method for 'test-op' always returns 'nil', so
+ that tests are always run afresh. Of course, the 'test-op' for
+ your system could depend on a deterministically repeatable
+ 'test-report-op', and just read the results from the report files,
+ in which case you could have this method return 't'.
</span>
Operations that print output should send that output to the standard
<span style="color: #000000;background-color: #ffdddd">-CL stream `*standard-output*', as the Lisp compiler and loader do.
</span><span style="color: #000000;background-color: #ddffdd">+CL stream '*standard-output*', as the Lisp compiler and loader do.
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: Components, Next: Functions, Prev: Operations, Up: The object model of ASDF
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: Components, Next: Dependencies, Prev: Operations, Up: The object model of ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">-6.2 Components
</span><span style="color: #000000;background-color: #ddffdd">+7.2 Components
</span> ==============
<span style="color: #000000;background-color: #ffdddd">-A "component" represents a source file or (recursively) a collection of
-components. A "system" is (roughly speaking) a top-level component
-that can be found via `find-system'.
</span><span style="color: #000000;background-color: #ddffdd">+A 'component' represents an individual source file or a group of source
+files, and the things that get transformed into. A 'system' is a
+component at the top level of the component hierarchy, that can be found
+via 'find-system'. A 'source-file' is a component representing a single
+source-file and the successive output files into which it is
+transformed. A 'module' is an intermediate component itself grouping
+several other components, themselves source-files or further modules.
</span>
A "system designator" is a system itself, or a string or symbol that
<span style="color: #000000;background-color: #ffdddd">-behaves just like any other component name (including with regard to
-the case conversion rules for component names).
</span><span style="color: #000000;background-color: #ddffdd">+behaves just like any other component name (including with regard to the
+case conversion rules for component names).
</span>
A "component designator", relative to a base component, is either a
component itself, or a string or symbol, or a list of designators.
-- Function: find-system system-designator &optional (error-p t)
<span style="color: #000000;background-color: #ffdddd">- Given a system designator, `find-system' finds and returns a
</span><span style="color: #000000;background-color: #ddffdd">+
+ Given a system designator, 'find-system' finds and returns a
</span> system. If no system is found, an error of type
<span style="color: #000000;background-color: #ffdddd">- `missing-component' is thrown, or `nil' is returned if `error-p'
- is false.
</span><span style="color: #000000;background-color: #ddffdd">+ 'missing-component' is thrown, or 'nil' is returned if 'error-p' is
+ false.
</span>
<span style="color: #000000;background-color: #ffdddd">- To find and update systems, `find-system' funcalls each element in
- the `*system-definition-search-functions*' list, expecting a
</span><span style="color: #000000;background-color: #ddffdd">+ To find and update systems, 'find-system' funcalls each element in
+ the '*system-definition-search-functions*' list, expecting a
</span> pathname to be returned, or a system object, from which a pathname
may be extracted, and that will be registered. The resulting
pathname (if any) is loaded if one of the following conditions is
true:
* there is no system of that name in memory
<span style="color: #000000;background-color: #ffdddd">-
</span> * the pathname is different from that which was previously
loaded
<span style="color: #000000;background-color: #ffdddd">-
- * the file's `last-modified' time exceeds the `last-modified'
</span><span style="color: #000000;background-color: #ddffdd">+ * the file's 'last-modified' time exceeds the 'last-modified'
</span> time of the system in memory
<span style="color: #000000;background-color: #ffdddd">- When system definitions are loaded from `.asd' files, a new
- scratch 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.
-
- The default value of `*system-definition-search-functions*' is a
- list of two functions. The first function looks in each of the
- directories given by evaluating members of `*central-registry*'
- for a file whose name is the name of the system and whose type is
- `asd'. The first such file is returned, whether or not it turns
- out to actually define the appropriate system. The second
- function does something similar, for the directories specified in
- the `source-registry'. Hence, it is strongly advised to define a
- system FOO in the corresponding file FOO.ASD.
</span><span style="color: #000000;background-color: #ddffdd">+ When system definitions are loaded from '.asd' files, they are
+ implicitly loaded into the 'ASDF-USER' package, which uses 'ASDF',
+ 'UIOP' and 'UIOP/COMMON-LISP'(1) Programmers who do anything
+ non-trivial in a '.asd' file, such as defining new variables,
+ functions or classes, should include 'defpackage' and 'in-package'
+ forms in this file, so they will not overwrite each others'
+ extensions. Such forms might also help the files behave
+ identically if loaded manually with 'cl:load' for development or
+ debugging, though we recommend you use the function
+ 'asdf::load-asd' instead, which the 'slime-asdf' contrib knows
+ about.
+
+ The default value of '*system-definition-search-functions*' is a
+ list of three functions. The first function looks in each of the
+ directories given by evaluating members of '*central-registry*' for
+ a file whose name is the name of the system and whose type is
+ 'asd'; the first such file is returned, whether or not it turns out
+ to actually define the appropriate system. The second function
+ does something similar, for the directories specified in the
+ 'source-registry', but searches the filesystem only once and caches
+ its results. The third function makes the
+ 'package-inferred-system' extension work, *note The
+ package-inferred-system extension::.
+
+ Because of the way these search functions are defined, you should
+ put the definition for a system FOO in a file named 'foo.asd', in a
+ directory that is in the central registry or which can be found
+ using the source registry configuration.
+
+ It is often useful to define multiple systems in a same file, but
+ ASDF can only locate a system's definition file based on the system
+ name. For this reason, ASDF 3's system search algorithm has been
+ extended to allow a file 'foo.asd' to contain secondary systems
+ named FOO/BAR, FOO/BAZ, FOO/QUUX, etc., in addition to the primary
+ system named FOO. The first component of a system name, separated
+ by the slash character, '/', is called the primary name of a
+ system. The primary name may be extracted by function
+ 'asdf::primary-system-name'; when ASDF 3 is told to find a system
+ whose name has a slash, it will first attempt to load the
+ corresponding primary system, and will thus see any such
+ definitions, and/or any definition of a
+ 'package-inferred-system'.(2) If your file 'foo.asd' also defines
+ systems that do not follow this convention, e.g., a system named
+ FOO-TEST, ASDF will not be able to automatically locate a
+ definition for these systems, and will only see their definition if
+ you explicitly find or load the primary system using e.g.
+ '(asdf:find-system "foo")' before you try to use them. We strongly
+ recommend against this practice, though it is currently supported
+ for backward compatibility.
+
+ -- Function: primary-system-name name
+
+ Internal (not exported) function, 'asdf::primary-system-name'.
+ Returns the primary system name (the portion before the slash, '/',
+ in a secondary system name) from NAME.
+
+ -- Function: locate-system name
+
+ This function should typically _not_ be invoked directly. It is
+ exported as part of the API only for programmers who wish to
+ provide their own '*system-definition-search-functions*'.
+
+ Given a system NAME designator, try to locate where to load the
+ system definition from. Returns five values: FOUNDP, FOUND-SYSTEM,
+ PATHNAME, PREVIOUS, and PREVIOUS-TIME. FOUNDP is true when a
+ system was found, either a new as yet unregistered one, or a
+ previously registered one. The FOUND-SYSTEM return value will be a
+ 'system' object, if a system definition is found in your source
+ registry. The system definition will _not_ be loaded if it hasn't
+ been loaded already. PATHNAME when not null is a path from which
+ to load the system, either associated with FOUND-SYSTEM, or with
+ the PREVIOUS system. If PREVIOUS is not null, it will be a
+ _previously loaded_ 'system' object of the same name (note that the
+ system _definition_ is previously-loaded: the system itself may or
+ may not be). PREVIOUS-TIME when not null is the timestamp of the
+ previous system definition file, at the time when the PREVIOUS
+ system definition was loaded.
+
+ For example, if your current registry has 'foo.asd' in
+ '/current/path/to/foo.asd', but system 'foo' was previously loaded
+ from '/previous/path/to/foo.asd' then LOCATE-SYSTEM will return the
+ following values:
+ 1. FOUNDP will be 'T',
+ 2. FOUND-SYSTEM will be 'NIL',
+ 3. PATHNAME will be '#p"/current/path/to/foo.asd"',
+ 4. PREVIOUS will be an object of type 'SYSTEM' with
+ 'system-source-file' slot value of
+ '#p"/previous/path/to/foo.asd"'
+ 5. PREVIOUS-TIME will be the timestamp of
+ '#p"/previous/path/to/foo.asd"' at the time it was loaded.
</span>
-- Function: find-component base path
<span style="color: #000000;background-color: #ddffdd">+
</span> Given a BASE component (or designator for such), and a PATH, find
the component designated by the PATH starting from the BASE.
If PATH is a component object, it designates itself, independently
from the base.
<span style="color: #000000;background-color: #ffdddd">- If PATH is a string, or symbol denoting a string via `coerce-name',
- then BASE is resolved to a component object, which must be a
- system or module, and the designated component is the child named
- by the PATH.
</span><span style="color: #000000;background-color: #ddffdd">+ If PATH is a string, or symbol denoting a string via 'coerce-name',
+ then BASE is resolved to a component object, which must be a system
+ or module, and the designated component is the child named by the
+ PATH.
</span>
<span style="color: #000000;background-color: #ffdddd">- If PATH is a `cons' cell, `find-component' with the base and the
- `car' of the PATH, and the resulting object is used as the base
- for a tail call to `find-component' with the `car' of the PATH.
</span><span style="color: #000000;background-color: #ddffdd">+ If PATH is a 'cons' cell, 'find-component' with the base and the
+ 'car' of the PATH, and the resulting object is used as the base for
+ a tail call to 'find-component' with the 'car' of the PATH.
</span>
If BASE is a component object, it designates itself.
<span style="color: #000000;background-color: #ffdddd">- If BASE is null, then PATH is used as the base, with `nil' as the
</span><span style="color: #000000;background-color: #ddffdd">+ If BASE is null, then PATH is used as the base, with 'nil' as the
</span> path.
<span style="color: #000000;background-color: #ffdddd">- If BASE is a string, or symbol denoting a string via `coerce-name',
- it designates a system as per `find-system'.
</span><span style="color: #000000;background-color: #ddffdd">+ If BASE is a string, or symbol denoting a string via 'coerce-name',
+ it designates a system as per 'find-system'.
</span>
<span style="color: #000000;background-color: #ffdddd">- If BASE is a `cons' cell, it designates the component found by
- `find-component' with its `car' as base and `cdr' as path.
</span><span style="color: #000000;background-color: #ddffdd">+ If BASE is a 'cons' cell, it designates the component found by
+ 'find-component' with its 'car' as base and 'cdr' as path.
</span>
* Menu:
<span style="color: #aaaaaa">@@ -1664,69 +2230,90 @@ component itself, or a string or symbol, or a list of designators.
</span> * Pre-defined subclasses of component::
* Creating new component types::
<span style="color: #000000;background-color: #ddffdd">+ ---------- Footnotes ----------
+
+ (1) Note that between releases 2.27 and 3.0.3, only 'UIOP/PACKAGE',
+not all of 'UIOP', was used; if you want your code to work with releases
+earlier than 3.1.2, you may have to explicitly define a package that
+uses 'UIOP', or use proper package prefix to your symbols, as in
+'uiop:version<'.
+
+ (2) ASDF 2.26 and earlier versions do not support this primary system
+name convention. With these versions of ASDF you must explicitly load
+'foo.asd' before you can use system FOO/BAR defined therein, e.g. using
+'(asdf:find-system "foo")'. We do not support ASDF 2, and recommend
+that you should upgrade to ASDF 3.
+
</span>
File: asdf.info, Node: Common attributes of components, Next: Pre-defined subclasses of component, Prev: Components, Up: Components
<span style="color: #000000;background-color: #ffdddd">-6.2.1 Common attributes of components
</span><span style="color: #000000;background-color: #ddffdd">+7.2.1 Common attributes of components
</span> -------------------------------------
All components, regardless of type, have the following attributes. All
<span style="color: #000000;background-color: #ffdddd">-attributes except `name' are optional.
</span><span style="color: #000000;background-color: #ddffdd">+attributes except 'name' are optional.
</span>
<span style="color: #000000;background-color: #ffdddd">-6.2.1.1 Name
</span><span style="color: #000000;background-color: #ddffdd">+7.2.1.1 Name
</span> ............
A component name is a string or a symbol. If a symbol, its name is
<span style="color: #000000;background-color: #ffdddd">-taken and lowercased.
</span><span style="color: #000000;background-color: #ddffdd">+taken and lowercased. This translation is performed by the exported
+function 'coerce-name'.
</span>
<span style="color: #000000;background-color: #ffdddd">- Unless overridden by a `:pathname' attribute, the name will be
</span><span style="color: #000000;background-color: #ddffdd">+ Unless overridden by a ':pathname' attribute, the name will be
</span> interpreted as a pathname specifier according to a Unix-style syntax.
*Note Pathname specifiers: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">-6.2.1.2 Version identifier
</span><span style="color: #000000;background-color: #ddffdd">+7.2.1.2 Version identifier
</span> ..........................
This optional attribute specifies a version for the current component.
The version should typically be a string of integers separated by dots,
<span style="color: #000000;background-color: #ffdddd">-for example `1.0.11'. For more information on version specifiers, see
</span><span style="color: #000000;background-color: #ddffdd">+for example '1.0.11'. For more information on version specifiers, see
</span> *note The defsystem grammar::.
A version may then be queried by the generic function
<span style="color: #000000;background-color: #ffdddd">-`version-satisfies', to see if `:version' dependencies are satisfied,
</span><span style="color: #000000;background-color: #ddffdd">+'version-satisfies', to see if ':version' dependencies are satisfied,
</span> and when specifying dependencies, a constraint of minimal version to
<span style="color: #000000;background-color: #ffdddd">-satisfy can be specified using e.g. `(:version "mydepname" "1.0.11")'.
</span><span style="color: #000000;background-color: #ddffdd">+satisfy can be specified using e.g. '(:version "mydepname" "1.0.11")'.
</span>
Note that in the wild, we typically see version numbering only on
<span style="color: #000000;background-color: #ffdddd">-components of type `system'. Presumably it is much less useful within
-a given system, wherein the library author is responsible to keep the
</span><span style="color: #000000;background-color: #ddffdd">+components of type 'system'. Presumably it is much less useful within a
+given system, wherein the library author is responsible to keep the
</span> various files in synch.
<span style="color: #000000;background-color: #ffdddd">-6.2.1.3 Required features
</span><span style="color: #000000;background-color: #ddffdd">+7.2.1.3 Required features
</span> .........................
<span style="color: #000000;background-color: #ffdddd">-Traditionally defsystem users have used `#+' reader conditionals to
-include or exclude specific per-implementation files. This means that
-any single implementation cannot read the entire system, which becomes
-a problem if it doesn't wish to compile it, but instead for example to
-create an archive file containing all the sources, as it will omit to
-process the system-dependent sources for other systems.
-
- Each component in an asdf system may therefore specify using
-`:if-feature' a feature expression using the same syntax as `#+' does,
-such that any reference to the component will be ignored during
-compilation, loading and/or linking if the expression evaluates to
-false. Since the expression is read by the normal reader, you must
-explicitly prefix your symbols with `:' so they be read as keywords;
-this is as contrasted with the `#+' syntax that implicitly reads
-symbols in the keyword package by default.
-
- For instance, `:if-feature (:and :x86 (:or :sbcl :cmu :scl))'
</span><span style="color: #000000;background-color: #ddffdd">+Traditionally defsystem users have used '#+' reader conditionals to
+include or exclude specific per-implementation files. For example,
+CFFI, the portable C foreign function interface contained lines like:
+ #+sbcl (:file "cffi-sbcl")
+ An unfortunate side effect of this approach is that no single
+implementation can read the entire system. This causes problems if, for
+example, one wished to design an 'archive-op' that would create an
+archive file containing all the sources, since for example the file
+'cffi-sbcl.lisp' above would be invisible when running the 'archive-op'
+on any implementation other than SBCL.
+
+ Starting with ASDF 3, components may therefore have an ':if-feature'
+option. The value of this option should be a feature expression using
+the same syntax as '#+' does. If that feature expression evaluates to
+false, any reference to the component will be ignored during
+compilation, loading and/or linking. Since the expression is read by
+the normal reader, you must explicitly prefix your symbols with ':' so
+they be read as keywords; this is as contrasted with the '#+' syntax
+that implicitly reads symbols in the keyword package by default.
+
+ For instance, ':if-feature (:and :x86 (:or :sbcl :cmu :scl))'
</span> specifies that the given component is only to be compiled and loaded
when the implementation is SBCL, CMUCL or Scieneer CL on an x86 machine.
<span style="color: #000000;background-color: #ffdddd">-You can not write it as `:if-feature (and x86 (or sbcl cmu scl))' since
-the symbols would presumably fail to be read as keywords.
</span><span style="color: #000000;background-color: #ddffdd">+You cannot write it as ':if-feature (and x86 (or sbcl cmu scl))' since
+the symbols would not be read as keywords.
</span>
<span style="color: #000000;background-color: #ffdddd">-6.2.1.4 Dependencies
</span><span style="color: #000000;background-color: #ddffdd">+ *Note if-feature-option::.
+
+7.2.1.4 Dependencies
</span> ....................
This attribute specifies dependencies of the component on its siblings.
<span style="color: #aaaaaa">@@ -1744,8 +2331,7 @@ initargs for the component, you can say
</span> This means the following things:
* before performing compile-op on this component, we must perform
load-op on A and B, and compile-op on C,
<span style="color: #000000;background-color: #ffdddd">-
- * before performing `load-op', we have to load FOO
</span><span style="color: #000000;background-color: #ddffdd">+ * before performing 'load-op', we have to load FOO
</span>
The syntax is approximately
<span style="color: #aaaaaa">@@ -1767,37 +2353,37 @@ general: it has an implied dependency
</span>
for all source file x, (load x) depends on (compile x)
<span style="color: #000000;background-color: #ffdddd">- and using a `:depends-on' argument to say that B depends on A
</span><span style="color: #000000;background-color: #ddffdd">+ and using a ':depends-on' argument to say that B depends on A
</span> _actually_ means that
(compile b) depends on (load a)
<span style="color: #000000;background-color: #ffdddd">- This is insufficient for e.g. the McCLIM system, which requires that
</span><span style="color: #000000;background-color: #ddffdd">+ This is insufficient for e.g. the McCLIM system, which requires that
</span> all the files are loaded before any of them can be compiled ]
End side note
In ASDF, the dependency information for a given component and
<span style="color: #000000;background-color: #ffdddd">-operation can be queried using `(component-depends-on operation
</span><span style="color: #000000;background-color: #ddffdd">+operation can be queried using '(component-depends-on operation
</span> component)', which returns a list
((load-op "a") (load-op "b") (compile-op "c") ...)
<span style="color: #000000;background-color: #ffdddd">- `component-depends-on' can be subclassed for more specific
-component/operation types: these need to `(call-next-method)' and
-append the answer to their dependency, unless they have a good reason
-for completely overriding the default dependencies.
</span><span style="color: #000000;background-color: #ddffdd">+ 'component-depends-on' can be subclassed for more specific
+component/operation types: these need to '(call-next-method)' and append
+the answer to their dependency, unless they have a good reason for
+completely overriding the default dependencies.
</span>
<span style="color: #000000;background-color: #ffdddd">- If it weren't for CLISP, we'd be using `LIST' method combination to
-do this transparently. But, we need to support CLISP. If you have the
</span><span style="color: #000000;background-color: #ddffdd">+ If it weren't for CLISP, we'd be using 'LIST' method combination to
+do this transparently. But, we need to support CLISP. If you have the
</span> time for some CLISP hacking, I'm sure they'd welcome your fixes.
A minimal version can be specified for a component you depend on
<span style="color: #000000;background-color: #ffdddd">-(typically another system), by specifying `(:version "other-system"
-"1.2.3")' instead of simply `"other-system"' as the dependency. See
-the discussion of the semantics of `:version' in the defsystem grammar.
</span><span style="color: #000000;background-color: #ddffdd">+(typically another system), by specifying '(:version "other-system"
+"1.2.3")' instead of simply '"other-system"' as the dependency. See the
+discussion of the semantics of ':version' in the defsystem grammar.
</span>
<span style="color: #000000;background-color: #ffdddd">-6.2.1.5 pathname
</span><span style="color: #000000;background-color: #ddffdd">+7.2.1.5 pathname
</span> ................
This attribute is optional and if absent (which is the usual case), the
<span style="color: #aaaaaa">@@ -1806,27 +2392,44 @@ component name will be used.
</span> *Note Pathname specifiers: The defsystem grammar, for an explanation
of how this attribute is interpreted.
<span style="color: #000000;background-color: #ffdddd">- Note that the `defsystem' macro (used to create a "top-level" system)
</span><span style="color: #000000;background-color: #ddffdd">+ Note that the 'defsystem' macro (used to create a "top-level" system)
</span> does additional processing to set the filesystem location of the top
<span style="color: #000000;background-color: #ffdddd">-component in that system. This is detailed elsewhere. *Note Defining
</span><span style="color: #000000;background-color: #ddffdd">+component in that system. This is detailed elsewhere. *Note Defining
</span> systems with defsystem::.
<span style="color: #000000;background-color: #ffdddd">-6.2.1.6 properties
</span><span style="color: #000000;background-color: #ddffdd">+ To find the CL pathname corresponding to a component, use
+
+ -- Function: component-pathname component
+ Returns the pathname corresponding to COMPONENT. For components
+ such as source files, this will be a filename pathname. For
+ example:
+
+ CL-USER> (asdf:component-pathname (asdf:find-system "xmls"))
+ #P"/Users/rpg/lisp/xmls/"
+
+ and
+
+ CL-USER> (asdf:component-pathname
+ (asdf:find-component
+ (asdf:find-system "xmls") "xmls"))
+ #P"/Users/rpg/lisp/xmls/xmls.lisp"
+
+7.2.1.6 properties
</span> ..................
This attribute is optional.
<span style="color: #000000;background-color: #ffdddd">- Packaging systems often require information about files or systems
-in addition to that specified by ASDF's pre-defined component
-attributes. Programs that create vendor packages out of ASDF systems
-therefore have to create "placeholder" information to satisfy these
-systems. Sometimes the creator of an ASDF system may know the
-additional information and wish to provide it directly.
</span><span style="color: #000000;background-color: #ddffdd">+ Packaging systems often require information about files or systems in
+addition to that specified by ASDF's pre-defined component attributes.
+Programs that create vendor packages out of ASDF systems therefore have
+to create "placeholder" information to satisfy these systems. Sometimes
+the creator of an ASDF system may know the additional information and
+wish to provide it directly.
</span>
<span style="color: #000000;background-color: #ffdddd">- `(component-property component property-name)' and associated `setf'
-method will allow the programmatic update of this information.
-Property names are compared as if by `EQL', so use symbols or keywords
-or something.
</span><span style="color: #000000;background-color: #ddffdd">+ '(component-property component property-name)' and associated 'setf'
+method will allow the programmatic update of this information. Property
+names are compared as if by 'EQL', so use symbols or keywords or
+something.
</span>
* Menu:
<span style="color: #aaaaaa">@@ -1836,17 +2439,18 @@ or something.
</span>
File: asdf.info, Node: Pre-defined subclasses of component, Next: Creating new component types, Prev: Common attributes of components, Up: Components
<span style="color: #000000;background-color: #ffdddd">-6.2.2 Pre-defined subclasses of component
</span><span style="color: #000000;background-color: #ddffdd">+7.2.2 Pre-defined subclasses of component
</span> -----------------------------------------
-- Component: source-file
<span style="color: #000000;background-color: #ddffdd">+
</span> A source file is any file that the system does not know how to
generate from other components of the system.
Note that this is not necessarily the same thing as "a file
<span style="color: #000000;background-color: #ffdddd">- containing data that is typically fed to a compiler". If a file
- is generated by some pre-processor stage (e.g. a `.h' file from
- `.h.in' by autoconf) then it is not, by this definition, a source
</span><span style="color: #000000;background-color: #ddffdd">+ containing data that is typically fed to a compiler". If a file is
+ generated by some pre-processor stage (e.g. a '.h' file from
+ '.h.in' by autoconf) then it is not, by this definition, a source
</span> file. Conversely, we might have a graphic file that cannot be
automatically regenerated, or a proprietary shared library that we
received as a binary: these do count as source files for our
<span style="color: #aaaaaa">@@ -1856,72 +2460,71 @@ File: asdf.info, Node: Pre-defined subclasses of component, Next: Creating new
</span> describe these._
-- Component: module
<span style="color: #000000;background-color: #ddffdd">+
</span> A module is a collection of sub-components.
A module component has the following extra initargs:
<span style="color: #000000;background-color: #ffdddd">- * `:components' the components contained in this module
</span><span style="color: #000000;background-color: #ddffdd">+ * ':components' the components contained in this module
</span>
<span style="color: #000000;background-color: #ffdddd">- * `:default-component-class' All children components which
- don't specify their class explicitly are inferred to be of
- this type.
</span><span style="color: #000000;background-color: #ddffdd">+ * ':default-component-class' All children components which don't
+ specify their class explicitly are inferred to be of this
+ type.
</span>
<span style="color: #000000;background-color: #ffdddd">- * `:if-component-dep-fails' This attribute was removed in ASDF
- 3. Do not use it. Use `:if-feature' instead.
</span><span style="color: #000000;background-color: #ddffdd">+ * ':if-component-dep-fails' This attribute was removed in ASDF
+ 3. Do not use it. Use ':if-feature' instead (*note
+ required-features::, and *note if-feature-option::).
</span>
<span style="color: #000000;background-color: #ffdddd">- * `:serial' When this attribute is set, each subcomponent of
</span><span style="color: #000000;background-color: #ddffdd">+ * ':serial' When this attribute is set, each subcomponent of
</span> this component is assumed to depend on all subcomponents
<span style="color: #000000;background-color: #ffdddd">- before it in the list given to `:components', i.e. all of
</span><span style="color: #000000;background-color: #ddffdd">+ before it in the list given to ':components', i.e. all of
</span> them are loaded before a compile or load operation is
performed on it.
<span style="color: #000000;background-color: #ffdddd">-
</span> The default operation knows how to traverse a module, so most
operations will not need to provide methods specialised on modules.
<span style="color: #000000;background-color: #ffdddd">- `module' may be subclassed to represent components such as
</span><span style="color: #000000;background-color: #ddffdd">+ 'module' may be subclassed to represent components such as
</span> foreign-language linked libraries or archive files.
-- Component: system
<span style="color: #000000;background-color: #ffdddd">- `system' is a subclass of `module'.
</span><span style="color: #000000;background-color: #ddffdd">+
+ 'system' is a subclass of 'module'.
</span>
A system is a module with a few extra attributes for documentation
purposes; these are given elsewhere. *Note The defsystem
grammar::.
Users can create new classes for their systems: the default
<span style="color: #000000;background-color: #ffdddd">- `defsystem' macro takes a `:class' keyword argument.
</span><span style="color: #000000;background-color: #ddffdd">+ 'defsystem' macro takes a ':class' keyword argument.
</span>
File: asdf.info, Node: Creating new component types, Prev: Pre-defined subclasses of component, Up: Components
<span style="color: #000000;background-color: #ffdddd">-6.2.3 Creating new component types
</span><span style="color: #000000;background-color: #ddffdd">+7.2.3 Creating new component types
</span> ----------------------------------
New component types are defined by subclassing one of the existing
component classes and specializing methods on the new component class.
<span style="color: #000000;background-color: #ffdddd">- _FIXME: this should perhaps be explained more throughly, not only by
-example ..._
-
</span> As an example, suppose we have some implementation-dependent
functionality that we want to isolate in one subdirectory per Lisp
implementation our system supports. We create a subclass of
<span style="color: #000000;background-color: #ffdddd">-`cl-source-file':
</span><span style="color: #000000;background-color: #ddffdd">+'cl-source-file':
</span>
(defclass unportable-cl-source-file (cl-source-file)
())
<span style="color: #000000;background-color: #ffdddd">- Function `asdf:implementation-type' (exported since 2.014.14) gives
</span><span style="color: #000000;background-color: #ddffdd">+ Function 'asdf:implementation-type' (exported since 2.014.14) gives
</span> us the name of the subdirectory. All that's left is to define how to
<span style="color: #000000;background-color: #ffdddd">-calculate the pathname of an `unportable-cl-source-file'.
</span><span style="color: #000000;background-color: #ddffdd">+calculate the pathname of an 'unportable-cl-source-file'.
</span>
(defmethod component-pathname ((component unportable-cl-source-file))
(merge-pathnames*
(parse-unix-namestring (format nil "~(~A~)/" (asdf:implementation-type)))
(call-next-method)))
<span style="color: #000000;background-color: #ffdddd">- The new component type is used in a `defsystem' form in this way:
</span><span style="color: #000000;background-color: #ddffdd">+ The new component type is used in a 'defsystem' form in this way:
</span>
(defsystem :foo
:components
<span style="color: #aaaaaa">@@ -1933,47 +2536,102 @@ calculate the pathname of an `unportable-cl-source-file'.
</span> )
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: Functions, Prev: Components, Up: The object model of ASDF
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: Dependencies, Next: Functions, Prev: Components, Up: The object model of ASDF
+
+7.3 Dependencies
+================
+
+To be successfully build-able, this graph of actions must be acyclic.
+If, as a user, extender or implementer of ASDF, you introduce a cycle
+into the dependency graph, ASDF will fail loudly. To clearly
+distinguish the direction of dependencies, ASDF 3 uses the words
+_requiring_ and _required_ as applied to an action depending on the
+other: the requiring action 'depends-on' the completion of all required
+actions before it may itself be 'perform'ed.
+
+ Using the 'defsystem' syntax, users may easily express direct
+dependencies along the graph of the object hierarchy: between a
+component and its parent, its children, and its siblings. By defining
+custom CLOS methods, you can express more elaborate dependencies as you
+wish. Most common operations, such as 'load-op', 'compile-op' or
+'load-source-op' are automatically propagate "downward" the component
+hierarchy and are "covariant" with it: to act the operation on the
+parent module, you must first act it on all the children components,
+with the action on the parent being parent of the action on each child.
+Other operations, such as 'prepare-op' and 'prepare-source-op'
+(introduced in ASDF 3) are automatically propagated "upward" the
+component hierarchy and are "contravariant" with it: to perform the
+operation of preparing for compilation of a child component, you must
+perform the operation of preparing for compilation of its parent
+component, and so on, ensuring that all the parent's dependencies are
+(compiled and) loaded before the child component may be compiled and
+loaded. Yet other operations, such as 'test-op' or 'load-bundle-op'
+remain at the system level, and are not propagated along the hierarchy,
+but instead do something global on the system.
+
+
+File: asdf.info, Node: Functions, Prev: Dependencies, Up: The object model of ASDF
</span>
<span style="color: #000000;background-color: #ffdddd">-6.3 Functions
</span><span style="color: #000000;background-color: #ddffdd">+7.4 Functions
</span> =============
<span style="color: #000000;background-color: #ffdddd">- -- version-satisfies: VERSION VERSION-SPEC
</span><span style="color: #000000;background-color: #ddffdd">+ -- Function: version-satisfies VERSION VERSION-SPEC
</span> Does VERSION satisfy the VERSION-SPEC. A generic function. ASDF
<span style="color: #000000;background-color: #ffdddd">- provides built-in methods for VERSION being a `component' or
- `string'. VERSION-SPEC should be a string. If it's a component,
</span><span style="color: #000000;background-color: #ddffdd">+ provides built-in methods for VERSION being a 'component' or
+ 'string'. VERSION-SPEC should be a string. If it's a component,
</span> its version is extracted as a string before further processing.
A version string satisfies the version-spec if after parsing, the
<span style="color: #000000;background-color: #ffdddd">- former is no older than the latter. Therefore `"1.9.1"',
- `"1.9.2"' and `"1.10"' all satisfy `"1.9.1"', but `"1.8.4"' or
- `"1.9"' do not. For more information about how
- `version-satisfies' parses and interprets version strings and
- specifications, *note The defsystem grammar:: (version specifiers)
- and *note Common attributes of components::.
</span><span style="color: #000000;background-color: #ddffdd">+ former is no older than the latter. Therefore '"1.9.1"', '"1.9.2"'
+ and '"1.10"' all satisfy '"1.9.1"', but '"1.8.4"' or '"1.9"' do
+ not. For more information about how 'version-satisfies' parses and
+ interprets version strings and specifications, *note The defsystem
+ grammar:: (version specifiers) and *note Common attributes of
+ components::.
</span>
Note that in versions of ASDF prior to 3.0.1, including the entire
<span style="color: #000000;background-color: #ffdddd">- ASDF 1 and ASDF 2 series, `version-satisfies' would also require
</span><span style="color: #000000;background-color: #ddffdd">+ ASDF 1 and ASDF 2 series, 'version-satisfies' would also require
</span> that the version and the version-spec have the same major version
number (the first integer in the list); if the major version
differed, the version would be considered as not matching the spec.
But that feature was not documented, therefore presumably not
relied upon, whereas it was a nuisance to several users. Starting
<span style="color: #000000;background-color: #ffdddd">- with ASDF 3.0.1, `version-satisfies' does not treat the major
</span><span style="color: #000000;background-color: #ddffdd">+ with ASDF 3.0.1, 'version-satisfies' does not treat the major
</span> version number specially, and returns T simply if the first
argument designates a version that isn't older than the one
<span style="color: #000000;background-color: #ffdddd">- specified as a second argument. If needs be, the `(:version ...)'
</span><span style="color: #000000;background-color: #ddffdd">+ specified as a second argument. If needs be, the '(:version ...)'
</span> syntax for specifying dependencies could be in the future extended
<span style="color: #000000;background-color: #ffdddd">- to specify an exclusive upper bound for compatible versions as
- well as an inclusive lower bound.
</span><span style="color: #000000;background-color: #ddffdd">+ to specify an exclusive upper bound for compatible versions as well
+ as an inclusive lower bound.
</span>
File: asdf.info, Node: Controlling where ASDF searches for systems, Next: Controlling where ASDF saves compiled files, Prev: The object model of ASDF, Up: Top
<span style="color: #000000;background-color: #ffdddd">-7 Controlling where ASDF searches for systems
</span><span style="color: #000000;background-color: #ddffdd">+8 Controlling where ASDF searches for systems
</span> *********************************************
<span style="color: #000000;background-color: #ffdddd">-7.1 Configurations
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* Configurations::
+* Truenames and other dangers::
+* XDG base directory::
+* Backward Compatibility::
+* Configuration DSL::
+* Configuration Directories::
+* Shell-friendly syntax for configuration::
+* Search Algorithm::
+* Caching Results::
+* Configuration API::
+* Introspection::
+* Status::
+* Rejected ideas::
+* TODO::
+* Credits for the source-registry::
+
+
+File: asdf.info, Node: Configurations, Next: Truenames and other dangers, Prev: Controlling where ASDF searches for systems, Up: Controlling where ASDF searches for systems
+
+8.1 Configurations
</span> ==================
Configurations specify paths where to find system files.
<span style="color: #aaaaaa">@@ -1985,47 +2643,55 @@ Configurations specify paths where to find system files.
</span> itself.
2. An application may explicitly initialize the source-registry
<span style="color: #000000;background-color: #ffdddd">- configuration using the configuration API (*note Configuration
- API: Controlling where ASDF searches for systems, below) in which
- case this takes precedence. It may itself compute this
- configuration from the command-line, from a script, from its own
- configuration file, etc.
</span><span style="color: #000000;background-color: #ddffdd">+ configuration using the configuration API (*note Configuration API:
+ Controlling where ASDF searches for systems, below) in which case
+ this takes precedence. It may itself compute this configuration
+ from the command-line, from a script, from its own configuration
+ file, etc.
</span>
3. The source registry will be configured from the environment
<span style="color: #000000;background-color: #ffdddd">- variable `CL_SOURCE_REGISTRY' if it exists.
</span><span style="color: #000000;background-color: #ddffdd">+ variable 'CL_SOURCE_REGISTRY' if it exists.
</span>
4. The source registry will be configured from user configuration file
<span style="color: #000000;background-color: #ffdddd">- `$XDG_CONFIG_DIRS/common-lisp/source-registry.conf' (which
- defaults to `~/.config/common-lisp/source-registry.conf') if it
- exists.
</span><span style="color: #000000;background-color: #ddffdd">+ '$XDG_CONFIG_DIRS/common-lisp/source-registry.conf' (which defaults
+ to '~/.config/common-lisp/source-registry.conf') if it exists.
</span>
5. The source registry will be configured from user configuration
<span style="color: #000000;background-color: #ffdddd">- directory `$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/'
- (which defaults to `~/.config/common-lisp/source-registry.conf.d/')
</span><span style="color: #000000;background-color: #ddffdd">+ directory '$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/'
+ (which defaults to '~/.config/common-lisp/source-registry.conf.d/')
</span> if it exists.
<span style="color: #000000;background-color: #ffdddd">- 6. The source registry will be configured from system configuration
- file `/etc/common-lisp/source-registry.conf' if it exists/
</span><span style="color: #000000;background-color: #ddffdd">+ 6. The source registry will be configured from default user
+ configuration trees '~/common-lisp/' (since ASDF 3.1.2 only),
+ '~/.sbcl/systems/' (on SBCL only),
+ '$XDG_DATA_HOME/common-lisp/systems/' (no recursion, link farm)
+ '$XDG_DATA_HOME/common-lisp/source/'. The 'XDG_DATA_HOME'
+ directory defaults to '~/.local/share/'. On Windows, the
+ 'local-appdata' and 'appdata' directories are used instead.
</span>
7. The source registry will be configured from system configuration
<span style="color: #000000;background-color: #ffdddd">- directory `/etc/common-lisp/source-registry.conf.d/' if it exists.
</span><span style="color: #000000;background-color: #ddffdd">+ file '/etc/common-lisp/source-registry.conf' if it exists.
</span>
<span style="color: #000000;background-color: #ffdddd">- 8. The source registry will be configured from a default
</span><span style="color: #000000;background-color: #ddffdd">+ 8. The source registry will be configured from system configuration
+ directory '/etc/common-lisp/source-registry.conf.d/' if it exists.
+
+ 9. The source registry will be configured from a default
</span> configuration. This configuration may allow for
implementation-specific systems to be found, for systems to be
found the current directory (at the time that the configuration is
<span style="color: #000000;background-color: #ffdddd">- initialized) as well as `:directory' entries for
- `$XDG_DATA_DIRS/common-lisp/systems/' and `:tree' entries for
- `$XDG_DATA_DIRS/common-lisp/source/'. For instance, SBCL will
- include directories for its contribs when it can find them; it
- will look for them where SBCL was installed, or at the location
- specified by the `SBCL_HOME' environment variable.
</span><span style="color: #000000;background-color: #ddffdd">+ initialized) as well as ':directory' entries for
+ '$XDG_DATA_DIRS/common-lisp/systems/' and ':tree' entries for
+ '$XDG_DATA_DIRS/common-lisp/source/', where 'XDG_DATA_DIRS'
+ defaults to '/usr/local/share' and '/usr/share' on Unix, and the
+ 'common-appdata' directory on Windows.
</span>
<span style="color: #000000;background-color: #ddffdd">+ 10. The source registry may include implementation-dependent
+ directories that correspond to implementation-provided extensions.
</span>
Each of these configurations is specified as an s-expression in a
trivial domain-specific language (defined below). Additionally, a more
<span style="color: #000000;background-color: #ffdddd">-shell-friendly syntax is available for the environment variable
-(defined yet below).
</span><span style="color: #000000;background-color: #ddffdd">+shell-friendly syntax is available for the environment variable (defined
+yet below).
</span>
Each of these configurations is only used if the previous
configuration explicitly or implicitly specifies that it includes its
<span style="color: #aaaaaa">@@ -2035,29 +2701,35 @@ inherited configuration.
</span> automatically prepended to whatever directories are specified in
configuration files, no matter if the last one inherits or not.
<span style="color: #000000;background-color: #ffdddd">-7.2 Truenames and other dangers
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Truenames and other dangers, Next: XDG base directory, Prev: Configurations, Up: Controlling where ASDF searches for systems
+
+8.2 Truenames and other dangers
</span> ===============================
One great innovation of the original ASDF was its ability to leverage
<span style="color: #000000;background-color: #ffdddd">-`CL:TRUENAME' to locate where your source code was and where to build
</span><span style="color: #000000;background-color: #ddffdd">+'CL:TRUENAME' to locate where your source code was and where to build
</span> it, allowing for symlink farms as a simple but effective configuration
mechanism that is easy to control programmatically. ASDF 3 still
<span style="color: #000000;background-color: #ffdddd">-supports this configuration style, and it is enabled by default;
-however we recommend you instead use our source-registry configuration
-mechanism described below, because it is easier to setup in a portable
-way across users and implementations.
</span><span style="color: #000000;background-color: #ddffdd">+supports this configuration style, and it is enabled by default; however
+we recommend you instead use our source-registry configuration mechanism
+described below, because it is easier to setup in a portable way across
+users and implementations.
</span>
<span style="color: #000000;background-color: #ffdddd">- Addtionally, some people dislike truename, either because it is very
</span><span style="color: #000000;background-color: #ddffdd">+ Additionally, some people dislike truename, either because it is very
</span> slow on their system, or because they are using content-addressed
storage where the truename of a file is related to a digest of its
individual contents, and not to other files in the same intended
<span style="color: #000000;background-color: #ffdddd">-project. For these people, ASDF 3 allows to eschew the `TRUENAME'
-mechanism, by setting the variable ASDF:*RESOLVE-SYMLINKS* to `nil'.
</span><span style="color: #000000;background-color: #ddffdd">+project. For these people, ASDF 3 allows to eschew the 'TRUENAME'
+mechanism, by setting the variable ASDF:*RESOLVE-SYMLINKS* to 'nil'.
</span>
PS: Yes, if you haven't read Vernor Vinge's short but great classic
<span style="color: #000000;background-color: #ffdddd">-"True Names... and Other Dangers" then you're in for a treat.
</span><span style="color: #000000;background-color: #ddffdd">+"True Names... and Other Dangers" then you're in for a treat.
</span>
<span style="color: #000000;background-color: #ffdddd">-7.3 XDG base directory
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: XDG base directory, Next: Backward Compatibility, Prev: Truenames and other dangers, Up: Controlling where ASDF searches for systems
+
+8.3 XDG base directory
</span> ======================
Note that we purport to respect the XDG base directory specification as
<span style="color: #aaaaaa">@@ -2065,61 +2737,76 @@ to where configuration files are located, where data files are located,
</span> where output file caches are located. Mentions of XDG variables refer
to that document.
<span style="color: #000000;background-color: #ffdddd">-`http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html'
</span><span style="color: #000000;background-color: #ddffdd">+ <http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html>
</span>
This specification allows the user to specify some environment
variables to customize how applications behave to his preferences.
<span style="color: #000000;background-color: #ffdddd">- On Windows platforms, when not using Cygwin, instead of the XDG base
-directory specification, we try to use folder configuration from the
-registry regarding `Common AppData' and similar directories. Since
</span><span style="color: #000000;background-color: #ddffdd">+ On Windows platforms, even when not using Cygwin, and starting with
+ASDF 3.1.5, we still do a best effort at following the XDG base
+directory specification, even though it doesn't exactly fit common
+practice for Windows applications. However, we replace the fixed Unix
+paths '~/.local', '/usr/local' and '/usr' with their rough Windows
+equivalent 'Local AppData', 'AppData', 'Common AppData', etc. Since
</span> support for querying the Windows registry is not possible to do in
reasonable amounts of portable Common Lisp code, ASDF 3 relies on the
<span style="color: #000000;background-color: #ffdddd">-environment variables that Windows usually exports.
</span><span style="color: #000000;background-color: #ddffdd">+environment variables that Windows usually exports, and are hopefully in
+synch with the Windows registry. If you care about the details, see
+'uiop/configuration.lisp' and don't hesitate to suggest improvements.
+
+
+File: asdf.info, Node: Backward Compatibility, Next: Configuration DSL, Prev: XDG base directory, Up: Controlling where ASDF searches for systems
</span>
<span style="color: #000000;background-color: #ffdddd">-7.4 Backward Compatibility
</span><span style="color: #000000;background-color: #ddffdd">+8.4 Backward Compatibility
</span> ==========================
For backward compatibility as well as to provide a practical backdoor
<span style="color: #000000;background-color: #ffdddd">-for hackers, ASDF will first search for `.asd' files in the directories
-specified in `asdf:*central-registry*' before it searches in the source
</span><span style="color: #000000;background-color: #ddffdd">+for hackers, ASDF will first search for '.asd' files in the directories
+specified in 'asdf:*central-registry*' before it searches in the source
</span> registry above.
<span style="color: #000000;background-color: #ffdddd">- *Note Configuring ASDF to find your systems -- old style:
-Configuring ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+ *Note Configuring ASDF to find your systems -- old style: Configuring
+ASDF.
</span>
<span style="color: #000000;background-color: #ffdddd">- By default, `asdf:*central-registry*' will be empty.
</span><span style="color: #000000;background-color: #ddffdd">+ By default, 'asdf:*central-registry*' will be empty.
</span>
This old mechanism will therefore not affect you if you don't use it,
but will take precedence over the new mechanism if you do use it.
<span style="color: #000000;background-color: #ffdddd">-7.5 Configuration DSL
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Configuration DSL, Next: Configuration Directories, Prev: Backward Compatibility, Up: Controlling where ASDF searches for systems
+
+8.5 Configuration DSL
</span> =====================
Here is the grammar of the s-expression (SEXP) DSL for source-registry
configuration:
<span style="color: #000000;background-color: #ffdddd">- ;; A configuration is a single SEXP starting with keyword :source-registry
- ;; followed by a list of directives.
</span><span style="color: #000000;background-color: #ddffdd">+ ;; A configuration is a single SEXP starting with the keyword
+ ;; :source-registry followed by a list of directives.
</span> CONFIGURATION := (:source-registry DIRECTIVE ...)
;; A directive is one of the following:
DIRECTIVE :=
;; INHERITANCE DIRECTIVE:
;; Your configuration expression MUST contain
<span style="color: #000000;background-color: #ffdddd">- ;; exactly one of either of these:
- :inherit-configuration | ; splices inherited configuration (often specified last)
- :ignore-inherited-configuration | ; drop inherited configuration (specified anywhere)
</span><span style="color: #000000;background-color: #ddffdd">+ ;; exactly one of the following:
+ :inherit-configuration |
+ ;; splices inherited configuration (often specified last) or
+ :ignore-inherited-configuration |
+ ;; drop inherited configuration (specified anywhere)
</span>
;; forward compatibility directive (since ASDF 2.011.4), useful when
<span style="color: #000000;background-color: #ffdddd">- ;; you want to use new configuration features but have to bootstrap a
- ;; the newer required ASDF from an older release that doesn't sport said features:
- :ignore-invalid-entries | ; drops subsequent invalid entries instead of erroring out
</span><span style="color: #000000;background-color: #ddffdd">+ ;; you want to use new configuration features but have to bootstrap
+ ;; the newer required ASDF from an older release that doesn't
+ ;; support said features:
+ :ignore-invalid-entries |
</span>
;; add a single directory to be scanned (no recursion)
(:directory DIRECTORY-PATHNAME-DESIGNATOR) |
<span style="color: #000000;background-color: #ffdddd">- ;; add a directory hierarchy, recursing but excluding specified patterns
</span><span style="color: #000000;background-color: #ddffdd">+ ;; add a directory hierarchy, recursing but
+ ;; excluding specified patterns
</span> (:tree DIRECTORY-PATHNAME-DESIGNATOR) |
;; override the defaults for exclusion patterns
<span style="color: #aaaaaa">@@ -2135,118 +2822,149 @@ configuration:
</span> ;; This directive specifies that some default must be spliced.
:default-registry
<span style="color: #000000;background-color: #ffdddd">- REGULAR-FILE-PATHNAME-DESIGNATOR := PATHNAME-DESIGNATOR ;; interpreted as a file
- DIRECTORY-PATHNAME-DESIGNATOR := PATHNAME-DESIGNATOR ;; interpreted as a directory name
</span><span style="color: #000000;background-color: #ddffdd">+ REGULAR-FILE-PATHNAME-DESIGNATOR
+ := PATHNAME-DESIGNATOR ; interpreted as a file
+ DIRECTORY-PATHNAME-DESIGNATOR
+ := PATHNAME-DESIGNATOR ; interpreted as a directory
</span>
PATHNAME-DESIGNATOR :=
NIL | ;; Special: skip this entry.
ABSOLUTE-COMPONENT-DESIGNATOR ;; see pathname DSL
<span style="color: #000000;background-color: #ffdddd">- EXCLUSION-PATTERN := a string without wildcards, that will be matched exactly
- against the name of a any subdirectory in the directory component
- of a path. e.g. `"_darcs"' will match `#p"/foo/bar/_darcs/src/bar.asd"'
</span><span style="color: #000000;background-color: #ddffdd">+ EXCLUSION-PATTERN := a string without wildcards, that will be matched
+ exactly against the name of a any subdirectory in the directory
+ component of a path. e.g. "_darcs" will match
+ #p"/foo/bar/_darcs/src/bar.asd"
</span>
Pathnames are designated using another DSL, shared with the
<span style="color: #000000;background-color: #ffdddd">-output-translations configuration DSL below. The DSL is resolved by
-the function `asdf::resolve-location', to be documented and exported at
-some point in the future.
</span><span style="color: #000000;background-color: #ddffdd">+output-translations configuration DSL below. The DSL is resolved by the
+function 'asdf::resolve-location', to be documented and exported at some
+point in the future.
</span>
ABSOLUTE-COMPONENT-DESIGNATOR :=
(ABSOLUTE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
<span style="color: #000000;background-color: #ffdddd">- STRING | ;; namestring (better be absolute or bust, directory assumed where applicable).
- ;; In output-translations, directory is assumed and **/*.*.* added if it's last.
- ;; On MCL, a MacOSX-style POSIX namestring (for MacOS9 style, use #p"...");
- ;; Note that none of the above applies to strings used in *central-registry*,
- ;; which doesn't use this DSL: they are processed as normal namestrings.
- ;; however, you can compute what you put in the *central-registry*
- ;; based on the results of say (asdf::resolve-location "/Users/fare/cl/cl-foo/")
- PATHNAME | ;; pathname (better be an absolute path, or bust)
- ;; In output-translations, unless followed by relative components,
- ;; it better have appropriate wildcards, as in **/*.*.*
- :HOME | ;; designates the user-homedir-pathname ~/
- :USER-CACHE | ;; designates the default location for the user cache
- :HERE | ;; designates the location of the configuration file
- ;; (or *default-pathname-defaults*, if invoked interactively)
- :ROOT ;; magic, for output-translations source only: paths that are relative
- ;; to the root of the source host and device
- ;; Not valid anymore: :SYSTEM-CACHE (was a security hazard)
</span><span style="color: #000000;background-color: #ddffdd">+ STRING |
+ ;; namestring (better be absolute or bust, directory assumed where
+ ;; applicable). In output-translations, directory is assumed and
+ ;; **/*.*.* added if it's last. On MCL, a MacOSX-style POSIX
+ ;; namestring (for MacOS9 style, use #p"..."); Note that none of the
+ ;; above applies to strings used in *central-registry*, which
+ ;; doesn't use this DSL: they are processed as normal namestrings.
+ ;; however, you can compute what you put in the *central-registry*
+ ;; based on the results of say
+ ;; (asdf::resolve-location "/Users/fare/cl/cl-foo/")
+ PATHNAME |
+ ;; pathname (better be an absolute path, or bust)
+ ;; In output-translations, unless followed by relative components,
+ ;; it better have appropriate wildcards, as in **/*.*.*
+ :HOME | ; designates the user-homedir-pathname ~/
+ :USER-CACHE | ; designates the default location for the user cache
+ :HERE |
+ ;; designates the location of the configuration file
+ ;; (or *default-pathname-defaults*, if invoked interactively)
+ :ROOT
+ ;; magic, for output-translations source only: paths that are relative
+ ;; to the root of the source host and device
+
+ They keyword :SYSTEM-CACHE is not accepted in ASDF 3.1 and beyond: it
+ was a security hazard.
</span>
RELATIVE-COMPONENT-DESIGNATOR :=
(RELATIVE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
<span style="color: #000000;background-color: #ffdddd">- STRING | ;; relative directory pathname as interpreted by parse-unix-namestring.
- ;; In output translations, if last component, **/*.*.* is added
- PATHNAME | ;; pathname; unless last component, directory is assumed.
- :IMPLEMENTATION | ;; directory based on implementation, e.g. sbcl-1.0.45-linux-x64
- :IMPLEMENTATION-TYPE | ;; a directory based on lisp-implementation-type only, e.g. sbcl
- :DEFAULT-DIRECTORY | ;; a relativized version of the default directory
</span><span style="color: #000000;background-color: #ddffdd">+ STRING |
+ ;; relative directory pathname as interpreted by
+ ;; parse-unix-namestring.
+ ;; In output translations, if last component, **/*.*.* is added
+ PATHNAME | ; pathname; unless last component, directory is assumed.
+ :IMPLEMENTATION |
+ ;; directory based on implementation, e.g. sbcl-1.0.45-linux-x64
+ :IMPLEMENTATION-TYPE |
+ ;; a directory based on lisp-implementation-type only, e.g. sbcl
+ :DEFAULT-DIRECTORY |
+ ;; a relativized version of the default directory
</span> :*/ | ;; any direct subdirectory (since ASDF 2.011.4)
:**/ | ;; any recursively inferior subdirectory (since ASDF 2.011.4)
:*.*.* | ;; any file (since ASDF 2.011.4)
<span style="color: #000000;background-color: #ffdddd">- ;; Not supported (anymore): :UID and :USERNAME
</span><span style="color: #000000;background-color: #ddffdd">+
+ The keywords :UID and :USERNAME are no longer supported.
</span>
For instance, as a simple case, my
<span style="color: #000000;background-color: #ffdddd">-`~/.config/common-lisp/source-registry.conf', which is the default
-place ASDF looks for this configuration, once contained:
</span><span style="color: #000000;background-color: #ddffdd">+'~/.config/common-lisp/source-registry.conf', which is the default place
+ASDF looks for this configuration, once contained:
</span> (:source-registry
(:tree (:home "cl")) ;; will expand to e.g. "/home/joeluser/cl/"
:inherit-configuration)
<span style="color: #000000;background-color: #ffdddd">-7.6 Configuration Directories
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Configuration Directories, Next: Shell-friendly syntax for configuration, Prev: Configuration DSL, Up: Controlling where ASDF searches for systems
+
+8.6 Configuration Directories
</span> =============================
Configuration directories consist in files each containing a list of
<span style="color: #000000;background-color: #ffdddd">-directives without any enclosing `(:source-registry ...)' form. The
-files will be sorted by namestring as if by `string<' and the lists of
</span><span style="color: #000000;background-color: #ddffdd">+directives without any enclosing '(:source-registry ...)' form. The
+files will be sorted by namestring as if by 'string<' and the lists of
</span> directives of these files with be concatenated in order. An implicit
<span style="color: #000000;background-color: #ffdddd">-`:inherit-configuration' will be included at the _end_ of the list.
</span><span style="color: #000000;background-color: #ddffdd">+':inherit-configuration' will be included at the _end_ of the list.
</span>
<span style="color: #000000;background-color: #ffdddd">- This allows for packaging software that has file granularity (e.g.
-Debian's `dpkg' or some future version of `clbuild') to easily include
-configuration information about distributed software.
</span><span style="color: #000000;background-color: #ddffdd">+ System-wide or per-user Common Lisp software distributions such as
+Debian packages or some future version of 'clbuild' may then include
+files such as '/etc/common-lisp/source-registry.conf.d/10-foo.conf' or
+'~/.config/common-lisp/source-registry.conf.d/10-foo.conf' to easily and
+modularly register configuration information about software being
+distributed.
</span>
The convention is that, for sorting purposes, the names of files in
<span style="color: #000000;background-color: #ffdddd">-such a directory begin with two digits that determine the order in
-which these entries will be read. Also, the type of these files is
-conventionally `"conf"' and as a limitation to some implementations
-(e.g. GNU clisp), the type cannot be `nil'.
</span><span style="color: #000000;background-color: #ddffdd">+such a directory begin with two digits that determine the order in which
+these entries will be read. Also, the type of these files must be
+'.conf', which not only simplifies the implementation by allowing for
+more portable techniques in finding those files, but also makes it
+trivial to disable a file, by renaming it to a different file type.
</span>
Directories may be included by specifying a directory pathname or
<span style="color: #000000;background-color: #ffdddd">-namestring in an `:include' directive, e.g.:
</span><span style="color: #000000;background-color: #ddffdd">+namestring in an ':include' directive, e.g.:
</span>
(:include "/foo/bar/")
Hence, to achieve the same effect as my example
<span style="color: #000000;background-color: #ffdddd">-`~/.config/common-lisp/source-registry.conf' above, I could simply
</span><span style="color: #000000;background-color: #ddffdd">+'~/.config/common-lisp/source-registry.conf' above, I could simply
</span> create a file
<span style="color: #000000;background-color: #ffdddd">-`~/.config/common-lisp/source-registry.conf.d/33-home-fare-cl.conf'
</span><span style="color: #000000;background-color: #ddffdd">+'~/.config/common-lisp/source-registry.conf.d/33-home-fare-cl.conf'
</span> alone in its directory with the following contents:
(:tree "/home/fare/cl/")
<span style="color: #000000;background-color: #ffdddd">-7.6.1 The :here directive
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* The here directive::
+
+
+File: asdf.info, Node: The here directive, Prev: Configuration Directories, Up: Configuration Directories
+
+8.6.1 The :here directive
</span> -------------------------
<span style="color: #000000;background-color: #ffdddd">-The `:here' directive is an absolute pathname designator that refers to
</span><span style="color: #000000;background-color: #ddffdd">+The ':here' directive is an absolute pathname designator that refers to
</span> the directory containing the configuration file currently being
processed.
<span style="color: #000000;background-color: #ffdddd">- The `:here' directive is intended to simplify the delivery of
-complex CL systems, and for easy configuration of projects shared
-through revision control systems, in accordance with our design
-principle that each participant should be able to provide all and only
-the information available to him or her.
</span><span style="color: #000000;background-color: #ddffdd">+ The ':here' directive is intended to simplify the delivery of complex
+CL systems, and for easy configuration of projects shared through
+revision control systems, in accordance with our design principle that
+each participant should be able to provide all and only the information
+available to him or her.
</span>
Consider a person X who has set up the source code repository for a
<span style="color: #000000;background-color: #ffdddd">-complex project with a master directory `dir/'. Ordinarily, one might
</span><span style="color: #000000;background-color: #ddffdd">+complex project with a master directory 'dir/'. Ordinarily, one might
</span> simply have the user add a directive that would look something like
this:
<span style="color: #000000;background-color: #ffdddd">- (:tree "path/to/dir")
- But what if X knows that there are very large subtrees under dir
-that are filled with, e.g., Java source code, image files for icons,
-etc.? All of the asdf system definitions are contained in the
-subdirectories `dir/src/lisp/' and `dir/extlib/lisp/', and these are
-the only directories that should be searched.
-
- In this case, X can put into `dir/' a file `asdf.conf' that contains
</span><span style="color: #000000;background-color: #ddffdd">+ (:tree "path/to/dir")
+ But what if X knows that there are very large subtrees under dir that
+are filled with, e.g., Java source code, image files for icons, etc.?
+All of the asdf system definitions are contained in the subdirectories
+'dir/src/lisp/' and 'dir/extlib/lisp/', and these are the only
+directories that should be searched.
+
+ In this case, X can put into 'dir/' a file 'asdf.conf' that contains
</span> the following:
(:source-registry
(:tree (:here "src/lisp/"))
<span style="color: #aaaaaa">@@ -2257,38 +2975,42 @@ the following:
</span> repository, she need only add
(:include "/path/to/my/checkout/directory/asdf.conf")
to one of her previously-existing asdf source location configuration
<span style="color: #000000;background-color: #ffdddd">-files, or invoke `initialize-source-registry' with a configuration form
</span><span style="color: #000000;background-color: #ddffdd">+files, or invoke 'initialize-source-registry' with a configuration form
</span> containing that s-expression. ASDF will find the .conf file that X has
provided, and then set up source locations within the working directory
according to X's (relative) instructions.
<span style="color: #000000;background-color: #ffdddd">-7.7 Shell-friendly syntax for configuration
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Shell-friendly syntax for configuration, Next: Search Algorithm, Prev: Configuration Directories, Up: Controlling where ASDF searches for systems
+
+8.7 Shell-friendly syntax for configuration
</span> ===========================================
<span style="color: #000000;background-color: #ffdddd">-When considering environment variable `CL_SOURCE_REGISTRY' ASDF will
-skip to next configuration if it's an empty string. It will `READ' the
-string as a SEXP in the DSL if it begins with a paren `(' and it will
-be interpreted much like `TEXINPUTS' list of paths, where
</span><span style="color: #000000;background-color: #ddffdd">+When considering environment variable 'CL_SOURCE_REGISTRY' ASDF will
+skip to next configuration if it's an empty string. It will 'READ' the
+string as a SEXP in the DSL if it begins with a paren '(', otherwise it
+will be interpreted much like 'TEXINPUTS', as a list of paths, where
</span>
<span style="color: #000000;background-color: #ffdddd">- * paths are separated by a `:' (colon) on Unix platforms
-(including cygwin), by a `;' (semicolon) on other platforms (mainly,
-Windows).
</span><span style="color: #000000;background-color: #ddffdd">+ * paths are separated by a ':' (colon) on Unix platforms (including
+cygwin), by a ';' (semicolon) on other platforms (mainly, Windows).
</span>
* each entry is a directory to add to the search path.
<span style="color: #000000;background-color: #ffdddd">- * if the entry ends with a double slash `//' then it instead
-indicates a tree in the subdirectories of which to recurse.
</span><span style="color: #000000;background-color: #ddffdd">+ * if the entry ends with a double slash '//' then it instead
+indicates a tree in the subdirectories of which to recurse.
+
+ * if the entry is the empty string (which may only appear once), then
+it indicates that the inherited configuration should be spliced there.
</span>
<span style="color: #000000;background-color: #ffdddd">- * if the entry is the empty string (which may only appear once),
-then it indicates that the inherited configuration should be
-spliced there.
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Search Algorithm, Next: Caching Results, Prev: Shell-friendly syntax for configuration, Up: Controlling where ASDF searches for systems
</span>
<span style="color: #000000;background-color: #ffdddd">-7.8 Search Algorithm
</span><span style="color: #000000;background-color: #ddffdd">+8.8 Search Algorithm
</span> ====================
In case that isn't clear, the semantics of the configuration is that
<span style="color: #000000;background-color: #ffdddd">-when searching for a system of a given name, directives are processed
-in order.
</span><span style="color: #000000;background-color: #ddffdd">+when searching for a system of a given name, directives are processed in
+order.
</span>
When looking in a directory, if the system is found, the search
succeeds, otherwise it continues.
<span style="color: #aaaaaa">@@ -2305,24 +3027,78 @@ kept by such version control systems as Darcs. Exclude statements are
</span> not propagated to further included or inherited configuration files or
expressions; instead the defaults are reset around every configuration
statement to the default defaults from
<span style="color: #000000;background-color: #ffdddd">-`asdf::*default-source-registry-exclusions*'.
</span><span style="color: #000000;background-color: #ddffdd">+'asdf::*default-source-registry-exclusions*'.
</span>
Include statements cause the search to recurse with the path
specifications from the file specified.
An inherit-configuration statement cause the search to recurse with
the path specifications from the next configuration (*note
<span style="color: #000000;background-color: #ffdddd">-Configurations: Controlling where ASDF searches for systems. above).
</span><span style="color: #000000;background-color: #ddffdd">+Configurations:: above).
</span>
<span style="color: #000000;background-color: #ffdddd">-7.9 Caching Results
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Caching Results, Next: Configuration API, Prev: Search Algorithm, Up: Controlling where ASDF searches for systems
+
+8.9 Caching Results
</span> ===================
The implementation is allowed to either eagerly compute the information
from the configurations and file system, or to lazily re-compute it
<span style="color: #000000;background-color: #ffdddd">-every time, or to cache any part of it as it goes. To explicitly flush
-any information cached by the system, use the API below.
</span><span style="color: #000000;background-color: #ddffdd">+every time, or to cache any part of it as it goes. In practice, the
+recommended 'source-registry' eagerly collects and caches results and
+you need to explicitly flush the cache for change to be taken into
+account, whereas the old-style '*central-registry*' mechanism queries
+the filesystem every time.
+
+ To explicitly flush any information cached by the system after a
+change was made in the filesystem, *Note Configuration API::, and e.g.
+call 'asdf:clear-source-registry'.
+
+ Starting with ASDF 3.1.4, you can also explicitly build a persistent
+cache of the '.asd' files found under a tree: when recursing into a
+directory declared by ':tree' and its transitive subdirectories, if a
+file '.cl-source-registry.cache' exists containing a form that is a list
+starting with ':source-registry-cache' followed by a list of strings, as
+in '(:source-registry-cache _"foo/bar.asd" "path/to/more.asd" ..._)',
+then the strings are assumed to be 'unix-namestring's designating the
+available asd files under that tree, and the recursion otherwise stops.
+The list can also be empty, allowing to stop a costly recursion in a
+huge directory tree.
+
+ To update such a cache after you install, update or remove source
+repositories, you can run a script distributed with ASDF:
+'tools/cl-source-registry-cache.lisp _/path/to/directory_'. To wholly
+invalidate the cache, you can delete the file
+'.cl-source-registry.cache' in that directory. In either case, for an
+existing Lisp process to see this change, it needs to clear its own
+cache with e.g. '(asdf:clear-source-registry)'.
+
+ Developers may safely create a cache in their development tree, and
+we recommend they do it at the top of their source tree if it contains
+more than a small number of files and directories; they only need update
+it when they create, remove or move '.asd' files. Software distribution
+managers may also safely create such a cache, but they must be careful
+to update it every time they install, update or remove a software source
+repository or installation package. Finally, advanced developers who
+juggle with a lot of code in their 'source-registry' may manually manage
+such a cache, to allow for faster startup of Lisp programs.
+
+ This persistence cache can help you reduce startup latency. For
+instance, on one machine with hundreds of source repositories, such a
+cache shaves half a second at the startup of every '#!/usr/bin/cl'
+script using SBCL, more on other implementations; this makes a notable
+difference as to their subjective interactivity and usability. The
+speedup will only happen if the implementation-provided ASDF is recent
+enough (3.1.3.7 or later); it is not enough for a recent ASDF upgrade to
+be present, since the upgrade will itself be found but after the old
+version has scanned the directories without heeding such a cache. To
+upgrade the implementation-provided ASDF, use our script
+'tools/install-asdf.lisp'.
+
+
+File: asdf.info, Node: Configuration API, Next: Introspection, Prev: Caching Results, Up: Controlling where ASDF searches for systems
</span>
<span style="color: #000000;background-color: #ffdddd">-7.10 Configuration API
</span><span style="color: #000000;background-color: #ddffdd">+8.10 Configuration API
</span> ======================
The specified functions are exported from your build system's package.
<span style="color: #aaaaaa">@@ -2331,105 +3107,165 @@ XCVB the corresponding functions are in package XCVB.
</span>
-- Function: initialize-source-registry &optional PARAMETER
will read the configuration and initialize all internal variables.
<span style="color: #000000;background-color: #ffdddd">- You may extend or override configuration from the environment
- and configuration files with the given PARAMETER, which can be
- `nil' (no configuration override), or a SEXP (in the SEXP DSL),
- a string (as in the string DSL), a pathname (of a file or
- directory with configuration), or a symbol (fbound to function
- that when called returns one of the above).
</span><span style="color: #000000;background-color: #ddffdd">+ You may extend or override configuration from the environment and
+ configuration files with the given PARAMETER, which can be 'nil'
+ (no configuration override), or a SEXP (in the SEXP DSL), a string
+ (as in the string DSL), a pathname (of a file or directory with
+ configuration), or a symbol (fbound to function that when called
+ returns one of the above).
</span>
-- Function: clear-source-registry
<span style="color: #000000;background-color: #ffdddd">- undoes any source registry configuration and clears any cache
- for the search algorithm. You might want to call this function
- (or better, `clear-configuration') before you dump an image
- that would be resumed with a different configuration, and
- return an empty configuration. Note that this does not include
- clearing information about systems defined in the current
- image, only about where to look for systems not yet defined.
</span><span style="color: #000000;background-color: #ddffdd">+ undoes any source registry configuration and clears any cache for
+ the search algorithm. You might want to call this function (or
+ better, 'clear-configuration') before you dump an image that would
+ be resumed with a different configuration, and return an empty
+ configuration. Note that this does not include clearing
+ information about systems defined in the current image, only about
+ where to look for systems not yet defined.
</span>
-- Function: ensure-source-registry &optional PARAMETER
<span style="color: #000000;background-color: #ffdddd">- checks whether a source registry has been initialized. If not,
</span><span style="color: #000000;background-color: #ddffdd">+ checks whether a source registry has been initialized. If not,
</span> initialize it with the given PARAMETER.
<span style="color: #000000;background-color: #ffdddd">- Every time you use ASDF's `find-system', or anything that uses it
-(such as `operate', `load-system', etc.), `ensure-source-registry' is
-called with parameter `nil', which the first time around causes your
</span><span style="color: #000000;background-color: #ddffdd">+ Every time you use ASDF's 'find-system', or anything that uses it
+(such as 'operate', 'load-system', etc.), 'ensure-source-registry' is
+called with parameter 'nil', which the first time around causes your
</span> configuration to be read. If you change a configuration file, you need
<span style="color: #000000;background-color: #ffdddd">-to explicitly `initialize-source-registry' again, or maybe simply to
-`clear-source-registry' (or `clear-configuration') which will cause the
</span><span style="color: #000000;background-color: #ddffdd">+to explicitly 'initialize-source-registry' again, or maybe simply to
+'clear-source-registry' (or 'clear-configuration') which will cause the
</span> initialization to happen next time around.
<span style="color: #000000;background-color: #ffdddd">-7.11 Status
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Introspection, Next: Status, Prev: Configuration API, Up: Controlling where ASDF searches for systems
+
+8.11 Introspection
+==================
+
+* Menu:
+
+* *source-registry-parameter* variable::
+* Information about system dependencies::
+
+
+File: asdf.info, Node: *source-registry-parameter* variable, Next: Information about system dependencies, Prev: Introspection, Up: Introspection
+
+8.11.1 *source-registry-parameter* variable
+-------------------------------------------
+
+We have made available the variable '*source-registry-parameter*' that
+can be used by code that wishes to introspect about the (past)
+configuration of ASDF's source registry. *This variable should never be
+set!* It will be set as a side-effect of calling
+'initialize-source-registry'; user code should treat it as read-only.
+
+
+File: asdf.info, Node: Information about system dependencies, Prev: *source-registry-parameter* variable, Up: Introspection
+
+8.11.2 Information about system dependencies
+--------------------------------------------
+
+ASDF makes available three functions to read system interdependencies.
+These are intended to aid programmers who wish to perform dependency
+analyses.
+
+ -- Function: system-defsystem-depends-on system
+
+ -- Function: system-depends-on system
+
+ -- Function: system-weakly-depends-on system
+ Returns a list of names of systems that are weakly depended on by
+ SYSTEM. Weakly depended on systems are optionally loaded only if
+ ASDF can find them; failure to find such systems does _not_ cause
+ an error in loading.
+
+ Note that the return value for 'system-weakly-depends-on' is
+ simpler than the return values of the other two system dependency
+ introspection functions.
+
+
+File: asdf.info, Node: Status, Next: Rejected ideas, Prev: Introspection, Up: Controlling where ASDF searches for systems
+
+8.12 Status
</span> ===========
This mechanism is vastly successful, and we have declared that
<span style="color: #000000;background-color: #ffdddd">-`asdf:*central-registry*' is not recommended anymore, though we will
</span><span style="color: #000000;background-color: #ddffdd">+'asdf:*central-registry*' is not recommended anymore, though we will
</span> continue to support it. All hooks into implementation-specific search
<span style="color: #000000;background-color: #ffdddd">-mechanisms have been integrated in the `wrapping-source-registry' that
</span><span style="color: #000000;background-color: #ddffdd">+mechanisms have been integrated in the 'wrapping-source-registry' that
</span> everyone uses implicitly.
<span style="color: #000000;background-color: #ffdddd">-7.12 Rejected ideas
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Rejected ideas, Next: TODO, Prev: Status, Up: Controlling where ASDF searches for systems
+
+8.13 Rejected ideas
</span> ===================
<span style="color: #000000;background-color: #ffdddd">-Alternatives I considered and rejected included:
</span><span style="color: #000000;background-color: #ddffdd">+Alternatives I (FRR) considered and rejected while developing ASDF 2
+included:
</span>
<span style="color: #000000;background-color: #ffdddd">- 1. Keep `asdf:*central-registry*' as the master with its current
- semantics, and somehow the configuration parser expands the new
- configuration language into a expanded series of directories of
- subdirectories to lookup, pre-recursing through specified
- hierarchies. This is kludgy, and leaves little space of future
</span><span style="color: #000000;background-color: #ddffdd">+ 1. Keep 'asdf:*central-registry*' as the master with its current
+ semantics, and somehow the configuration parser expands the new
+ configuration language into a expanded series of directories of
+ subdirectories to lookup, pre-recursing through specified
+ hierarchies. This is kludgy, and leaves little space of future
</span> cleanups and extensions.
<span style="color: #000000;background-color: #ffdddd">- 2. Keep `asdf:*central-registry*' remains the master but extend its
- semantics in completely new ways, so that new kinds of entries
- may be implemented as a recursive search, etc. This seems
- somewhat backwards.
</span><span style="color: #000000;background-color: #ddffdd">+ 2. Keep 'asdf:*central-registry*' as the master but extend its
+ semantics in completely new ways, so that new kinds of entries may
+ be implemented as a recursive search, etc. This seems somewhat
+ backwards.
</span>
<span style="color: #000000;background-color: #ffdddd">- 3. Completely remove `asdf:*central-registry*' and break backwards
- compatibility. Hopefully this will happen in a few years after
- everyone migrate to a better ASDF and/or to XCVB, but it would
- be very bad to do it now.
</span><span style="color: #000000;background-color: #ddffdd">+ 3. Completely remove 'asdf:*central-registry*' and break backwards
+ compatibility. Hopefully this will happen in a few years after
+ everyone migrate to a better ASDF and/or to XCVB, but it would be
+ very bad to do it now.
</span>
<span style="color: #000000;background-color: #ffdddd">- 4. Replace `asdf:*central-registry*' by a symbol-macro with
- appropriate magic when you dereference it or setf it. Only the
- new variable with new semantics is handled by the new search
- procedure. Complex and still introduces subtle semantic issues.
</span><span style="color: #000000;background-color: #ddffdd">+ 4. Replace 'asdf:*central-registry*' by a symbol-macro with
+ appropriate magic when you dereference it or setf it. Only the new
+ variable with new semantics is handled by the new search procedure.
+ Complex and still introduces subtle semantic issues.
</span>
I've been suggested the below features, but have rejected them, for
the sake of keeping ASDF no more complex than strictly necessary.
<span style="color: #000000;background-color: #ffdddd">- * More syntactic sugar: synonyms for the configuration directives,
- such as `(:add-directory X)' for `(:directory X)', or
- `(:add-directory-hierarchy X)' or `(:add-directory X :recurse
- t)' for `(:tree X)'.
</span><span style="color: #000000;background-color: #ddffdd">+ * More syntactic sugar: synonyms for the configuration directives,
+ such as '(:add-directory X)' for '(:directory X)', or
+ '(:add-directory-hierarchy X)' or '(:add-directory X :recurse t)'
+ for '(:tree X)'.
</span>
<span style="color: #000000;background-color: #ffdddd">- * The possibility to register individual files instead of
</span><span style="color: #000000;background-color: #ddffdd">+ * The possibility to register individual files instead of
</span> directories.
<span style="color: #000000;background-color: #ffdddd">- * Integrate Xach Beane's tilde expander into the parser, or
- something similar that is shell-friendly or shell-compatible.
- I'd rather keep ASDF minimal. But maybe this precisely keeps it
- minimal by removing the need for evaluated entries that ASDF has?
- i.e. uses of `USER-HOMEDIR-PATHNAME' and `$SBCL_HOME'
- Hopefully, these are already superseded by the `:default-registry'
</span><span style="color: #000000;background-color: #ddffdd">+ * Integrate Xach Beane's tilde expander into the parser, or something
+ similar that is shell-friendly or shell-compatible. I'd rather
+ keep ASDF minimal. But maybe this precisely keeps it minimal by
+ removing the need for evaluated entries that ASDF has? i.e. uses
+ of 'USER-HOMEDIR-PATHNAME' and '$SBCL_HOME' Hopefully, these are
+ already superseded by the ':default-registry'
</span>
<span style="color: #000000;background-color: #ffdddd">- * Using the shell-unfriendly syntax `/**' instead of `//' to
- specify recursion down a filesystem tree in the environment
- variable. It isn't that Lisp friendly either.
</span><span style="color: #000000;background-color: #ddffdd">+ * Using the shell-unfriendly syntax '/**' instead of TEXINPUTS-like
+ '//' to specify recursion down a filesystem tree in the environment
+ variable. It isn't that Lisp friendly either.
</span>
<span style="color: #000000;background-color: #ffdddd">-7.13 TODO
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: TODO, Next: Credits for the source-registry, Prev: Rejected ideas, Up: Controlling where ASDF searches for systems
+
+8.14 TODO
</span> =========
* Add examples
<span style="color: #000000;background-color: #ffdddd">-7.14 Credits for the source-registry
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Credits for the source-registry, Prev: TODO, Up: Controlling where ASDF searches for systems
+
+8.15 Credits for the source-registry
</span> ====================================
Thanks a lot to Stelian Ionescu for the initial idea.
Thanks to Rommel Martinez for the initial implementation attempt.
<span style="color: #000000;background-color: #ffdddd">- All bad design ideas and implementation bugs are to mine, not theirs.
</span><span style="color: #000000;background-color: #ddffdd">+ All bad design ideas and implementation bugs are mine, not theirs.
</span> But so are good design ideas and elegant implementation tricks.
-- Francois-Rene Rideau <fare@tunes.org>, Mon, 22 Feb 2010 00:07:33
<span style="color: #aaaaaa">@@ -2438,22 +3274,44 @@ But so are good design ideas and elegant implementation tricks.
</span>
File: asdf.info, Node: Controlling where ASDF saves compiled files, Next: Error handling, Prev: Controlling where ASDF searches for systems, Up: Top
<span style="color: #000000;background-color: #ffdddd">-8 Controlling where ASDF saves compiled files
</span><span style="color: #000000;background-color: #ddffdd">+9 Controlling where ASDF saves compiled files
</span> *********************************************
<span style="color: #000000;background-color: #ffdddd">-Each Common Lisp implementation has its own format for compiled files
-(fasls for short, short for "fast loading"). If you use multiple
-implementations (or multiple versions of the same implementation),
-you'll soon find your source directories littered with various `fasl's,
-`dfsl's, `cfsl's and so on. Worse yet, some implementations use the
-same file extension while changing formats from version to version (or
-platform to platform) which means that you'll have to recompile binaries
-as you switch from one implementation to the next.
-
- Since ASDF 2, ASDF includes the `asdf-output-translations' facility
</span><span style="color: #000000;background-color: #ddffdd">+Each Common Lisp implementation has its own format for compiled files or
+fasls.(1) If you use multiple implementations (or multiple versions of
+the same implementation), you'll soon find your source directories
+littered with various 'fasl's, 'dfsl's, 'cfsl's and so on. Worse yet,
+multiple implementations use the same file extension and some
+implementations maintain the same file extension while changing formats
+from version to version (or platform to platform). This can lead to
+many errors and much confusion as you switch from one implementation to
+the next. Finally, this requires write access to the source directory,
+and therefore precludes sharing of a same source code directory between
+multiple users.
+
+ Since ASDF 2, ASDF includes the 'asdf-output-translations' facility
</span> to mitigate the problem.
<span style="color: #000000;background-color: #ffdddd">-8.1 Configurations
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* Output Configurations::
+* Output Backward Compatibility::
+* Output Configuration DSL::
+* Output Configuration Directories::
+* Output Shell-friendly syntax for configuration::
+* Semantics of Output Translations::
+* Output Caching Results::
+* Output location API::
+* Credits for output translations::
+
+ ---------- Footnotes ----------
+
+ (1) "FASL" is short for "FASt Loading."
+
+
+File: asdf.info, Node: Output Configurations, Next: Output Backward Compatibility, Prev: Controlling where ASDF saves compiled files, Up: Controlling where ASDF saves compiled files
+
+9.1 Configurations
</span> ==================
Configurations specify mappings from input locations to output
<span style="color: #aaaaaa">@@ -2463,110 +3321,116 @@ searches for systems.
</span>
1. Some hardcoded wrapping output translations configuration may be
used. This allows special output translations (or usually,
<span style="color: #000000;background-color: #ffdddd">- invariant directories) to be specified corresponding to the
- similar special entries in the source registry.
</span><span style="color: #000000;background-color: #ddffdd">+ invariant directories) to be specified corresponding to the similar
+ special entries in the source registry.
</span>
2. An application may explicitly initialize the output-translations
configuration using the Configuration API in which case this takes
<span style="color: #000000;background-color: #ffdddd">- precedence. (*note Configuration API: Controlling where ASDF
- saves compiled files.) It may itself compute this configuration
- from the command-line, from a script, from its own configuration
- file, etc.
</span><span style="color: #000000;background-color: #ddffdd">+ precedence. (*note Configuration API: Controlling where ASDF saves
+ compiled files.) It may itself compute this configuration from the
+ command-line, from a script, from its own configuration file, etc.
</span>
3. The source registry will be configured from the environment
<span style="color: #000000;background-color: #ffdddd">- variable `ASDF_OUTPUT_TRANSLATIONS' if it exists.
</span><span style="color: #000000;background-color: #ddffdd">+ variable 'ASDF_OUTPUT_TRANSLATIONS' if it exists.
</span>
4. The source registry will be configured from user configuration file
<span style="color: #000000;background-color: #ffdddd">- `$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf'
- (which defaults to
- `~/.config/common-lisp/asdf-output-translations.conf') if it
- exists.
</span><span style="color: #000000;background-color: #ddffdd">+ '$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf' (which
+ defaults to '~/.config/common-lisp/asdf-output-translations.conf')
+ if it exists.
</span>
5. The source registry will be configured from user configuration
directory
<span style="color: #000000;background-color: #ffdddd">- `$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf.d/'
</span><span style="color: #000000;background-color: #ddffdd">+ '$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf.d/'
</span> (which defaults to
<span style="color: #000000;background-color: #ffdddd">- `~/.config/common-lisp/asdf-output-translations.conf.d/') if it
</span><span style="color: #000000;background-color: #ddffdd">+ '~/.config/common-lisp/asdf-output-translations.conf.d/') if it
</span> exists.
6. The source registry will be configured from system configuration
<span style="color: #000000;background-color: #ffdddd">- file `/etc/common-lisp/asdf-output-translations.conf' if it exists.
</span><span style="color: #000000;background-color: #ddffdd">+ file '/etc/common-lisp/asdf-output-translations.conf' if it exists.
</span>
7. The source registry will be configured from system configuration
<span style="color: #000000;background-color: #ffdddd">- directory `/etc/common-lisp/asdf-output-translations.conf.d/' if
- it exists.
</span><span style="color: #000000;background-color: #ddffdd">+ directory '/etc/common-lisp/asdf-output-translations.conf.d/' if it
+ exists.
+
+ Each of these configurations is specified as a SEXP in a trivial
+domain-specific language (*note Configuration DSL::). Additionally, a
+more shell-friendly syntax is available for the environment variable
+(*note Shell-friendly syntax for configuration::).
+
+ When processing an entry in the above list of configuration methods,
+ASDF will stop unless that entry explicitly or implicitly specifies that
+it includes its inherited configuration.
</span>
<span style="color: #000000;background-color: #ddffdd">+ Note that by default, a per-user cache is used for output files.
+This allows the seamless use of shared installations of software between
+several users, and takes files out of the way of the developers when
+they browse source code, at the expense of taking a small toll when
+developers have to clean up output files and find they need to get
+familiar with output-translations first.(1)
</span>
<span style="color: #000000;background-color: #ffdddd">- Each of these configurations is specified as a SEXP in a trival
-domain-specific language (defined below). Additionally, a more
-shell-friendly syntax is available for the environment variable
-(defined yet below).
</span><span style="color: #000000;background-color: #ddffdd">+ ---------- Footnotes ----------
</span>
<span style="color: #000000;background-color: #ffdddd">- Each of these configurations is only used if the previous
-configuration explicitly or implicitly specifies that it includes its
-inherited configuration.
</span><span style="color: #000000;background-color: #ddffdd">+ (1) A 'CLEAN-OP' would be a partial solution to this problem.
</span>
<span style="color: #000000;background-color: #ffdddd">- Note that by default, a per-user cache is used for output files.
-This allows the seamless use of shared installations of software
-between several users, and takes files out of the way of the developers
-when they browse source code, at the expense of taking a small toll
-when developers have to clean up output files and find they need to get
-familiar with output-translations first.
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Output Backward Compatibility, Next: Output Configuration DSL, Prev: Output Configurations, Up: Controlling where ASDF saves compiled files
</span>
<span style="color: #000000;background-color: #ffdddd">-8.2 Backward Compatibility
</span><span style="color: #000000;background-color: #ddffdd">+9.2 Backward Compatibility
</span> ==========================
<span style="color: #000000;background-color: #ffdddd">-We purposefully do NOT provide backward compatibility with earlier
-versions of `ASDF-Binary-Locations' (8 Sept 2009),
-`common-lisp-controller' (7.0) or `cl-launch' (2.35), each of which had
-similar general capabilities. The previous APIs of these programs were
-not designed for configuration by the end-user in an easy way with
-configuration files. Recent versions of same packages use the new
-`asdf-output-translations' API as defined below:
-`common-lisp-controller' (7.2) and `cl-launch' (3.000).
-`ASDF-Binary-Locations' is fully superseded and not to be used anymore.
</span><span style="color: #000000;background-color: #ddffdd">+We purposely do _not_ provide backward compatibility with earlier
+versions of 'ASDF-Binary-Locations' (8 Sept 2009),
+'common-lisp-controller' (7.0) or 'cl-launch' (2.35), each of which had
+similar general capabilities. The APIs of these programs were not
+designed for easy user configuration through configuration files.
+Recent versions of 'common-lisp-controller' (7.2) and 'cl-launch'
+(3.000) use the new 'asdf-output-translations' API as defined below.
+'ASDF-Binary-Locations' is fully superseded and not to be used anymore.
</span>
This incompatibility shouldn't inconvenience many people. Indeed,
few people use and customize these packages; these few people are
experts who can trivially adapt to the new configuration. Most people
are not experts, could not properly configure these features (except
<span style="color: #000000;background-color: #ffdddd">-inasmuch as the default configuration of `common-lisp-controller'
-and/or `cl-launch' might have been doing the right thing for some
-users), and yet will experience software that "just works", as
-configured by the system distributor, or by default.
</span><span style="color: #000000;background-color: #ddffdd">+inasmuch as the default configuration of 'common-lisp-controller' and/or
+'cl-launch' might have been doing the right thing for some users), and
+yet will experience software that "just works", as configured by the
+system distributor, or by default.
</span>
<span style="color: #000000;background-color: #ffdddd">- Nevertheless, if you are a fan of `ASDF-Binary-Locations', we
-provide a limited emulation mode:
</span><span style="color: #000000;background-color: #ddffdd">+ Nevertheless, if you are a fan of 'ASDF-Binary-Locations', we provide
+a limited emulation mode:
</span>
-- Function: enable-asdf-binary-locations-compatibility &key
centralize-lisp-binaries default-toplevel-directory
include-per-user-information map-all-source-files
source-to-target-mappings
<span style="color: #000000;background-color: #ffdddd">- This function will initialize the new `asdf-output-translations'
- facility in a way that emulates the behavior of the old
- `ASDF-Binary-Locations' facility. Where you would previously set
</span><span style="color: #000000;background-color: #ddffdd">+ This function will initialize the new 'asdf-output-translations'
+ facility in a way that emulates the behaviour of the old
+ 'ASDF-Binary-Locations' facility. Where you would previously set
</span> global variables *CENTRALIZE-LISP-BINARIES*,
*DEFAULT-TOPLEVEL-DIRECTORY*, *INCLUDE-PER-USER-INFORMATION*,
*MAP-ALL-SOURCE-FILES* or *SOURCE-TO-TARGET-MAPPINGS* you will now
have to pass the same values as keyword arguments to this function.
<span style="color: #000000;background-color: #ffdddd">- Note however that as an extension the `:source-to-target-mappings'
</span><span style="color: #000000;background-color: #ddffdd">+ Note however that as an extension the ':source-to-target-mappings'
</span> keyword argument will accept any valid pathname designator for
<span style="color: #000000;background-color: #ffdddd">- `asdf-output-translations' instead of just strings and pathnames.
</span><span style="color: #000000;background-color: #ddffdd">+ 'asdf-output-translations' instead of just strings and pathnames.
</span>
If you insist, you can also keep using the old
<span style="color: #000000;background-color: #ffdddd">-`ASDF-Binary-Locations' (the one available as an extension to load of
</span><span style="color: #000000;background-color: #ddffdd">+'ASDF-Binary-Locations' (the one available as an extension to load of
</span> top of ASDF, not the one built into a few old versions of ASDF), but
<span style="color: #000000;background-color: #ffdddd">-first you must disable `asdf-output-translations' with
-`(asdf:disable-output-translations)', or you might experience
</span><span style="color: #000000;background-color: #ddffdd">+first you must disable 'asdf-output-translations' with
+'(asdf:disable-output-translations)', or you might experience
</span> "interesting" issues.
<span style="color: #000000;background-color: #ffdddd">- Also, note that output translation is enabled by default. To
-disable it, use `(asdf:disable-output-translations)'.
</span><span style="color: #000000;background-color: #ddffdd">+ Also, note that output translation is enabled by default. To disable
+it, use '(asdf:disable-output-translations)'.
+
+
+File: asdf.info, Node: Output Configuration DSL, Next: Output Configuration Directories, Prev: Output Backward Compatibility, Up: Controlling where ASDF saves compiled files
</span>
<span style="color: #000000;background-color: #ffdddd">-8.3 Configuration DSL
</span><span style="color: #000000;background-color: #ddffdd">+9.3 Configuration DSL
</span> =====================
<span style="color: #000000;background-color: #ffdddd">-Here is the grammar of the SEXP DSL for `asdf-output-translations'
</span><span style="color: #000000;background-color: #ddffdd">+Here is the grammar of the SEXP DSL for 'asdf-output-translations'
</span> configuration:
;; A configuration is single SEXP starting with keyword :source-registry
<span style="color: #aaaaaa">@@ -2578,18 +3442,22 @@ DIRECTIVE :=
</span> ;; INHERITANCE DIRECTIVE:
;; Your configuration expression MUST contain
;; exactly one of either of these:
<span style="color: #000000;background-color: #ffdddd">- :inherit-configuration | ; splices inherited configuration (often specified last)
- :ignore-inherited-configuration | ; drop inherited configuration (specified anywhere)
</span><span style="color: #000000;background-color: #ddffdd">+ :inherit-configuration |
+ ;; splices inherited configuration (often specified last)
+ :ignore-inherited-configuration |
+ ;; drop inherited configuration (specified anywhere)
</span>
;; forward compatibility directive (since ASDF 2.011.4), useful when
;; you want to use new configuration features but have to bootstrap a
<span style="color: #000000;background-color: #ffdddd">- ;; the newer required ASDF from an older release that doesn't sport said features:
- :ignore-invalid-entries | ; drops subsequent invalid entries instead of erroring out
</span><span style="color: #000000;background-color: #ddffdd">+ ;; the newer required ASDF from an older release that doesn't have
+ ;; said features:
+ :ignore-invalid-entries |
</span>
;; include a configuration file or directory
(:include PATHNAME-DESIGNATOR) |
<span style="color: #000000;background-color: #ffdddd">- ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/ or something.
</span><span style="color: #000000;background-color: #ddffdd">+ ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/
+ ;; or something.
</span> :enable-user-cache |
;; Disable global cache. Map / to /
:disable-cache |
<span style="color: #aaaaaa">@@ -2601,127 +3469,146 @@ DIRECTIVE :=
</span> (DIRECTORY-DESIGNATOR (:function TRANSLATION-FUNCTION))
DIRECTORY-DESIGNATOR :=
<span style="color: #000000;background-color: #ffdddd">- NIL | ;; As source: skip this entry. As destination: same as source
- T | ;; as source matches anything, as destination leaves pathname unmapped.
- ABSOLUTE-COMPONENT-DESIGNATOR ;; same as in the source-registry language
</span><span style="color: #000000;background-color: #ddffdd">+ NIL | ; As source: skip this entry. As destination: same as source
+ T | ; as source matches anything, as destination
+ ; maps pathname to itself.
+ ABSOLUTE-COMPONENT-DESIGNATOR ; same as in the source-registry language
</span>
TRANSLATION-FUNCTION :=
<span style="color: #000000;background-color: #ffdddd">- SYMBOL | ;; symbol of a function that takes two arguments,
- ;; the pathname to be translated and the matching DIRECTORY-DESIGNATOR
- LAMBDA ;; A form which evalutates to a function taking two arguments consisting of
- ;; the pathname to be translated and the matching DIRECTORY-DESIGNATOR
</span><span style="color: #000000;background-color: #ddffdd">+ SYMBOL | ;; symbol naming a function that takes two arguments:
+ ;; the pathname to be translated and the matching
+ ;; DIRECTORY-DESIGNATOR
+ LAMBDA ;; A form which evaluates to a function taking two arguments:
+ ;; the pathname to be translated and the matching
+ ;; DIRECTORY-DESIGNATOR
+
</span>
Relative components better be either relative or subdirectories of
the path before them, or bust.
The last component, if not a pathname, is notionally completed by
<span style="color: #000000;background-color: #ffdddd">-`/**/*.*'. You can specify more fine-grained patterns by using a
</span><span style="color: #000000;background-color: #ddffdd">+'/**/*.*'. You can specify more fine-grained patterns by using a
</span> pathname object as the last component e.g.
<span style="color: #000000;background-color: #ffdddd">-`#p"some/path/**/foo*/bar-*.fasl"'
</span><span style="color: #000000;background-color: #ddffdd">+'#p"some/path/**/foo*/bar-*.fasl"'
</span>
<span style="color: #000000;background-color: #ffdddd">- You may use `#+features' to customize the configuration file.
</span><span style="color: #000000;background-color: #ddffdd">+ You may use '#+features' to customize the configuration file.
</span>
<span style="color: #000000;background-color: #ffdddd">- The second designator of a mapping may be `nil', indicating that
</span><span style="color: #000000;background-color: #ddffdd">+ The second designator of a mapping may be 'nil', indicating that
</span> files are not mapped to anything but themselves (same as if the second
designator was the same as the first).
<span style="color: #000000;background-color: #ffdddd">- When the first designator is `t', the mapping always matches. When
-the first designator starts with `:root', the mapping matches any host
</span><span style="color: #000000;background-color: #ddffdd">+ When the first designator is 't', the mapping always matches. When
+the first designator starts with ':root', the mapping matches any host
</span> and device. In either of these cases, if the second designator isn't
<span style="color: #000000;background-color: #ffdddd">-`t' and doesn't start with `:root', then strings indicating the host
-and pathname are somehow copied in the beginning of the directory
-component of the source pathname before it is translated.
-
- When the second designator is `t', the mapping is the identity.
-When the second designator starts with `:root', the mapping preserves
-the host and device of the original pathname. Notably, this allows you
-to map files to a subdirectory of the whichever directory the file is
-in. Though the syntax is not quite as easy to use as we'd like, you
-can have an (source destination) mapping entry such as follows in your
</span><span style="color: #000000;background-color: #ddffdd">+'t' and doesn't start with ':root', then strings indicating the host and
+pathname are somehow copied in the beginning of the directory component
+of the source pathname before it is translated.
+
+ When the second designator is 't', the mapping is the identity. When
+the second designator starts with ':root', the mapping preserves the
+host and device of the original pathname. Notably, this allows you to
+map files to a subdirectory of the whichever directory the file is in.
+Though the syntax is not quite as easy to use as we'd like, you can have
+an (source destination) mapping entry such as follows in your
</span> configuration file, or you may use
<span style="color: #000000;background-color: #ffdddd">-`enable-asdf-binary-locations-compatibility' with
-`:centralize-lisp-binaries nil' which will do the same thing internally
</span><span style="color: #000000;background-color: #ddffdd">+'enable-asdf-binary-locations-compatibility' with
+':centralize-lisp-binaries nil' which will do the same thing internally
</span> for you:
<span style="color: #000000;background-color: #ffdddd">- #.(let ((wild-subdir (make-pathname :directory '(:relative :wild-inferiors)))
- (wild-file (make-pathname :name :wild :version :wild :type :wild)))
- `((:root ,wild-subdir ,wild-file) ;; Or using the implicit wildcard, just :root
- (:root ,wild-subdir :implementation ,wild-file)))
- Starting with ASDF 2.011.4, you can use the simpler: ``(:root (:root
</span><span style="color: #000000;background-color: #ddffdd">+ #.(let ((wild-subdir
+ (make-pathname :directory '(:relative :wild-inferiors)))
+ (wild-file
+ (make-pathname :name :wild :version :wild :type :wild)))
+ `((:root ,wild-subdir ,wild-file)
+ (:root ,wild-subdir :implementation ,wild-file)))
+ Starting with ASDF 2.011.4, you can use the simpler: '`(:root (:root
</span> :**/ :implementation :*.*.*))'
<span style="color: #000000;background-color: #ffdddd">- `:include' statements cause the search to recurse with the path
</span><span style="color: #000000;background-color: #ddffdd">+ ':include' statements cause the search to recurse with the path
</span> specifications from the file specified.
<span style="color: #000000;background-color: #ffdddd">- If the `translate-pathname' mechanism cannot achieve a desired
-translation, the user may provide a function which provides the
-required algorithim. Such a translation function is specified by
-supplying a list as the second `directory-designator' the first element
-of which is the keyword `:function', and the second element of which is
-either a symbol which designates a function or a lambda expression.
-The function designated by the second argument must take two arguments,
-the first being the pathname of the source file, the second being the
-wildcard that was matched. The result of the function invocation
-should be the translated pathname.
-
- An `:inherit-configuration' statement cause the search to recurse
-with the path specifications from the next configuration. *Note
-Configurations: Controlling where ASDF saves compiled files, above.
-
- * `:enable-user-cache' is the same as `(t :user-cache)'.
-
- * `:disable-cache' is the same as `(t t)'.
-
- * `:user-cache' uses the contents of variable `asdf::*user-cache*'
- which by default is the same as using `(:home ".cache"
</span><span style="color: #000000;background-color: #ddffdd">+ If the 'translate-pathname' mechanism cannot achieve a desired
+translation, the user may provide a function which provides the required
+algorithm. Such a translation function is specified by supplying a list
+as the second 'directory-designator' the first element of which is the
+keyword ':function', and the second element of which is either a symbol
+which designates a function or a lambda expression. The function
+designated by the second argument must take two arguments, the first
+being the pathname of the source file, the second being the wildcard
+that was matched. When invoked, the function should return the
+translated pathname.
+
+ An ':inherit-configuration' statement causes the search to recurse
+with the path specifications from the next configuration in the bulleted
+list. *Note Configurations: Controlling where ASDF saves compiled
+files, above.
+
+ * ':enable-user-cache' is the same as '(t :user-cache)'.
+ * ':disable-cache' is the same as '(t t)'.
+ * ':user-cache' uses the contents of variable 'asdf::*user-cache*'
+ which by default is the same as using '(:home ".cache"
</span> "common-lisp" :implementation)'.
<span style="color: #000000;background-color: #ffdddd">- * `:system-cache' uses the contents of variable
- `asdf::*system-cache*' which by default is the same as using
- `("/var/cache/common-lisp" :uid :implementation-type)' (on Unix
- and cygwin), or something semi-sensible on Windows.
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Output Configuration Directories, Next: Output Shell-friendly syntax for configuration, Prev: Output Configuration DSL, Up: Controlling where ASDF saves compiled files
</span>
<span style="color: #000000;background-color: #ffdddd">-8.4 Configuration Directories
</span><span style="color: #000000;background-color: #ddffdd">+9.4 Configuration Directories
</span> =============================
<span style="color: #000000;background-color: #ffdddd">-Configuration directories consist in files each contains a list of
-directives without any enclosing `(:output-translations ...)' form.
-The files will be sorted by namestring as if by `string<' and the lists
-of directives of these files with be concatenated in order. An
-implicit `:inherit-configuration' will be included at the _end_ of the
</span><span style="color: #000000;background-color: #ddffdd">+Configuration directories consist of files, each of which contains a
+list of directives without any enclosing '(:output-translations ...)'
+form. The files will be sorted by namestring as if by 'string<' and the
+lists of directives of these files with be concatenated in order. An
+implicit ':inherit-configuration' will be included at the _end_ of the
</span> list.
<span style="color: #000000;background-color: #ffdddd">- This allows for packaging software that has file granularity (e.g.
-Debian's `dpkg' or some future version of `clbuild') to easily include
-configuration information about software being distributed.
</span><span style="color: #000000;background-color: #ddffdd">+ System-wide or per-user Common Lisp software distributions such as
+Debian packages or some future version of 'clbuild' may then include
+files such as
+'/etc/common-lisp/asdf-output-translations.conf.d/10-foo.conf' or
+'~/.config/common-lisp/asdf-output-translations.conf.d/10-foo.conf' to
+easily and modularly register configuration information about software
+being distributed.
</span>
The convention is that, for sorting purposes, the names of files in
<span style="color: #000000;background-color: #ffdddd">-such a directory begin with two digits that determine the order in
-which these entries will be read. Also, the type of these files is
-conventionally `"conf"' and as a limitation of some implementations,
-the type cannot be `nil'.
</span><span style="color: #000000;background-color: #ddffdd">+such a directory begin with two digits that determine the order in which
+these entries will be read. Also, the type of these files must be
+'.conf', which not only simplifies the implementation by allowing for
+more portable techniques in finding those files, but also makes it
+trivial to disable a file, by renaming it to a different file type.
</span>
Directories may be included by specifying a directory pathname or
<span style="color: #000000;background-color: #ffdddd">-namestring in an `:include' directive, e.g.:
</span><span style="color: #000000;background-color: #ddffdd">+namestring in an ':include' directive, e.g.:
+
</span> (:include "/foo/bar/")
<span style="color: #000000;background-color: #ffdddd">-8.5 Shell-friendly syntax for configuration
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Output Shell-friendly syntax for configuration, Next: Semantics of Output Translations, Prev: Output Configuration Directories, Up: Controlling where ASDF saves compiled files
+
+9.5 Shell-friendly syntax for configuration
</span> ===========================================
<span style="color: #000000;background-color: #ffdddd">-When considering environment variable `ASDF_OUTPUT_TRANSLATIONS' ASDF
-will skip to next configuration if it's an empty string. It will
-`READ' the string as an SEXP in the DSL if it begins with a paren `('
-and it will be interpreted as a list of directories. Directories
-should come by pairs, indicating a mapping directive. Entries are
-separated by a `:' (colon) on Unix platforms (including cygwin), by a
-`;' (semicolon) on other platforms (mainly, Windows).
</span><span style="color: #000000;background-color: #ddffdd">+When considering environment variable 'ASDF_OUTPUT_TRANSLATIONS' ASDF
+will skip to the next configuration if it's an empty string. It will
+'READ' the string as an SEXP in the DSL if it begins with a paren '('
+and it will be interpreted as a list of directories. Directories should
+come by pairs, indicating a mapping directive. Entries are separated by
+a ':' (colon) on Unix platforms (including cygwin), by a ';' (semicolon)
+on other platforms (mainly, Windows).
</span>
The magic empty entry, if it comes in what would otherwise be the
first entry in a pair, indicates the splicing of inherited
configuration. If it comes as the second entry in a pair, it indicates
<span style="color: #000000;background-color: #ffdddd">-that the directory specified first is to be left untranslated (which
-has the same effect as if the directory had been repeated).
</span><span style="color: #000000;background-color: #ddffdd">+that the directory specified first is to be left untranslated (which has
+the same effect as if the directory had been repeated). Thus
+'"/foo:/bar::/baz:"' means that things under directory '/foo/' are
+translated to be under '/bar/', then include the inherited
+configuration, then specify that things under directory '/baz/' are not
+translated.
+
+
+File: asdf.info, Node: Semantics of Output Translations, Next: Output Caching Results, Prev: Output Shell-friendly syntax for configuration, Up: Controlling where ASDF saves compiled files
</span>
<span style="color: #000000;background-color: #ffdddd">-8.6 Semantics of Output Translations
</span><span style="color: #000000;background-color: #ddffdd">+9.6 Semantics of Output Translations
</span> ====================================
From the specified configuration, a list of mappings is extracted in a
<span style="color: #aaaaaa">@@ -2735,9 +3622,9 @@ entry, in order, resolve the first designated directory into an actual
</span> directory pathname for source locations. If no mapping was specified
yet for that location, resolve the second designated directory to an
output location directory add a mapping to the table mapping the source
<span style="color: #000000;background-color: #ffdddd">-location to the output location, and add another mapping from the
-output location to itself (unless a mapping already exists for the
-output location).
</span><span style="color: #000000;background-color: #ddffdd">+location to the output location, and add another mapping from the output
+location to itself (unless a mapping already exists for the output
+location).
</span>
Based on the table, a mapping function is defined, mapping source
pathnames to output pathnames: given a source pathname, locate the
<span style="color: #aaaaaa">@@ -2748,7 +3635,10 @@ source pathname. (A global default mapping the filesystem root to
</span> itself may ensure that there will always be a match, with same
fall-through semantics).
<span style="color: #000000;background-color: #ffdddd">-8.7 Caching Results
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Output Caching Results, Next: Output location API, Prev: Semantics of Output Translations, Up: Controlling where ASDF saves compiled files
+
+9.7 Caching Results
</span> ===================
The implementation is allowed to either eagerly compute the information
<span style="color: #aaaaaa">@@ -2756,59 +3646,63 @@ from the configurations and file system, or to lazily re-compute it
</span> every time, or to cache any part of it as it goes. To explicitly flush
any information cached by the system, use the API below.
<span style="color: #000000;background-color: #ffdddd">-8.8 Output location API
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Output location API, Next: Credits for output translations, Prev: Output Caching Results, Up: Controlling where ASDF saves compiled files
+
+9.8 Output location API
</span> =======================
The specified functions are exported from package ASDF.
-- Function: initialize-output-translations &optional PARAMETER
will read the configuration and initialize all internal variables.
<span style="color: #000000;background-color: #ffdddd">- You may extend or override configuration from the environment
- and configuration files with the given PARAMETER, which can be
- `nil' (no configuration override), or a SEXP (in the SEXP DSL),
- a string (as in the string DSL), a pathname (of a file or
- directory with configuration), or a symbol (fbound to function
- that when called returns one of the above).
</span><span style="color: #000000;background-color: #ddffdd">+ You may extend or override configuration from the environment and
+ configuration files with the given PARAMETER, which can be 'nil'
+ (no configuration override), or a SEXP (in the SEXP DSL), a string
+ (as in the string DSL), a pathname (of a file or directory with
+ configuration), or a symbol (fbound to function that when called
+ returns one of the above).
</span>
-- Function: disable-output-translations
<span style="color: #000000;background-color: #ffdddd">- will initialize output translations in a way that maps every
- pathname to itself, effectively disabling the output
- translation facility.
</span><span style="color: #000000;background-color: #ddffdd">+ will initialize output translations in a way that maps every
+ pathname to itself, effectively disabling the output translation
+ facility.
</span>
-- Function: clear-output-translations
<span style="color: #000000;background-color: #ffdddd">- undoes any output translation configuration and clears any
- cache for the mapping algorithm. You might want to call this
- function (or better, `clear-configuration') before you dump
- an image that would be resumed with a different configuration,
- and return an empty configuration. Note that this does not
- include clearing information about systems defined in the
- current image, only about where to look for systems not yet
- defined.
</span><span style="color: #000000;background-color: #ddffdd">+ undoes any output translation configuration and clears any cache
+ for the mapping algorithm. You might want to call this function
+ (or better, 'clear-configuration') before you dump an image that
+ would be resumed with a different configuration, and return an
+ empty configuration. Note that this does not include clearing
+ information about systems defined in the current image, only about
+ where to look for systems not yet defined.
</span>
-- Function: ensure-output-translations &optional PARAMETER
<span style="color: #000000;background-color: #ffdddd">- checks whether output translations have been initialized. If
- not, initialize them with the given PARAMETER. This function
- will be called before any attempt to operate on a system.
</span><span style="color: #000000;background-color: #ddffdd">+ checks whether output translations have been initialized. If not,
+ initialize them with the given PARAMETER. This function will be
+ called before any attempt to operate on a system.
</span>
-- Function: apply-output-translations PATHNAME
Applies the configured output location translations to PATHNAME
<span style="color: #000000;background-color: #ffdddd">- (calls `ensure-output-translations' for the translations).
-
- Every time you use ASDF's `output-files', or anything that uses it
-(that may compile, such as `operate', `perform', etc.),
-`ensure-output-translations' is called with parameter `nil', which the
-first time around causes your configuration to be read. If you change
-a configuration file, you need to explicitly
-`initialize-output-translations' again, or maybe
-`clear-output-translations' (or `clear-configuration'), which will
-cause the initialization to happen next time around.
-
-8.9 Credits for output translations
</span><span style="color: #000000;background-color: #ddffdd">+ (calls 'ensure-output-translations' for the translations).
+
+ Every time you use ASDF's 'output-files', or anything that uses it
+(that may compile, such as 'operate', 'perform', etc.),
+'ensure-output-translations' is called with parameter 'nil', which the
+first time around causes your configuration to be read. If you change a
+configuration file, you need to explicitly
+'initialize-output-translations' again, or maybe
+'clear-output-translations' (or 'clear-configuration'), which will cause
+the initialization to happen next time around.
+
+
+File: asdf.info, Node: Credits for output translations, Prev: Output location API, Up: Controlling where ASDF saves compiled files
+
+9.9 Credits for output translations
</span> ===================================
<span style="color: #000000;background-color: #ffdddd">-Thanks a lot to Bjorn Lindberg and Gary King for
-`ASDF-Binary-Locations', and to Peter van Eynde for `Common Lisp
-Controller'.
</span><span style="color: #000000;background-color: #ddffdd">+Thanks a lot to Peter van Eynde for 'Common Lisp Controller' and to
+Bjorn Lindberg and Gary King for 'ASDF-Binary-Locations'.
</span>
All bad design ideas and implementation bugs are to mine, not theirs.
But so are good design ideas and elegant implementation tricks.
<span style="color: #aaaaaa">@@ -2818,72 +3712,82 @@ But so are good design ideas and elegant implementation tricks.
</span>
File: asdf.info, Node: Error handling, Next: Miscellaneous additional functionality, Prev: Controlling where ASDF saves compiled files, Up: Top
<span style="color: #000000;background-color: #ffdddd">-9 Error handling
-****************
</span><span style="color: #000000;background-color: #ddffdd">+10 Error handling
+*****************
</span>
<span style="color: #000000;background-color: #ffdddd">-9.1 ASDF errors
-===============
</span><span style="color: #000000;background-color: #ddffdd">+10.1 ASDF errors
+================
</span>
If ASDF detects an incorrect system definition, it will signal a
<span style="color: #000000;background-color: #ffdddd">-generalised instance of `SYSTEM-DEFINITION-ERROR'.
</span><span style="color: #000000;background-color: #ddffdd">+generalised instance of 'SYSTEM-DEFINITION-ERROR'.
</span>
Operations may go wrong (for example when source files contain
errors). These are signalled using generalised instances of
<span style="color: #000000;background-color: #ffdddd">-`OPERATION-ERROR'.
</span><span style="color: #000000;background-color: #ddffdd">+'OPERATION-ERROR'.
</span>
<span style="color: #000000;background-color: #ffdddd">-9.2 Compilation error and warning handling
-==========================================
</span><span style="color: #000000;background-color: #ddffdd">+10.2 Compilation error and warning handling
+===========================================
</span>
ASDF checks for warnings and errors when a file is compiled. The
variables *COMPILE-FILE-WARNINGS-BEHAVIOUR* and
<span style="color: #000000;background-color: #ffdddd">-*COMPILE-FILE-ERRORS-BEHAVIOR* control the handling of any such events.
-The valid values for these variables are `:error', `:warn', and
-`:ignore'.
</span><span style="color: #000000;background-color: #ddffdd">+*COMPILE-FILE-FAILURE-BEHAVIOUR* control the handling of any such
+events. The valid values for these variables are ':error', ':warn', and
+':ignore'.
</span>
File: asdf.info, Node: Miscellaneous additional functionality, Next: Getting the latest version, Prev: Error handling, Up: Top
<span style="color: #000000;background-color: #ffdddd">-10 Miscellaneous additional functionality
</span><span style="color: #000000;background-color: #ddffdd">+11 Miscellaneous additional functionality
</span> *****************************************
ASDF includes several additional features that are generally useful for
system definition and development.
<span style="color: #000000;background-color: #ffdddd">-10.1 Controlling file compilation
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* Controlling file compilation::
+* Controlling source file character encoding::
+* Miscellaneous Functions::
+* Some Utility Functions::
+
+
+File: asdf.info, Node: Controlling file compilation, Next: Controlling source file character encoding, Prev: Miscellaneous additional functionality, Up: Miscellaneous additional functionality
+
+11.1 Controlling file compilation
</span> =================================
When declaring a component (system, module, file), you can specify a
<span style="color: #000000;background-color: #ffdddd">-keyword argument `:around-compile function'. If left unspecified (and
</span><span style="color: #000000;background-color: #ddffdd">+keyword argument ':around-compile function'. If left unspecified (and
</span> therefore unbound), the value will be inherited from the parent
<span style="color: #000000;background-color: #ffdddd">-component if any, or with a default of `nil' if no value is specified
-in any transitive parent.
-
- The argument must be a either `nil', a fbound symbol, a
-lambda-expression (e.g. `(lambda (thunk) ...(funcall thunk ...) ...)')
-a function object (e.g. using `#.#'' but that's discouraged because it
-prevents the introspection done by e.g. asdf-dependency-grovel), or a
-string that when `read' yields a symbol or a lambda-expression. `nil'
</span><span style="color: #000000;background-color: #ddffdd">+component if any, or with a default of 'nil' if no value is specified in
+any transitive parent.
+
+ The argument must be either 'nil', an fbound symbol, a
+lambda-expression (e.g. '(lambda (thunk) ...(funcall thunk ...) ...)')
+a function object (e.g. using '#.#'' but that's discouraged because it
+prevents the introspection done by e.g. asdf-dependency-grovel), or a
+string that when 'read' yields a symbol or a lambda-expression. 'nil'
</span> means the normal compile-file function will be called. A non-nil value
designates a function of one argument that will be called with a
<span style="color: #000000;background-color: #ffdddd">-function that will invoke `compile-file*' with various arguments; the
</span><span style="color: #000000;background-color: #ddffdd">+function that will invoke 'compile-file*' with various arguments; the
</span> around-compile hook may supply additional keyword arguments to pass to
<span style="color: #000000;background-color: #ffdddd">-that call to `compile-file*'.
-
- One notable argument that is heeded by `compile-file*' is
-`:compile-check', a function called when the compilation was otherwise
-a success, with the same arguments as `compile-file'; the function
-shall return true if the compilation and its resulting compiled file
-respected all system-specific invariants, and false (`nil') if it broke
-any of those invariants; it may issue warnings or errors before it
-returns `nil'. (NB: The ability to pass such extra flags is only
-available starting with ASDF 2.22.3.) This feature is notably
-exercised by asdf-finalizers.
</span><span style="color: #000000;background-color: #ddffdd">+that call to 'compile-file*'.
+
+ One notable argument that is heeded by 'compile-file*' is
+':compile-check', a function called when the compilation was otherwise a
+success, with the same arguments as 'compile-file'; the function shall
+return true if the compilation and its resulting compiled file respected
+all system-specific invariants, and false ('nil') if it broke any of
+those invariants; it may issue warnings or errors before it returns
+'nil'. (NB: The ability to pass such extra flags is only available
+starting with ASDF 2.22.3.) This feature is notably exercised by
+asdf-finalizers.
</span>
By using a string, you may reference a function, symbol and/or
package that will only be created later during the build, but isn't yet
present at the time the defsystem form is evaluated. However, if your
entire system is using such a hook, you may have to explicitly override
<span style="color: #000000;background-color: #ffdddd">-the hook with `nil' for all the modules and files that are compiled
</span><span style="color: #000000;background-color: #ddffdd">+the hook with 'nil' for all the modules and files that are compiled
</span> before the hook is defined.
Using this hook, you may achieve such effects as: locally renaming
<span style="color: #aaaaaa">@@ -2895,223 +3799,257 @@ seeds and other sources of non-determinism, overriding the
</span> source-location and/or timestamping systems, checking that some
compile-time side-effects were properly balanced, etc.
<span style="color: #000000;background-color: #ffdddd">- Note that there is no around-load hook. This is on purpose. Some
-implementations such as ECL, GCL or MKCL link object files, which
-allows for no such hook. Other implementations allow for concatenating
-FASL files, which doesn't allow for such a hook either. We aim to
-discourage something that's not portable, and has some dubious impact
-on performance and semantics even when it is possible. Things you
-might want to do with an around-load hook are better done
-around-compile, though it may at times require some creativity (see
-e.g. the `package-renaming' system).
-
-10.2 Controlling source file character encoding
</span><span style="color: #000000;background-color: #ddffdd">+ Note that there is no around-load hook. This is on purpose. Some
+implementations such as ECL, GCL or MKCL link object files, which allows
+for no such hook. Other implementations allow for concatenating FASL
+files, which doesn't allow for such a hook either. We aim to discourage
+something that's not portable, and has some dubious impact on
+performance and semantics even when it is possible. Things you might
+want to do with an around-load hook are better done around-compile,
+though it may at times require some creativity (see e.g. the
+'package-renaming' system).
+
+
+File: asdf.info, Node: Controlling source file character encoding, Next: Miscellaneous Functions, Prev: Controlling file compilation, Up: Miscellaneous additional functionality
+
+11.2 Controlling source file character encoding
</span> ===============================================
<span style="color: #000000;background-color: #ffdddd">-Starting with ASDF 2.21, components accept a `:encoding' option so
</span><span style="color: #000000;background-color: #ddffdd">+Starting with ASDF 2.21, components accept a ':encoding' option so
</span> authors may specify which character encoding should be used to read and
evaluate their source code. When left unspecified, the encoding is
inherited from the parent module or system; if no encoding is specified
<span style="color: #000000;background-color: #ffdddd">-at any point, the default `:autodetect' is assumed. By default, only
-`:default', `:utf-8' and `:autodetect' are accepted. `:autodetect',
-the default, calls `*encoding-detection-hook*' which by default always
-returns `*default-encoding*' which itself defaults to `:default'.
</span><span style="color: #000000;background-color: #ddffdd">+at any point, or if 'nil' is explicitly specified, an extensible
+protocol described below is followed, that ultimately defaults to
+':utf-8' since ASDF 3.
+
+ The protocol to determine the encoding is to call the function
+'detect-encoding', which itself, if provided a valid file, calls the
+function specified by *ENCODING-DETECTION-HOOK*, or else defaults to the
+*DEFAULT-ENCODING*. The *ENCODING-DETECTION-HOOK* is by default bound
+to function 'always-default-encoding', that always returns the contents
+of *DEFAULT-ENCODING*. *DEFAULT-ENCODING* is bound to ':utf-8' by
+default (before ASDF 3, the default was ':default').
+
+ Whichever encoding is returned must be a portable keyword, that will
+be translated to an implementation-specific external-format designator
+by function 'encoding-external-format', which itself simply calls the
+function specified *ENCODING-EXTERNAL-FORMAT-HOOK*; that function by
+default is 'default-encoding-external-format', that only recognizes
+':utf-8' and ':default', and translates the former to the
+implementation-dependent *UTF-8-EXTERNAL-FORMAT*, and the latter to
+itself (that itself is portable but has an implementation-dependent
+meaning).
</span>
In other words, there now are plenty of extension hooks, but by
<span style="color: #000000;background-color: #ffdddd">-default ASDF follows the backwards compatible behavior of using
-whichever `:default' encoding your implementation uses, which itself
-may or may not vary based on environment variables and other locale
-settings. In practice this means that only source code that only uses
-ASCII is guaranteed to be read the same on all implementations
-independently from any user setting.
-
- Additionally, for backward-compatibility with older versions of ASDF
-and/or with implementations that do not support unicode and its many
-encodings, you may want to use the reader conditionals `#+asdf-unicode
-#+asdf-unicode' to protect any `:encoding _encoding_' statement as
-`:asdf-unicode' will be present in `*features*' only if you're using a
-recent ASDF on an implementation that supports unicode. We recommend
-that you avoid using unprotected `:encoding' specifications until after
-ASDF 2.21 or later becomes widespread, hopefully by the end of 2012.
-
- While it offers plenty of hooks for extension, and one such
-extension is being developed (see below), ASDF itself only recognizes
-one encoding beside `:default', and that is `:utf-8', which is the _de
-facto_ standard, already used by the vast majority of libraries that
-use more than ASCII. On implementations that do not support unicode,
-the feature `:asdf-unicode' is absent, and the `:default'
-external-format is used to read even source files declared as `:utf-8'.
-On these implementations, non-ASCII characters intended to be read as
-one CL character may thus end up being read as multiple CL characters.
-In most cases, this shouldn't affect the software's semantics: comments
-will be skipped just the same, strings with be read and printed with
-slightly different lengths, symbol names will be accordingly longer,
-but none of it should matter. But a few systems that actually depend
-on unicode characters may fail to work properly, or may work in a
-subtly different way. See for instance `lambda-reader'.
</span><span style="color: #000000;background-color: #ddffdd">+default ASDF enforces the previous _de facto_ standard behaviour of
+using ':utf-8', independently from whatever configuration the user may
+be using. Thus, system authors can now rely on ':utf-8' being used
+while compiling their files, even if the user is currently using
+':koi8-r' or ':euc-jp' as their interactive encoding. (Before ASDF 3,
+there was no such guarantee, ':default' was used, and only plain ASCII
+was safe to include in source code.)
+
+ Some legacy implementations only support 8-bit characters, and some
+implementations provide 8-bit only variants. On these implementations,
+the *UTF-8-EXTERNAL-FORMAT* gracefully falls back to ':default', and
+Unicode characters will be read as multi-character mojibake. To detect
+such situations, UIOP will push the ':asdf-unicode' feature on
+implementations that support Unicode, and you can use
+reader-conditionalization to protect any ':encoding _encoding_'
+statement, as in '#+asdf-unicode :encoding #+asdf-unicode :utf-8'. We
+recommend that you avoid using unprotected ':encoding' specifications
+until after ASDF 2.21 or later becomes widespread. As of May 2015, all
+maintained implementations provide ASDF 3, so you may prudently start
+using this and other features without such protection.
+
+ While it offers plenty of hooks for extension, and one such extension
+is available (see 'asdf-encodings' below), ASDF itself only recognizes
+one encoding beside ':default', and that is ':utf-8', which is the _de
+facto_ standard, already used by the vast majority of libraries that use
+more than ASCII. On implementations that do not support unicode, the
+feature ':asdf-unicode' is absent, and the ':default' external-format is
+used to read even source files declared as ':utf-8'. On these
+implementations, non-ASCII characters intended to be read as one CL
+character may thus end up being read as multiple CL characters. In most
+cases, this shouldn't affect the software's semantics: comments will be
+skipped just the same, strings with be read and printed with slightly
+different lengths, symbol names will be accordingly longer, but none of
+it should matter. But a few systems that actually depend on unicode
+characters may fail to work properly, or may work in a subtly different
+way. See for instance 'lambda-reader'.
</span>
We invite you to embrace UTF-8 as the encoding for non-ASCII
characters starting today, even without any explicit specification in
<span style="color: #000000;background-color: #ffdddd">-your `.asd' files. Indeed, on some implementations and configurations,
-UTF-8 is already the `:default', and loading your code may cause errors
-if it is encoded in anything but UTF-8. Therefore, even with the
-legacy behavior, non-UTF-8 is guaranteed to break for some users,
-whereas UTF-8 is pretty much guaranteed not to break anywhere (provided
-you do _not_ use a BOM), although it might be read incorrectly on some
-implementations. In the future, we intend to make `:utf-8' the default
-value of `*default-encoding*', to be enforced everywhere, so at least
-the code is guaranteed to be read correctly everywhere it can be.
</span><span style="color: #000000;background-color: #ddffdd">+your '.asd' files. Indeed, on some implementations and configurations,
+UTF-8 is already the ':default', and loading your code may cause errors
+if it is encoded in anything but UTF-8. Therefore, even with the legacy
+behaviour, non-UTF-8 is guaranteed to break for some users, whereas
+UTF-8 is pretty much guaranteed not to break anywhere (provided you do
+_not_ use a BOM), although it might be read incorrectly on some
+implementations. ':utf-8' has been the default value of
+'*default-encoding*' since ASDF 3.
</span>
If you need non-standard character encodings for your source code,
<span style="color: #000000;background-color: #ffdddd">-use the extension system `asdf-encodings', by specifying
-`:defsystem-depends-on (:asdf-encodings)' in your `defsystem'. This
</span><span style="color: #000000;background-color: #ddffdd">+use the extension system 'asdf-encodings', by specifying
+':defsystem-depends-on ("asdf-encodings")' in your 'defsystem'. This
</span> extension system will register support for more encodings using the
<span style="color: #000000;background-color: #ffdddd">-`*encoding-external-format-hook*' facility, so you can explicitly
-specify `:encoding :latin1' in your `.asd' file. Using the
-`*encoding-detection-hook*' it will also eventually implement some
-autodetection of a file's encoding from an emacs-style `-*- mode: lisp
-; coding: latin1 -*-' declaration, or otherwise based on an analysis of
-octet patterns in the file. At this point, asdf-encoding only supports
-the encodings that are supported as part of your implementation. Since
-the list varies depending on implementations, we once again recommend
-you use `:utf-8' everywhere, which is the most portable (next is
-`:latin1').
-
- If you're not using a version of Quicklisp that has it, you may get
-the source for `asdf-encodings' using git: `git clone
-git://common-lisp.net/projects/asdf/asdf-encodings.git' or `git clone
-ssh://common-lisp.net/project/asdf/git/asdf-encodings.git'. You can
-also browse the repository on
-`http://common-lisp.net/gitweb?p=projects/asdf/asdf-encodings.git'.
-
- In the future, we intend to change the default `*default-encoding*'
-to `:utf-8', which is already the de facto standard for most libraries
-that use non-ASCII characters: utf-8 works everywhere and was
-backhandedly enforced by a lot of people using SBCL and utf-8 and
-sending reports to authors so they make their packages compatible. A
-survey showed only about a handful few libraries are incompatible with
-non-UTF-8, and then, only in comments, and we believe that authors will
-adopt UTF-8 when prompted. See the April 2012 discussion on the
-asdf-devel mailing-list. For backwards compatibility with users who
-insist on a non-UTF-8 encoding, but cannot immediately transition to
-using `asdf-encodings' (maybe because it isn't ready), it will still be
-possible to use the `:encoding :default' option in your `defsystem' form
-to restore the behavior of ASDF 2.20 and earlier. This shouldn't be
-required in libraries, because user pressure as mentioned above will
-already have pushed library authors towards using UTF-8; but authors of
-end-user programs might care.
-
- When you use `asdf-encodings', any further loaded `.asd' file will
-use the autodetection algorithm to determine its encoding; yet if you
-depend on this detection happening, you may want to explicitly load
-`asdf-encodings' early in your build, for by the time you can use
-`:defsystem-depends-on', it is already too late to load it. In
-practice, this means that the `*default-encoding*' is usually used for
-`.asd' files. Currently, this defaults to `:default' for backwards
-compatibility, and that means that you shouldn't rely on non-ASCII
-characters in a .asd file. Since component (path)names are the only
-real data in these files, and non-ASCII characters are not very
-portable for file names, this isn't too much of an issue. We still
-encourage you to use either plain ASCII or UTF-8 in `.asd' files, as we
-intend to make `:utf-8' the default encoding in the future. This might
-matter, for instance, in meta-data about author's names.
-
-10.3 Miscellaneous Functions
</span><span style="color: #000000;background-color: #ddffdd">+'*encoding-external-format-hook*' facility, so you can explicitly
+specify ':encoding :latin1' in your '.asd' file. Using the
+'*encoding-detection-hook*' it will also eventually implement some
+autodetection of a file's encoding from an emacs-style '-*- mode: lisp ;
+coding: latin1 -*-' declaration, or otherwise based on an analysis of
+octet patterns in the file. At this point, 'asdf-encoding' only
+supports the encodings that are supported as part of your
+implementation. Since the list varies depending on implementations, we
+still recommend you use ':utf-8' everywhere, which is the most portable
+(next to it is ':latin1').
+
+ Recent versions of Quicklisp include 'asdf-encodings'; if you're not
+using it, you may get this extension using git: 'git clone
+https://gitlab.common-lisp.net/asdf/asdf-encodings.git' or 'git clone
+git@gitlab.common-lisp.net:asdf/asdf-encodings.git'. You can also
+browse the repository on
+<https://gitlab.common-lisp.net/asdf/asdf-encodings>.
+
+ When you use 'asdf-encodings', any '.asd' file loaded will use the
+autodetection algorithm to determine its encoding. If you depend on
+this detection happening, you should explicitly load 'asdf-encodings'
+early in your build. Note that ':defsystem-depends-on' cannot be used
+here: by the time the ':defsystem-depends-on' is loaded, the enclosing
+'defsystem' form has already been read.
+
+ In practice, this means that the '*default-encoding*' is usually used
+for '.asd' files. Currently, this defaults to ':utf-8', and you should
+be safe using Unicode characters in those files. This might matter, for
+instance, in meta-data about author's names. Otherwise, the main data
+in these files is component (path)names, and we don't recommend using
+non-ASCII characters for these, for the result probably isn't very
+portable.
+
+
+File: asdf.info, Node: Miscellaneous Functions, Next: Some Utility Functions, Prev: Controlling source file character encoding, Up: Miscellaneous additional functionality
+
+11.3 Miscellaneous Functions
</span> ============================
These functions are exported by ASDF for your convenience.
-- Function: system-relative-pathname system name &key type
<span style="color: #000000;background-color: #ddffdd">+
</span> It's often handy to locate a file relative to some system. The
<span style="color: #000000;background-color: #ffdddd">- `system-relative-pathname' function meets this need.
</span><span style="color: #000000;background-color: #ddffdd">+ 'system-relative-pathname' function meets this need.
</span>
It takes two mandatory arguments SYSTEM and NAME and a keyword
argument TYPE: SYSTEM is name of a system, whereas NAME and
optionally TYPE specify a relative pathname, interpreted like a
<span style="color: #000000;background-color: #ffdddd">- component pathname specifier by `coerce-pathname'. *Note Pathname
</span><span style="color: #000000;background-color: #ddffdd">+ component pathname specifier by 'coerce-pathname'. *Note Pathname
</span> specifiers: The defsystem grammar.
It returns a pathname built from the location of the system's
<span style="color: #000000;background-color: #ffdddd">- source directory and the relative pathname. For example:
</span><span style="color: #000000;background-color: #ddffdd">+ source directory and the relative pathname. For example:
</span>
> (asdf:system-relative-pathname 'cl-ppcre "regex.data")
#P"/repository/other/cl-ppcre/regex.data"
<span style="color: #000000;background-color: #ffdddd">-
</span> -- Function: system-source-directory system-designator
<span style="color: #000000;background-color: #ddffdd">+
</span> ASDF does not provide a turnkey solution for locating data (or
other miscellaneous) files that are distributed together with the
source code of a system. Programmers can use
<span style="color: #000000;background-color: #ffdddd">- `system-source-directory' to find such files. Returns a pathname
</span><span style="color: #000000;background-color: #ddffdd">+ 'system-source-directory' to find such files. Returns a pathname
</span> object. The SYSTEM-DESIGNATOR may be a string, symbol, or ASDF
system object.
-- Function: clear-system system-designator
<span style="color: #000000;background-color: #ddffdd">+
</span> It is sometimes useful to force recompilation of a previously
<span style="color: #000000;background-color: #ffdddd">- loaded system. In these cases, it may be useful to
- `(asdf:clear-system :foo)' to remove the system from the table of
- currently loaded systems; the next time the system `foo' or one
- that depends on it is re-loaded, `foo' will then be loaded again.
- Alternatively, you could touch `foo.asd' or remove the
- corresponding fasls from the output file cache. (It was once
- conceived that one should provide a list of systems the
- recompilation of which to force as the `:force' keyword argument
- to `load-system'; but this has never worked, and though the
- feature was fixed in ASDF 2.000, it remains `cerror''ed out as
- nobody ever used it.)
-
- Note that this does not and cannot by itself undo the previous
- loading of the system. Common Lisp has no provision for such an
- operation, and its reliance on irreversible side-effects to global
- datastructures makes such a thing impossible in the general case.
- If the software being re-loaded is not conceived with hot upgrade
- in mind, this re-loading may cause many errors, warnings or subtle
- silent problems, as packages, generic function signatures,
- structures, types, macros, constants, etc. are being redefined
- incompatibly. It is up to the user to make sure that reloading is
- possible and has the desired effect. In some cases, extreme
- measures such as recursively deleting packages, unregistering
- symbols, defining methods on `update-instance-for-redefined-class'
- and much more are necessary for reloading to happen smoothly.
- ASDF itself goes through notable pains to make such a hot upgrade
- possible with respect to its own code, and what it does is
- ridiculously complex; look at the beginning of `asdf.lisp' to see
- what it does.
</span><span style="color: #000000;background-color: #ddffdd">+ loaded system. For these cases, '(asdf:clear-system :foo)' will
+ remove the system from the table of currently loaded systems: the
+ next time the system 'foo' or one that depends on it is re-loaded,
+ 'foo' will be loaded again.(1)
+
+ Note that this does not and cannot undo the previous loading of the
+ system. Common Lisp has no provision for such an operation, and
+ its reliance on irreversible side-effects to global data structures
+ makes such a thing impossible in the general case. If the software
+ being re-loaded is not conceived with hot upgrade in mind,
+ re-loading may cause many errors, warnings or subtle silent
+ problems, as packages, generic function signatures, structures,
+ types, macros, constants, etc. are being redefined incompatibly.
+ It is up to the user to make sure that reloading is possible and
+ has the desired effect. In some cases, extreme measures such as
+ recursively deleting packages, unregistering symbols, defining
+ methods on 'update-instance-for-redefined-class' and much more are
+ necessary for reloading to happen smoothly. ASDF itself goes to
+ extensive effort to make a hot upgrade possible with respect to its
+ own code. If you want, you can reuse some of its utilities such as
+ 'uiop:define-package' and 'uiop:with-upgradability', and get
+ inspiration (or disinspiration) from what it does in 'header.lisp'
+ and 'upgrade.lisp'.
</span>
-- Function: register-preloaded-system name &rest keys
<span style="color: #000000;background-color: #ffdddd">- A system with name NAME, created by `make-instance' with extra
- keys KEYS (e.g. `:version'), is registered as _preloaded_. That
- is, its code has already been loaded into the current image, and
- if at some point some other system `:depends-on' it yet no source
- code is found, it is considered as already provided, and ASDF will
- not raise a `missing-component' error.
-
- This function is particularly useful if you distribute your code
- as fasls with either `fasl-op' or `monolithic-fasl-op', and want
- to register systems so that dependencies will work uniformly
- whether you're using your software from source or from fasl.
</span><span style="color: #000000;background-color: #ddffdd">+ A system with name NAME, created by 'make-instance' with extra keys
+ KEYS (e.g. ':version'), is registered as _preloaded_. That is,
+ its code has already been loaded into the current image, and if at
+ some point some other system ':depends-on' it yet no source code is
+ found, it is considered as already provided, and ASDF will not
+ raise a 'missing-component' error.
+
+ This function is particularly useful if you distribute your code as
+ fasls with either 'compile-bundle-op' or
+ 'monolithic-compile-bundle-op', and want to register systems so
+ that dependencies will work uniformly whether you're using your
+ software from source or from fasl.
+
+ -- Function: register-immutable-system name &rest keys
+ A system with name NAME, created by 'make-instance' with extra keys
+ KEYS (e.g. ':version'), is registered as _immutable_. That is,
+ its code has already been loaded into the current image, and if at
+ some point some other system ':depends-on' it, it is considered as
+ already provided, and no attempt will be made to search for an
+ updated version from the source-registry or any other method.
+ There will be no search for an '.asd' file, and no
+ 'missing-component' error.
+
+ This function (available since ASDF 3.1.5) is particularly useful
+ if you distribute a large body of code as a precompiled image, and
+ want to allow users to extend the image with further extension
+ systems, but without making thousands of filesystem requests
+ looking for inexistent (or worse, out of date) source code for all
+ the systems that came bundled with the image but aren't distributed
+ as source code to regular users.
</span>
-- Function: run-shell-command control-string &rest args
<span style="color: #000000;background-color: #ddffdd">+
</span> This function is obsolete and present only for the sake of
backwards-compatibility: "If it's not backwards, it's not
<span style="color: #000000;background-color: #ffdddd">- compatible". We _strongly_ discourage its use. Its current
- behavior is only well-defined on Unix platforms (which include
- MacOS X and cygwin). On Windows, anything goes. The following
</span><span style="color: #000000;background-color: #ddffdd">+ compatible". We _strongly_ discourage its use. Its current
+ behaviour is only well-defined on Unix platforms (which include
+ MacOS X and cygwin). On Windows, anything goes. The following
</span> documentation is only for the purpose of your migrating away from
it in a way that preserves semantics.
<span style="color: #000000;background-color: #ffdddd">- Instead we recommend the use `run-program', described in the next
</span><span style="color: #000000;background-color: #ddffdd">+ Instead we recommend the use 'run-program', described in the next
</span> section, and available as part of ASDF since ASDF 3.
<span style="color: #000000;background-color: #ffdddd">- `run-shell-command' takes as arguments a format `control-string'
- and arguments to be passed to `format' after this control-string
- to produce a string. This string is a command that will be
- evaluated with a POSIX shell if possible; yet, on Windows, some
</span><span style="color: #000000;background-color: #ddffdd">+ 'run-shell-command' takes as arguments a format 'control-string'
+ and arguments to be passed to 'format' after this control-string to
+ produce a string. This string is a command that will be evaluated
+ with a POSIX shell if possible; yet, on Windows, some
</span> implementations will use CMD.EXE, while others (like SBCL) will
make an attempt at invoking a POSIX shell (and fail if it is not
present).
<span style="color: #000000;background-color: #ffdddd">-10.4 Some Utility Functions
</span><span style="color: #000000;background-color: #ddffdd">+ ---------- Footnotes ----------
+
+ (1) Alternatively, you could touch 'foo.asd' or remove the
+corresponding fasls from the output file cache.
+
+
+File: asdf.info, Node: Some Utility Functions, Prev: Miscellaneous Functions, Up: Miscellaneous additional functionality
+
+11.4 Some Utility Functions
</span> ===========================
The below functions are not exported by ASDF itself, but by UIOP,
<span style="color: #aaaaaa">@@ -3125,321 +4063,444 @@ and sources for more information.
</span> Coerce NAME into a PATHNAME using standard Unix syntax.
Unix syntax is used whether or not the underlying system is Unix;
<span style="color: #000000;background-color: #ffdddd">- on such non-Unix systems it is only usable but for relative
- pathnames; but especially to manipulate relative pathnames
- portably, it is of crucial to possess a portable pathname syntax
- independent of the underlying OS. This is what
- `parse-unix-namestring' provides, and why we use it in ASDF.
-
- When given a `pathname' object, just return it untouched. When
- given `nil', just return `nil'. When given a non-null `symbol',
</span><span style="color: #000000;background-color: #ddffdd">+ on non-Unix systems it is only usable for relative pathnames. In
+ order to manipulate relative pathnames portably, it is crucial to
+ possess a portable pathname syntax independent of the underlying
+ OS. This is what 'parse-unix-namestring' provides, and why we use
+ it in ASDF.
+
+ When given a 'pathname' object, just return it untouched. When
+ given 'nil', just return 'nil'. When given a non-null 'symbol',
</span> first downcase its name and treat it as a string. When given a
<span style="color: #000000;background-color: #ffdddd">- `string', portably decompose it into a pathname as below.
</span><span style="color: #000000;background-color: #ddffdd">+ 'string', portably decompose it into a pathname as below.
</span>
<span style="color: #000000;background-color: #ffdddd">- `#\/' separates directory components.
</span><span style="color: #000000;background-color: #ddffdd">+ '#\/' separates directory components.
</span>
<span style="color: #000000;background-color: #ffdddd">- The last `#\/'-separated substring is interpreted as follows: 1-
- If TYPE is `:directory' or ENSURE-DIRECTORY is true, the string
- is made the last directory component, and its `name' and `type'
- are `nil'. if the string is empty, it's the empty pathname with
- all slots `nil'. 2- If TYPE is `nil', the substring is a
- file-namestring, and its `name' and `type' are separated by
- `split-name-type'. 3- If TYPE is a string, it is the given
- `type', and the whole string is the `name'.
</span><span style="color: #000000;background-color: #ddffdd">+ The last '#\/'-separated substring is interpreted as follows: 1- If
+ TYPE is ':directory' or ENSURE-DIRECTORY is true, the string is
+ made the last directory component, and its 'name' and 'type' are
+ 'nil'. if the string is empty, it's the empty pathname with all
+ slots 'nil'. 2- If TYPE is 'nil', the substring is a
+ file-namestring, and its 'name' and 'type' are separated by
+ 'split-name-type'. 3- If TYPE is a string, it is the given 'type',
+ and the whole string is the 'name'.
</span>
<span style="color: #000000;background-color: #ffdddd">- Directory components with an empty name the name `.' are removed.
- Any directory named `..' is read as DOT-DOT, which must be one of
- `:back' or `:up' and defaults to `:back'.
</span><span style="color: #000000;background-color: #ddffdd">+ Directory components with an empty name the name '.' are removed.
+ Any directory named '..' is read as DOT-DOT, which must be one of
+ ':back' or ':up' and defaults to ':back'.
</span>
<span style="color: #000000;background-color: #ffdddd">- `host', `device' and `version' components are taken from DEFAULTS,
- which itself defaults to `*nil-pathname*', also used if DEFAULTS
- is `nil'. No host or device can be specified in the string itself,
- which makes it unsuitable for absolute pathnames outside Unix.
</span><span style="color: #000000;background-color: #ddffdd">+ 'host', 'device' and 'version' components are taken from DEFAULTS,
+ which itself defaults to '*nil-pathname*'. '*nil-pathname*' is
+ also used if DEFAULTS is 'nil'. No host or device can be specified
+ in the string itself, which makes it unsuitable for absolute
+ pathnames outside Unix.
</span>
For relative pathnames, these components (and hence the defaults)
<span style="color: #000000;background-color: #ffdddd">- won't matter if you use `merge-pathnames*' but will matter if you
- use `merge-pathnames', which is an important reason to always use
- `merge-pathnames*'.
</span><span style="color: #000000;background-color: #ddffdd">+ won't matter if you use 'merge-pathnames*' but will matter if you
+ use 'merge-pathnames', which is an important reason to always use
+ 'merge-pathnames*'.
</span>
Arbitrary keys are accepted, and the parse result is passed to
<span style="color: #000000;background-color: #ffdddd">- `ensure-pathname' with those keys, removing TYPE, DEFAULTS and
</span><span style="color: #000000;background-color: #ddffdd">+ 'ensure-pathname' with those keys, removing TYPE, DEFAULTS and
</span> DOT-DOT. When you're manipulating pathnames that are supposed to
make sense portably even though the OS may not be Unixish, we
<span style="color: #000000;background-color: #ffdddd">- recommend you use `:want-relative t' to throw an error if the
- pathname is absolute
</span><span style="color: #000000;background-color: #ddffdd">+ recommend you use ':want-relative t' so that
+ 'parse-unix-namestring' will throw an error if the pathname is
+ absolute.
</span>
-- Function: merge-pathnames* specified &optional defaults
<span style="color: #000000;background-color: #ffdddd">- This function is a replacement for `merge-pathnames' that uses the
</span><span style="color: #000000;background-color: #ddffdd">+
+ This function is a replacement for 'merge-pathnames' that uses the
</span> host and device from the DEFAULTS rather than the SPECIFIED
<span style="color: #000000;background-color: #ffdddd">- pathname when the latter is a relative pathname. This allows ASDF
</span><span style="color: #000000;background-color: #ddffdd">+ pathname when the latter is a relative pathname. This allows ASDF
</span> and its users to create and use relative pathnames without having
to know beforehand what are the host and device of the absolute
pathnames they are relative to.
<span style="color: #000000;background-color: #ffdddd">-
</span> -- Function: subpathname pathname subpath &key type
<span style="color: #000000;background-color: #ddffdd">+
</span> This function takes a PATHNAME and a SUBPATH and a TYPE. If
<span style="color: #000000;background-color: #ffdddd">- SUBPATH is already a `pathname' object (not namestring), and is an
</span><span style="color: #000000;background-color: #ddffdd">+ SUBPATH is already a 'pathname' object (not namestring), and is an
</span> absolute pathname at that, it is returned unchanged; otherwise,
SUBPATH is turned into a relative pathname with given TYPE as per
<span style="color: #000000;background-color: #ffdddd">- `parse-unix-namestring' with `:want-relative t :type 'TYPE, then
- it is merged with the `pathname-directory-pathname' of PATHNAME,
- as per `merge-pathnames*'.
</span><span style="color: #000000;background-color: #ddffdd">+ 'parse-unix-namestring' with ':want-relative t :type 'TYPE, then it
+ is merged with the 'pathname-directory-pathname' of PATHNAME, as
+ per 'merge-pathnames*'.
</span>
We strongly encourage the use of this function for portably
resolving relative pathnames in your code base.
-- Function: subpathname* pathname subpath &key type
<span style="color: #000000;background-color: #ffdddd">- This function returns `nil' if the base PATHNAME is `nil',
- otherwise acts like `subpathname'.
</span><span style="color: #000000;background-color: #ddffdd">+
+ This function returns 'nil' if the base PATHNAME is 'nil',
+ otherwise acts like 'subpathname'.
</span>
-- Function: run-program command &key ignore-error-status force-shell
<span style="color: #000000;background-color: #ffdddd">- input output error-output
- if-input-does-not-exist if-output-exists if-error-output-exists
- element-type external-format &allow-other-keys
</span><span style="color: #000000;background-color: #ddffdd">+ input output error-output if-input-does-not-exist
+ if-output-exists if-error-output-exists element-type
+ external-format &allow-other-keys
</span>
<span style="color: #000000;background-color: #ffdddd">- `run-program' takes a COMMAND argument that is either a list of a
</span><span style="color: #000000;background-color: #ddffdd">+ 'run-program' takes a COMMAND argument that is either a list of a
</span> program name or path and its arguments, or a string to be executed
by a shell. It spawns the command, waits for it to return,
verifies that it exited cleanly (unless told not too below), and
optionally captures and processes its output. It accepts many
<span style="color: #000000;background-color: #ffdddd">- keyword arguments to configure its behavior.
</span><span style="color: #000000;background-color: #ddffdd">+ keyword arguments to configure its behaviour.
</span>
<span style="color: #000000;background-color: #ffdddd">- `run-program' returns three values: the first for the output, the
</span><span style="color: #000000;background-color: #ddffdd">+ 'run-program' returns three values: the first for the output, the
</span> second for the error-output, and the third for the return value.
(Beware that before ASDF 3.0.2.11, it didn't handle input or
error-output, and returned only one value, the one for the output
<span style="color: #000000;background-color: #ffdddd">- if any handler was specified, or else the exit code; please
- upgrade ASDF, or at least UIOP, to rely on the new enhanced
- behavior.)
</span><span style="color: #000000;background-color: #ddffdd">+ if any handler was specified, or else the exit code; please upgrade
+ ASDF, or at least UIOP, to rely on the new enhanced behaviour.)
</span>
OUTPUT is its most important argument; it specifies how the output
<span style="color: #000000;background-color: #ffdddd">- is captured and processed. If it is `nil', then the output is
</span><span style="color: #000000;background-color: #ddffdd">+ is captured and processed. If it is 'nil', then the output is
</span> redirected to the null device, that will discard it. If it is
<span style="color: #000000;background-color: #ffdddd">- `:interactive', then it is inherited from the current process
</span><span style="color: #000000;background-color: #ddffdd">+ ':interactive', then it is inherited from the current process
</span> (beware: this may be different from your *STANDARD-OUTPUT*, and
<span style="color: #000000;background-color: #ffdddd">- under SLIME will be on your `*inferior-lisp*' buffer). If it is
- `t', output goes to your current *STANDARD-OUTPUT* stream.
</span><span style="color: #000000;background-color: #ddffdd">+ under SLIME will be on your '*inferior-lisp*' buffer). If it is
+ 't', output goes to your current *STANDARD-OUTPUT* stream.
</span> Otherwise, OUTPUT should be a value that is a suitable first
<span style="color: #000000;background-color: #ffdddd">- argument to `slurp-input-stream' (see below), or a list of such a
- value and keyword arguments. In this case, `run-program' will
</span><span style="color: #000000;background-color: #ddffdd">+ argument to 'slurp-input-stream' (see below), or a list of such a
+ value and keyword arguments. In this case, 'run-program' will
</span> create a temporary stream for the program output; the program
output, in that stream, will be processed by a call to
<span style="color: #000000;background-color: #ffdddd">- `slurp-input-stream', using OUTPUT as the first argument (or if
</span><span style="color: #000000;background-color: #ddffdd">+ 'slurp-input-stream', using OUTPUT as the first argument (or if
</span> it's a list the first element of OUTPUT and the rest as keywords).
<span style="color: #000000;background-color: #ffdddd">- The primary value resulting from that call (or `nil' if no call
- was needed) will be the first value returned by `run-program'.
- E.g., using `:output :string' will have it return the entire
- output stream as a string. And using `:output '(:string :stripped
- t)' will have it return the same string stripped of any ending
- newline.
</span><span style="color: #000000;background-color: #ddffdd">+ The primary value resulting from that call (or 'nil' if no call was
+ needed) will be the first value returned by 'run-program'. E.g.,
+ using ':output :string' will have it return the entire output
+ stream as a string. And using ':output '(:string :stripped t)'
+ will have it return the same string stripped of any ending newline.
</span>
ERROR-OUTPUT is similar to OUTPUT, except that the resulting value
<span style="color: #000000;background-color: #ffdddd">- is returned as the second value of `run-program'. `t' designates
- the *ERROR-OUTPUT*. Also `:output' means redirecting the error
- output to the output stream, in which case `nil' is returned.
</span><span style="color: #000000;background-color: #ddffdd">+ is returned as the second value of 'run-program'. 't' designates
+ the *ERROR-OUTPUT*. Also ':output' means redirecting the error
+ output to the output stream, in which case 'nil' is returned.
</span>
<span style="color: #000000;background-color: #ffdddd">- INPUT is similar to OUTPUT, except that `vomit-output-stream' is
- used, no value is returned, and `t' designates the
</span><span style="color: #000000;background-color: #ddffdd">+ INPUT is similar to OUTPUT, except that 'vomit-output-stream' is
+ used, no value is returned, and 't' designates the
</span> *STANDARD-INPUT*.
<span style="color: #000000;background-color: #ffdddd">- `element-type' and `external-format' are passed on to your Lisp
</span><span style="color: #000000;background-color: #ddffdd">+ 'element-type' and 'external-format' are passed on to your Lisp
</span> implementation, when applicable, for creation of the output stream.
One and only one of the stream slurping or vomiting may or may not
happen in parallel in parallel with the subprocess, depending on
<span style="color: #000000;background-color: #ffdddd">- options and implementation, and with priority being given to
- output processing. Other streams are completely produced or
- consumed before or after the subprocess is spawned, using
- temporary files.
</span><span style="color: #000000;background-color: #ddffdd">+ options and implementation, and with priority being given to output
+ processing. Other streams are completely produced or consumed
+ before or after the subprocess is spawned, using temporary files.
</span>
<span style="color: #000000;background-color: #ffdddd">- `force-shell' forces evaluation of the command through a shell,
</span><span style="color: #000000;background-color: #ddffdd">+ 'force-shell' forces evaluation of the command through a shell,
</span> even if it was passed as a list rather than a string. If a shell
<span style="color: #000000;background-color: #ffdddd">- is used, it is `/bin/sh' on Unix or `CMD.EXE' on Windows, except
- on implementations that (erroneously, IMNSHO) insist on consulting
- `$SHELL' like clisp.
</span><span style="color: #000000;background-color: #ddffdd">+ is used, it is '/bin/sh' on Unix or 'CMD.EXE' on Windows, except on
+ implementations that (erroneously, IMNSHO) insist on consulting
+ '$SHELL' like clisp.
</span>
<span style="color: #000000;background-color: #ffdddd">- `ignore-error-status' causes `run-program' to not raise an error
- if the spawned program exits in error. Following POSIX
- convention, an error is anything but a normal exit with status
- code zero. By default, an error of type `subprocess-error' is
- raised in this case.
</span><span style="color: #000000;background-color: #ddffdd">+ 'ignore-error-status' causes 'run-program' to not raise an error if
+ the spawned program exits in error. Following POSIX convention, an
+ error is anything but a normal exit with status code zero. By
+ default, an error of type 'subprocess-error' is raised in this
+ case.
</span>
<span style="color: #000000;background-color: #ffdddd">- `run-program' works on all platforms supported by ASDF, except
</span><span style="color: #000000;background-color: #ddffdd">+ 'run-program' works on all platforms supported by ASDF, except
</span> Genera. See the source code for more documentation.
<span style="color: #000000;background-color: #ffdddd">-
</span> -- Function: slurp-input-stream processor input-stream &key
<span style="color: #000000;background-color: #ffdddd">- It's a generic function of two arguments, a target object and an
- input stream, and accepting keyword arguments. Predefined methods
- based on the target object are as follow:
-
- If the object is a function, the function is called with the
- stream as argument.
-
- If the object is a cons, its first element is applied to its rest
- appended by a list of the input stream.
-
- If the object is an output stream, the contents of the input
- stream are copied to it. If the LINEWISE keyword argument is
- provided, copying happens line by line, and an optional PREFIX is
- printed before each line. Otherwise, copying happen based on a
- buffer of size BUFFER-SIZE, using the specified ELEMENT-TYPE.
-
- If the object is `'string' or `:string', the content is captured
- into a string. Accepted keywords include the ELEMENT-TYPE and a
- flag STRIPPED, which when true causes any single line ending to be
- removed as per `uiop:stripln'.
-
- If the object is `:lines', the content is captured as a list of
- strings, one per line, without line ending. If the COUNT keyword
- argument is provided, it is a maximum count of lines to be read.
-
- If the object is `:line', the content is capture as with `:lines'
- above, and then its sub-object is extracted with the AT argument,
- which defaults to `0', extracting the first line. A number will
- extract the corresponding line. See the documentation for
- `uiop:access-at'.
-
- If the object is `:forms', the content is captured as a list of
- S-expressions, as read by the Lisp reader. If the COUNT argument
- is provided, it is a maximum count of lines to be read. We
- recommend you control the syntax with such macro as
- `uiop:with-safe-io-syntax'.
-
- If the object is `:form', the content is capture as with `:forms'
- above, and then its sub-object is extracted with the AT argument,
- which defaults to `0', extracting the first form. A number will
- extract the corresponding form. See the documentation for
- `uiop:access-at'. We recommend you control the syntax with such
- macro as `uiop:with-safe-io-syntax'.
</span>
<span style="color: #000000;background-color: #ddffdd">+ 'slurp-input-stream' is a generic function of two arguments, a
+ target object and an input stream, and accepting keyword arguments.
+ Predefined methods based on the target object are as follows:
+
+ * If the object is a function, the function is called with the
+ stream as argument.
+
+ * If the object is a cons, its first element is applied to its
+ rest appended by a list of the input stream.
+
+ * If the object is an output stream, the contents of the input
+ stream are copied to it. If the LINEWISE keyword argument is
+ provided, copying happens line by line, and an optional PREFIX
+ is printed before each line. Otherwise, copying happen based
+ on a buffer of size BUFFER-SIZE, using the specified
+ ELEMENT-TYPE.
+
+ * If the object is ''string' or ':string', the content is
+ captured into a string. Accepted keywords include the
+ ELEMENT-TYPE and a flag STRIPPED, which when true causes any
+ single line ending to be removed as per 'uiop:stripln'.
+
+ * If the object is ':lines', the content is captured as a list
+ of strings, one per line, without line ending. If the COUNT
+ keyword argument is provided, it is a maximum count of lines
+ to be read.
+
+ * If the object is ':line', the content is captured as with
+ ':lines' above, and then its sub-object is extracted with the
+ AT argument, which defaults to '0', extracting the first line.
+ A number will extract the corresponding line. See the
+ documentation for 'uiop:access-at'.
+
+ * If the object is ':forms', the content is captured as a list
+ of S-expressions, as read by the Lisp reader. If the COUNT
+ argument is provided, it is a maximum count of lines to be
+ read. We recommend you control the syntax with such macro as
+ 'uiop:with-safe-io-syntax'.
+
+ * If the object is ':form', the content is captured as with
+ ':forms' above, and then its sub-object is extracted with the
+ AT argument, which defaults to '0', extracting the first form.
+ A number will extract the corresponding form. See the
+ documentation for 'uiop:access-at'. We recommend you control
+ the syntax with such macro as 'uiop:with-safe-io-syntax'.
</span>
File: asdf.info, Node: Getting the latest version, Next: FAQ, Prev: Miscellaneous additional functionality, Up: Top
<span style="color: #000000;background-color: #ffdddd">-11 Getting the latest version
</span><span style="color: #000000;background-color: #ddffdd">+12 Getting the latest version
</span> *****************************
<span style="color: #000000;background-color: #ffdddd">-Decide which version you want. The `master' branch is where
-development happens; its `HEAD' is usually OK, including the latest
-fixes and portability tweaks, but an occasional regression may happen
-despite our (limited) test suite.
</span><span style="color: #000000;background-color: #ddffdd">+Decide which version you want. The 'master' branch is where development
+happens; its 'HEAD' is usually OK, including the latest fixes and
+portability tweaks, but an occasional regression may happen despite our
+(limited) test suite.
</span>
<span style="color: #000000;background-color: #ffdddd">- The `release' branch is what cautious people should be using; it has
</span><span style="color: #000000;background-color: #ddffdd">+ The 'release' branch is what cautious people should be using; it has
</span> usually been tested more, and releases are cut at a point where there
isn't any known unresolved issue.
<span style="color: #000000;background-color: #ffdddd">- You may get the ASDF source repository using git: `git clone
-git://common-lisp.net/projects/asdf/asdf.git'
</span><span style="color: #000000;background-color: #ddffdd">+ You may get the ASDF source repository using git: 'git clone
+https://gitlab.common-lisp.net/asdf/asdf.git'
</span>
You will find the above referenced tags in this repository. You can
also browse the repository on
<span style="color: #000000;background-color: #ffdddd">-`http://common-lisp.net/gitweb?p=projects/asdf/asdf.git'.
</span><span style="color: #000000;background-color: #ddffdd">+<https://gitlab.common-lisp.net/asdf/asdf>.
</span>
Discussion of ASDF development is conducted on the mailing list
<span style="color: #000000;background-color: #ffdddd">-`asdf-devel@common-lisp.net'.
-`http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel'
</span><span style="color: #000000;background-color: #ddffdd">+(*note Mailing list::).
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: FAQ, Next: TODO list, Prev: Getting the latest version, Up: Top
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: FAQ, Next: Ongoing Work, Prev: Getting the latest version, Up: Top
</span>
<span style="color: #000000;background-color: #ffdddd">-12 FAQ
</span><span style="color: #000000;background-color: #ddffdd">+13 FAQ
</span> ******
<span style="color: #000000;background-color: #ffdddd">-12.1 "Where do I report a bug?"
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* Where do I report a bug?::
+* Mailing list::
+* What has changed between ASDF 1 ASDF 2 and ASDF 3?::
+* Issues with installing the proper version of ASDF::
+* Issues with configuring ASDF::
+* Issues with using and extending ASDF to define systems::
+* ASDF development FAQs::
+
+
+File: asdf.info, Node: Where do I report a bug?, Next: Mailing list, Prev: FAQ, Up: FAQ
+
+13.1 "Where do I report a bug?"
</span> ===============================
<span style="color: #000000;background-color: #ffdddd">-ASDF bugs are tracked on launchpad: `https://launchpad.net/asdf'.
</span><span style="color: #000000;background-color: #ddffdd">+ASDF bugs are tracked on launchpad: <https://launchpad.net/asdf>.
</span>
If you're unsure about whether something is a bug, or for general
<span style="color: #000000;background-color: #ffdddd">-discussion, use the asdf-devel mailing list
-(http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel)
</span><span style="color: #000000;background-color: #ddffdd">+discussion, use the asdf-devel mailing list (*note Mailing list::).
+
+
+File: asdf.info, Node: Mailing list, Next: What has changed between ASDF 1 ASDF 2 and ASDF 3?, Prev: Where do I report a bug?, Up: FAQ
</span>
<span style="color: #000000;background-color: #ffdddd">-12.2 "What has changed between ASDF 1 and ASDF 2?"
-==================================================
</span><span style="color: #000000;background-color: #ddffdd">+13.2 Mailing list
+=================
</span>
<span style="color: #000000;background-color: #ffdddd">-12.2.1 What are ASDF 1 and ASDF 2?
-----------------------------------
</span><span style="color: #000000;background-color: #ddffdd">+Discussion of ASDF development is conducted on the mailing list
+'asdf-devel@common-lisp.net'.
+<http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel>
</span>
<span style="color: #000000;background-color: #ffdddd">-On May 31st 2010, we have released ASDF 2. ASDF 2 refers to release
-2.000 and later. (Releases between 1.656 and 1.728 were development
-releases for ASDF 2.) ASDF 1 to any release earlier than 1.369 or so.
-If your ASDF doesn't sport a version, it's an old ASDF 1.
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: What has changed between ASDF 1 ASDF 2 and ASDF 3?, Next: Issues with installing the proper version of ASDF, Prev: Mailing list, Up: FAQ
+
+13.3 "What has changed between ASDF 1, ASDF 2, and ASDF 3?"
+===========================================================
+
+We released ASDF 2.000 on May 31st 2010, ASDF 3.0.0 on May 15th 2013,
+ASDF 3.1.2 on May 6th 2014. Releases of ASDF 2 and now ASDF 3 have
+since then been included in all actively maintained CL implementations
+that used to bundle ASDF 1, plus many implementations that previously
+did not. ASDF has been made to work with all actively maintained CL
+implementations and even a few implementations that are _not_ actively
+maintained.
+
+ Furthermore, it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF
+3 on the fly (though we recommend instead upgrading your implementation
+or replacing its ASDF module). For this reason, we have stopped
+supporting ASDF 1 and ASDF 2. If you are using ASDF 1 or ASDF 2 and are
+experiencing any kind of issues or limitations, we recommend you upgrade
+to ASDF 3 -- and we explain how to do that. *Note Loading ASDF::.
+
+ Note that in the context of compatibility requirements, ASDF 2.27,
+released on Feb 1st 2013, and further releases up to 2.33, count as
+pre-releases of ASDF 3, and define the ':asdf3' feature, though the
+first stable release of ASDF 3 was release 3.0.1. Significant new or
+improved functionality were added in ASDF 3.1; the ':asdf3.1' feature is
+present in recent enough versions to detect this functionality; the
+first stable release since then was ASDF 3.1.2. New '*features*' are
+only added at major milestones, and the next one will probably be
+':asdf3.2'.
+
+* Menu:
+
+* What are ASDF 1 2 3?::
+* How do I detect the ASDF version?::
+* ASDF can portably name files in subdirectories::
+* Output translations::
+* Source Registry Configuration::
+* Usual operations are made easier to the user::
+* Many bugs have been fixed::
+* ASDF itself is versioned::
+* ASDF can be upgraded::
+* Decoupled release cycle::
+* Pitfalls of the transition to ASDF 2::
+* Pitfalls of the upgrade to ASDF 3::
+* What happened to the bundle operations::
+
+
+File: asdf.info, Node: What are ASDF 1 2 3?, Next: How do I detect the ASDF version?, Prev: What has changed between ASDF 1 ASDF 2 and ASDF 3?, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.1 What are ASDF 1, ASDF 2, and ASDF 3?
+-------------------------------------------
+
+ASDF 1 refers to any release earlier than 1.369 or so (from August 2001
+to October 2009), and to any development revision earlier than 2.000
+(May 2010). If your copy of ASDF doesn't even contain version
+information, it's an old ASDF 1. Revisions between 1.656 and 1.728 may
+count as development releases for ASDF 2.
+
+ ASDF 2 refers to releases from 2.000 (May 31st 2010) to 2.26 (Oct
+30th 2012), and any development revision newer than ASDF 1 and older
+than 2.27 (Feb 1st 2013).
+
+ ASDF 3 refers to releases from 2.27 (Feb 1st 2013) to 2.33 and 3.0.0
+onward (May 15th 2013). 2.27 to 2.33 count as pre-releases to ASDF 3.
+
+ ASDF 3.1 refers to releases from 3.1.2 (May 6th 2014) onward. These
+releases are also considered part of ASDF 3.
+
+
+File: asdf.info, Node: How do I detect the ASDF version?, Next: ASDF can portably name files in subdirectories, Prev: What are ASDF 1 2 3?, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.2 How do I detect the ASDF version?
+----------------------------------------
+
+All releases of ASDF push ':asdf' onto '*features*'. Releases starting
+with ASDF 2 push ':asdf2' onto '*features*'. Releases starting with
+ASDF 3 (including 2.27 and later pre-releases) push ':asdf3' onto
+'*features*'. Furthermore, releases starting with ASDF 3.1.2 (May
+2014), though they count as ASDF 3, include enough progress that they
+also push ':asdf3.1' onto '*features*'. You may depend on the presence
+or absence of these features to write code that takes advantage of
+recent ASDF functionality but still works on older versions, or at least
+detects the old version and signals an error.
+
+ Additionally, all releases starting with ASDF 2 define a function
+'(asdf:asdf-version)' you may use to query the version. All releases
+starting with 2.013 display the version number prominently on the second
+line of the 'asdf.lisp' source file.
+
+ If you are experiencing problems or limitations of any sort with ASDF
+1 or ASDF 2, we recommend that you should upgrade to the latest release,
+be it ASDF 3 or other.
+
+ Finally, here is a code snippet to programmatically determine what
+version of ASDF is loaded, if any, that works on all versions including
+very old ones:
</span>
<span style="color: #000000;background-color: #ffdddd">- ASDF 2 and its release candidates push `:asdf2' onto `*features*' so
-that if you are writing ASDF-dependent code you may check for this
-feature to see if the new API is present. _All_ versions of ASDF
-should have the `:asdf' feature.
</span><span style="color: #000000;background-color: #ddffdd">+ (when (find-package :asdf)
+ (let ((ver (symbol-value
+ (or (find-symbol (string :*asdf-version*) :asdf)
+ (find-symbol (string :*asdf-revision*) :asdf)))))
+ (etypecase ver
+ (string ver)
+ (cons (with-output-to-string (s)
+ (loop for (n . m) on ver
+ do (princ n s)
+ (when m (princ "." s)))))
+ (null "1.0"))))
</span>
<span style="color: #000000;background-color: #ffdddd">- Additionally, all versions of ASDF 2 define a function
-`(asdf:asdf-version)' you may use to query the version; and the source
-code of recent versions of ASDF 2 features the version number
-prominently on the second line of its source code.
</span><span style="color: #000000;background-color: #ddffdd">+ If it returns 'nil' then ASDF is not installed. Otherwise it should
+return a string. If it returns '"1.0"', then it can actually be any
+version before 1.77 or so, or some buggy variant of 1.x. If it returns
+anything older than '"3.0.1"', you really need to upgrade your
+implementation or at least upgrade its ASDF. *Note Replacing your
+implementation's ASDF::.
</span>
<span style="color: #000000;background-color: #ffdddd">- If you are experiencing problems or limitations of any sort with
-ASDF 1, we recommend that you should upgrade to ASDF 2, or whatever is
-the latest release.
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: ASDF can portably name files in subdirectories, Next: Output translations, Prev: How do I detect the ASDF version?, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
</span>
<span style="color: #000000;background-color: #ffdddd">-12.2.2 ASDF can portably name files in subdirectories
</span><span style="color: #000000;background-color: #ddffdd">+13.3.3 ASDF can portably name files in subdirectories
</span> -----------------------------------------------------
Common Lisp namestrings are not portable, except maybe for logical
<span style="color: #000000;background-color: #ffdddd">-pathnamestrings, that themselves have various limitations and require a
-lot of setup that is itself ultimately non-portable.
</span><span style="color: #000000;background-color: #ddffdd">+pathname namestrings, that themselves have various limitations and
+require a lot of setup that is itself ultimately non-portable.
</span>
In ASDF 1, the only portable ways to refer to pathnames inside
<span style="color: #000000;background-color: #ffdddd">-systems and components were very awkward, using `#.(make-pathname ...)'
-and `#.(merge-pathnames ...)'. Even the above were themselves were
</span><span style="color: #000000;background-color: #ddffdd">+systems and components were very awkward, using '#.(make-pathname ...)'
+and '#.(merge-pathnames ...)'. Even the above were themselves were
</span> inadequate in the general case due to host and device issues, unless
<span style="color: #000000;background-color: #ffdddd">-horribly complex patterns were used. Plenty of simple cases that
-looked portable actually weren't, leading to much confusion and
-greavance.
</span><span style="color: #000000;background-color: #ddffdd">+horribly complex patterns were used. Plenty of simple cases that looked
+portable actually weren't, leading to much confusion and greavance.
</span>
ASDF 2 implements its own portable syntax for strings as pathname
specifiers. Naming files within a system definition becomes easy and
<span style="color: #000000;background-color: #ffdddd">-portable again. *Note asdf:system-relative-pathname: Miscellaneous
-additional functionality, `merge-pathnames*', `coerce-pathname'.
</span><span style="color: #000000;background-color: #ddffdd">+portable again. *Note system-relative-pathname: Miscellaneous
+additional functionality, 'merge-pathnames*', 'coerce-pathname'.
</span>
On the other hand, there are places where systems used to accept
namestrings where you must now use an explicit pathname object:
<span style="color: #000000;background-color: #ffdddd">-`(defsystem ... :pathname "LOGICAL-HOST:PATH;TO;SYSTEM;" ...)' must now
-be written with the `#p' syntax: `(defsystem ... :pathname
</span><span style="color: #000000;background-color: #ddffdd">+'(defsystem ... :pathname "LOGICAL-HOST:PATH;TO;SYSTEM;" ...)' must now
+be written with the '#p' syntax: '(defsystem ... :pathname
</span> #p"LOGICAL-HOST:PATH;TO;SYSTEM;" ...)'
*Note Pathname specifiers: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">-12.2.3 Output translations
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Output translations, Next: Source Registry Configuration, Prev: ASDF can portably name files in subdirectories, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.4 Output translations
</span> --------------------------
A popular feature added to ASDF was output pathname translation:
<span style="color: #000000;background-color: #ffdddd">-`asdf-binary-locations', `common-lisp-controller', `cl-launch' and
-other hacks were all implementing it in ways both mutually incompatible
-and difficult to configure.
</span><span style="color: #000000;background-color: #ddffdd">+'asdf-binary-locations', 'common-lisp-controller', 'cl-launch' and other
+hacks were all implementing it in ways both mutually incompatible and
+difficult to configure.
</span>
Output pathname translation is essential to share source directories
of portable systems across multiple implementations or variants thereof,
<span style="color: #000000;background-color: #ffdddd">-or source directories of shared installations of systems across
-multiple users, or combinations of the above.
</span><span style="color: #000000;background-color: #ddffdd">+or source directories of shared installations of systems across multiple
+users, or combinations of the above.
</span>
In ASDF 2, a standard mechanism is provided for that,
<span style="color: #000000;background-color: #ffdddd">-`asdf-output-translations', with sensible defaults, adequate
</span><span style="color: #000000;background-color: #ddffdd">+'asdf-output-translations', with sensible defaults, adequate
</span> configuration languages, a coherent set of configuration files and
hooks, and support for non-Unix platforms.
*Note Controlling where ASDF saves compiled files::.
<span style="color: #000000;background-color: #ffdddd">-12.2.4 Source Registry Configuration
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Source Registry Configuration, Next: Usual operations are made easier to the user, Prev: Output translations, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.5 Source Registry Configuration
</span> ------------------------------------
<span style="color: #000000;background-color: #ffdddd">-Configuring ASDF used to require special magic to be applied just at
-the right moment, between the moment ASDF is loaded and the moment it
-is used, in a way that is specific to the user, the implementation he
-is using and the application he is building.
</span><span style="color: #000000;background-color: #ddffdd">+Configuring ASDF used to require special magic to be applied just at the
+right moment, between the moment ASDF is loaded and the moment it is
+used, in a way that is specific to the user, the implementation he is
+using and the application he is building.
</span>
This made for awkward configuration files and startup scripts that
<span style="color: #000000;background-color: #ffdddd">-could not be shared between users, managed by administrators or
-packaged by distributions.
</span><span style="color: #000000;background-color: #ddffdd">+could not be shared between users, managed by administrators or packaged
+by distributions.
</span>
ASDF 2 provides a well-documented way to configure ASDF, with
sensible defaults, adequate configuration languages, and a coherent set
<span style="color: #aaaaaa">@@ -3453,42 +4514,48 @@ every application. Yet settings can be easily overridden where needed,
</span> so whoever needs control has exactly as much as required.
At the same time, ASDF 2 remains compatible with the old magic you
<span style="color: #000000;background-color: #ffdddd">-may have in your build scripts (using `*central-registry*' and
-`*system-definition-search-functions*') to tailor the ASDF
-configuration to your build automation needs, and also allows for new
-magic, simpler and more powerful magic.
</span><span style="color: #000000;background-color: #ddffdd">+may have in your build scripts (using '*central-registry*' and
+'*system-definition-search-functions*') to tailor the ASDF configuration
+to your build automation needs, and also allows for new magic, simpler
+and more powerful magic.
</span>
*Note Controlling where ASDF searches for systems::.
<span style="color: #000000;background-color: #ffdddd">-12.2.5 Usual operations are made easier to the user
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Usual operations are made easier to the user, Next: Many bugs have been fixed, Prev: Source Registry Configuration, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.6 Usual operations are made easier to the user
</span> ---------------------------------------------------
<span style="color: #000000;background-color: #ffdddd">-In ASDF 1, you had to use the awkward syntax `(asdf:oos 'asdf:load-op
-:foo)' to load a system, and similarly for `compile-op', `test-op'.
</span><span style="color: #000000;background-color: #ddffdd">+In ASDF 1, you had to use the awkward syntax '(asdf:oos 'asdf:load-op
+:foo)' to load a system, and similarly for 'compile-op', 'test-op'.
</span>
In ASDF 2, you can use shortcuts for the usual operations:
<span style="color: #000000;background-color: #ffdddd">-`(asdf:load-system :foo)', and similarly for `compile-system',
-`test-system'.
</span><span style="color: #000000;background-color: #ddffdd">+'(asdf:load-system :foo)', and similarly for 'compile-system',
+'test-system'.
</span>
<span style="color: #000000;background-color: #ffdddd">-12.2.6 Many bugs have been fixed
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Many bugs have been fixed, Next: ASDF itself is versioned, Prev: Usual operations are made easier to the user, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.7 Many bugs have been fixed
</span> --------------------------------
The following issues and many others have been fixed:
<span style="color: #000000;background-color: #ffdddd">- * The infamous TRAVERSE function has been revamped completely
- between ASDF 1 and ASDF 2, with many bugs squashed. In
- particular, dependencies were not correctly propagated across
- modules but now are. It has been completely rewritten many times
- over between ASDF 2.000 and ASDF 3, with fundamental issues in the
- original model being fixed. Timestamps were not propagated at
- all, and now are. The internal model of how actions depend on
- each other is now both consistent and complete. The :version and
- the :force (system1 .. systemN) feature have been fixed.
</span><span style="color: #000000;background-color: #ddffdd">+ * The infamous TRAVERSE function has been revamped completely between
+ ASDF 1 and ASDF 2, with many bugs squashed. In particular,
+ dependencies were not correctly propagated across modules but now
+ are. It has been completely rewritten many times over between ASDF
+ 2.000 and ASDF 3, with fundamental issues in the original model
+ being fixed. Timestamps were not propagated at all, and now are.
+ The internal model of how actions depend on each other is now both
+ consistent and complete. The ':version' and the ':force (system1
+ .. systemN)' feature have been fixed.
</span>
* Performance has been notably improved for large systems (say with
thousands of components) by using hash-tables instead of linear
<span style="color: #000000;background-color: #ffdddd">- search, and linear-time list accumulation instead of
- quadratic-time recursive appends.
</span><span style="color: #000000;background-color: #ddffdd">+ search, and linear-time list accumulation instead of cubic time
+ recursive append, for an overall _O(n)_ complexity vs _O(n^4)_.
</span>
* Many features used to not be portable, especially where pathnames
were involved. Windows support was notably quirky because of such
<span style="color: #aaaaaa">@@ -3496,8 +4563,8 @@ The following issues and many others have been fixed:
</span>
* The internal test suite used to massively fail on many
implementations. While still incomplete, it now fully passes on
<span style="color: #000000;background-color: #ffdddd">- all implementations supported by the test suite, except for GCL
- (due to GCL bugs).
</span><span style="color: #000000;background-color: #ddffdd">+ all implementations supported by the test suite, though some tests
+ are commented out on a few implementations.
</span>
* Support was lacking for some implementations. ABCL and GCL were
notably wholly broken. ECL extensions were not integrated with
<span style="color: #aaaaaa">@@ -3505,43 +4572,51 @@ The following issues and many others have been fixed:
</span>
* The documentation was grossly out of date.
<span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: ASDF itself is versioned, Next: ASDF can be upgraded, Prev: Many bugs have been fixed, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
</span>
<span style="color: #000000;background-color: #ffdddd">-12.2.7 ASDF itself is versioned
</span><span style="color: #000000;background-color: #ddffdd">+13.3.8 ASDF itself is versioned
</span> -------------------------------
Between new features, old bugs fixed, and new bugs introduced, there
were various releases of ASDF in the wild, and no simple way to check
which release had which feature set. People using or writing systems
had to either make worst-case assumptions as to what features were
<span style="color: #000000;background-color: #ffdddd">-available and worked, or take great pains to have the correct version
-of ASDF installed.
</span><span style="color: #000000;background-color: #ddffdd">+available and worked, or take great pains to have the correct version of
+ASDF installed.
</span>
With ASDF 2, we provide a new stable set of working features that
<span style="color: #000000;background-color: #ffdddd">-everyone can rely on from now on. Use `#+asdf2' to detect presence of
-ASDF 2, `(asdf:version-satisfies (asdf:asdf-version) "2.345.67")' to
</span><span style="color: #000000;background-color: #ddffdd">+everyone can rely on from now on. Use '#+asdf2' to detect presence of
+ASDF 2, '(asdf:version-satisfies (asdf:asdf-version) "2.345.67")' to
</span> check the availability of a version no earlier than required.
<span style="color: #000000;background-color: #ffdddd">-12.2.8 ASDF can be upgraded
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: ASDF can be upgraded, Next: Decoupled release cycle, Prev: ASDF itself is versioned, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.9 ASDF can be upgraded
</span> ---------------------------
<span style="color: #000000;background-color: #ffdddd">-When an old version of ASDF was loaded, it was very hard to upgrade
-ASDF in your current image without breaking everything. Instead you
-had to exit the Lisp process and somehow arrange to start a new one
-from a simpler image. Something that can't be done from within Lisp,
-making automation of it difficult, which compounded with difficulty in
-configuration, made the task quite hard. Yet as we saw before, the
-task would have been required to not have to live with the worst case
-or non-portable subset of ASDF features.
-
- With ASDF 2, it is easy to upgrade from ASDF 2 to later versions
-from within Lisp, and not too hard to upgrade from ASDF 1 to ASDF 2
-from within Lisp. We support hot upgrade of ASDF and any breakage is a
-bug that we will do our best to fix. There are still limitations on
</span><span style="color: #000000;background-color: #ddffdd">+When an old version of ASDF was loaded, it was very hard to upgrade ASDF
+in your current image without breaking everything. Instead you had to
+exit the Lisp process and somehow arrange to start a new one from a
+simpler image. Something that can't be done from within Lisp, making
+automation of it difficult, which compounded with difficulty in
+configuration, made the task quite hard. Yet as we saw before, the task
+would have been required to not have to live with the worst case or
+non-portable subset of ASDF features.
+
+ With ASDF 2, it is easy to upgrade from ASDF 2 to later versions from
+within Lisp, and not too hard to upgrade from ASDF 1 to ASDF 2 from
+within Lisp. We support hot upgrade of ASDF and any breakage is a bug
+that we will do our best to fix. There are still limitations on
</span> upgrade, though, most notably the fact that after you upgrade ASDF, you
must also reload or upgrade all ASDF extensions.
<span style="color: #000000;background-color: #ffdddd">-12.2.9 Decoupled release cycle
-------------------------------
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Decoupled release cycle, Next: Pitfalls of the transition to ASDF 2, Prev: ASDF can be upgraded, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.10 Decoupled release cycle
+-------------------------------
</span>
When vendors were releasing their Lisp implementations with ASDF, they
had to basically never change version because neither upgrade nor
<span style="color: #aaaaaa">@@ -3555,13 +4630,16 @@ deal with a supported recent version of it. This means that release
</span> cycles will be causally decoupled, the practical consequence of which
will mean faster convergence towards the latest version for everyone.
<span style="color: #000000;background-color: #ffdddd">-12.2.10 Pitfalls of the transition to ASDF 2
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Pitfalls of the transition to ASDF 2, Next: Pitfalls of the upgrade to ASDF 3, Prev: Decoupled release cycle, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.11 Pitfalls of the transition to ASDF 2
</span> --------------------------------------------
The main pitfalls in upgrading to ASDF 2 seem to be related to the
output translation mechanism.
<span style="color: #000000;background-color: #ffdddd">- * Output translations is enabled by default. This may surprise some
</span><span style="color: #000000;background-color: #ddffdd">+ * Output translations is enabled by default. This may surprise some
</span> users, most of them in pleasant way (we hope), a few of them in an
unpleasant way. It is trivial to disable output translations.
*Note "How can I wholly disable the compiler output cache?": FAQ.
<span style="color: #aaaaaa">@@ -3574,36 +4652,35 @@ output translation mechanism.
</span> * The new ASDF output translations are incompatible with
ASDF-Binary-Locations. They replace A-B-L, and there is
compatibility mode to emulate your previous A-B-L configuration.
<span style="color: #000000;background-color: #ffdddd">- See `enable-asdf-binary-locations-compatibility' in *note Backward
</span><span style="color: #000000;background-color: #ddffdd">+ See 'enable-asdf-binary-locations-compatibility' in *note Backward
</span> Compatibility: Controlling where ASDF saves compiled files. But
thou shalt not load ABL on top of ASDF 2.
<span style="color: #000000;background-color: #ffdddd">-
</span> Other issues include the following:
* ASDF pathname designators are now specified in places where they
were unspecified, and a few small adjustments have to be made to
<span style="color: #000000;background-color: #ffdddd">- some non-portable defsystems. Notably, in the `:pathname' argument
- to a `defsystem' and its components, a logical pathname (or
</span><span style="color: #000000;background-color: #ddffdd">+ some non-portable defsystems. Notably, in the ':pathname' argument
+ to a 'defsystem' and its components, a logical pathname (or
</span> implementation-dependent hierarchical pathname) must now be
<span style="color: #000000;background-color: #ffdddd">- specified with `#p' syntax where the namestring might have
- previously sufficed; moreover when evaluation is desired `#.' must
- be used, where it wasn't necessary in the toplevel `:pathname'
- argument (but necessary in other `:pathname' arguments).
</span><span style="color: #000000;background-color: #ddffdd">+ specified with '#p' syntax where the namestring might have
+ previously sufficed; moreover when evaluation is desired '#.' must
+ be used, where it wasn't necessary in the toplevel ':pathname'
+ argument (but necessary in other ':pathname' arguments).
</span>
* There is a slight performance bug, notably on SBCL, when initially
<span style="color: #000000;background-color: #ffdddd">- searching for `asd' files, the implicit `(directory
- "/configured/path/**/*.asd")' for every configured path `(:tree
- "/configured/path/")' in your `source-registry' configuration can
- cause a slight pause. Try to `(time
</span><span style="color: #000000;background-color: #ddffdd">+ searching for 'asd' files, the implicit '(directory
+ "/configured/path/**/*.asd")' for every configured path '(:tree
+ "/configured/path/")' in your 'source-registry' configuration can
+ cause a slight pause. Try to '(time
</span> (asdf:initialize-source-registry))' to see how bad it is or isn't
on your system. If you insist on not having this pause, you can
avoid the pause by overriding the default source-registry
<span style="color: #000000;background-color: #ffdddd">- configuration and not use any deep `:tree' entry but only
- `:directory' entries or shallow `:tree' entries. Or you can fix
</span><span style="color: #000000;background-color: #ddffdd">+ configuration and not use any deep ':tree' entry but only
+ ':directory' entries or shallow ':tree' entries. Or you can fix
</span> your implementation to not be quite that slow when recursing
<span style="color: #000000;background-color: #ffdddd">- through directories. _Update_: This performance bug fixed the
- hard way in 2.010.
</span><span style="color: #000000;background-color: #ddffdd">+ through directories. _Update_: This performance bug fixed the hard
+ way in 2.010.
</span>
* On Windows, only LispWorks supports proper default configuration
pathnames based on the Windows registry. Other implementations
<span style="color: #aaaaaa">@@ -3616,124 +4693,279 @@ output translation mechanism.
</span> haven't all been tested.
* The mechanism by which one customizes a system so that Lisp files
<span style="color: #000000;background-color: #ffdddd">- may use a different extension from the default `.lisp' has changed.
</span><span style="color: #000000;background-color: #ddffdd">+ may use a different extension from the default '.lisp' has changed.
</span> Previously, the pathname for a component was lazily computed when
<span style="color: #000000;background-color: #ffdddd">- operating on a system, and you would `(defmethod source-file-type
</span><span style="color: #000000;background-color: #ddffdd">+ operating on a system, and you would '(defmethod source-file-type
</span> ((component cl-source-file) (system (eql (find-system 'foo))))
(declare (ignorable component system)) "lis")'. Now, the pathname
for a component is eagerly computed when defining the system, and
<span style="color: #000000;background-color: #ffdddd">- instead you will `(defclass cl-source-file.lis (cl-source-file)
- ((type :initform "lis")))' and use `:default-component-class
- cl-source-file.lis' as argument to `defsystem', as detailed in a
</span><span style="color: #000000;background-color: #ddffdd">+ instead you will '(defclass cl-source-file.lis (cl-source-file)
+ ((type :initform "lis")))' and use ':default-component-class
+ cl-source-file.lis' as argument to 'defsystem', as detailed in a
</span> *note How do I create a system definition where all the source
<span style="color: #000000;background-color: #ffdddd">- files have a .cl extension?: FAQ. below.
</span><span style="color: #000000;background-color: #ddffdd">+ files have a .cl extension?: FAQ. below. 'source-file-type' is
+ deprecated. To access a component's file-type, use 'file-type',
+ instead. 'source-file-type' will be removed.
+
+
+File: asdf.info, Node: Pitfalls of the upgrade to ASDF 3, Next: What happened to the bundle operations, Prev: Pitfalls of the transition to ASDF 2, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.12 Pitfalls of the upgrade to ASDF 3
+-----------------------------------------
+
+While ASDF 3 is largely compatible with ASDF 2, there are a few pitfalls
+when upgrading from ASDF 2, due to limitations in ASDF 2.
+
+ * ASDF 2 was designed so it could be upgraded; but upgrading it
+ required a special setup at the beginning of your build files.
+ Failure to upgrade it early could result in catastrophic attempt to
+ self-upgrade in mid-build.
+
+ * Starting with ASDF 3 (2.27 or later), ASDF will automatically
+ attempt to upgrade itself as the first step before any system
+ operation, to avoid any possibility of such catastrophic mid-build
+ self-upgrade. But that doesn't help if your old implementation
+ still provides ASDF 2.
+
+ * It was unsafe in ASDF 2 for a system definition to declare a
+ dependency on ASDF, since it could trigger such catastrophe for
+ users who were not carefully configured. If you declare a
+ dependency on a recent enough ASDF, yet want to be nice with these
+ potentially misconfigured users, we recommend that you not only
+ specify a recent ASDF in your dependencies with ':depends-on
+ ((:version "asdf" "3.1.2"))', but that you _also_ check that ASDF 3
+ is installed, or else the upgrade catastrophe might happen before
+ that specification is checked, by starting your '.asd' file with a
+ version check as follows:
+ #-asdf3 (error "MY-SYSTEM requires ASDF 3.1.2")
+
+ * When you upgrade from too old a version of ASDF, previously loaded
+ ASDF extensions become invalid, and will need to be reloaded.
+ Example extensions include CFFI-Grovel, hacks used by ironclad,
+ etc. Since it isn't possible to automatically detect what
+ extensions need to be invalidated and what systems use them, ASDF
+ will invalidate _all_ previously loaded systems when it is loaded
+ on top of a forward-incompatible ASDF version. (1)
+
+ * To write a portable build script, you need to rely on a recent
+ version of UIOP, but until you have ensured a recent ASDF is
+ loaded, you can't rely on UIOP being present, and thus must
+ manually avoid all the pathname pitfalls when loading ASDF itself.
+
+ * Bugs in CMUCL and XCL prevent upgrade of ASDF from an old
+ forward-incompatible version. Happily, CMUCL comes with a recent
+ ASDF, and XCL is more of a working demo than something you'd use
+ seriously anyway.
+
+ * For the above reasons, your build and startup scripts should load,
+ configure and upgrade ASDF among the very first things they do, and
+ ensure that ASDF 3 or later is present indeed, before they start
+ using ASDF to load anything else.
+
+ * Now that all implementations provide ASDF 3 or later (since May
+ 2015), the simple solution is just to use code as below in your
+ setup, and when it fails, upgrade your implementation or replace
+ its ASDF. (*note Replacing your implementation's ASDF::):
+ (require "asdf")
+ #-asdf3 (error "ASDF 3 or bust")
+
+ * For scripts that try to use ASDF simply via 'require' at first, and
+ make heroic attempts to load it the hard way if at first they don't
+ succeed, see 'tools/load-asdf.lisp' distributed with the ASDF
+ source repository, or the code of 'cl-launch'
+ (https://cliki.net/cl-launch).
+
+ * Note that in addition to the pitfalls and constraints above, these
+ heroic scripts (should you wish to write or modify one), must take
+ care to configure ASDF _twice_. A first time, right after you load
+ the old ASDF 2 and before you upgrade to the new ASDF 3, so it may
+ find where you put ASDF 3. A second time, because some
+ implementations can't handle a smooth upgrade to ASDF 3, and lose
+ configuration as they do.
+ (ignore-errors (funcall 'require "asdf")) ;; <--- try real hard
+ ;; <--- insert heroics here, if that failed to provide ASDF 2 or 3
+ ;; <--- insert configuration here, if that succeeded
+ (asdf:load-system "asdf")
+ ;; <--- re-configure here, too, in case at first you got ASDF 2
+
+ ---------- Footnotes ----------
+
+ (1) Forward incompatibility can be determined using the variable
+'asdf/upgrade::*oldest-forward-compatible-asdf-version*', which is 2.33
+at the time of this writing.
+
+
+File: asdf.info, Node: What happened to the bundle operations, Prev: Pitfalls of the upgrade to ASDF 3, Up: What has changed between ASDF 1 ASDF 2 and ASDF 3?
+
+13.3.13 What happened to the bundle operations?
+-----------------------------------------------
+
+'asdf-ecl' and its short-lived successor 'asdf-bundle' are no more,
+having been replaced by code now built into ASDF 3. Moreover, the name
+of the bundle operations has changed since ASDF 3.1.3.
+
+ And yet, the feature is not enabled to be used by 'load-system' by
+default on ECL as originally intended, because of a bug in ECL itself
+found during testing.
</span>
<span style="color: #000000;background-color: #ddffdd">+ Some of the bundle operations were renamed after ASDF 3.1.3, and the
+old names have been removed. Old bundle operations, and their modern
+equivalents are:
</span>
<span style="color: #000000;background-color: #ffdddd">-12.3 Issues with installing the proper version of ASDF
</span><span style="color: #000000;background-color: #ddffdd">+ * 'fasl-op' is now 'compile-bundle-op'
+ * 'load-fasl-op' is now 'load-bundle-op'
+ * 'binary-op' is now 'deliver-asd-op'
+ * 'monolithic-fasl-op' is now 'monolithic-compile-bundle-op'
+ * 'monolithic-load-fasl-op' is now 'monolithic-load-bundle-op'
+ * 'monolithic-binary-op' is now 'monolithic-deliver-asd-op'
+
+
+File: asdf.info, Node: Issues with installing the proper version of ASDF, Next: Issues with configuring ASDF, Prev: What has changed between ASDF 1 ASDF 2 and ASDF 3?, Up: FAQ
+
+13.4 Issues with installing the proper version of ASDF
</span> ======================================================
<span style="color: #000000;background-color: #ffdddd">-12.3.1 "My Common Lisp implementation comes with an outdated version of ASDF. What to do?"
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* My Common Lisp implementation comes with an outdated version of ASDF. What to do?::
+* I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?::
+
+
+File: asdf.info, Node: My Common Lisp implementation comes with an outdated version of ASDF. What to do?, Next: I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?, Prev: Issues with installing the proper version of ASDF, Up: Issues with installing the proper version of ASDF
+
+13.4.1 "My Common Lisp implementation comes with an outdated version of ASDF. What to do?"
</span> ------------------------------------------------------------------------------------------
<span style="color: #000000;background-color: #ffdddd">-We recommend you upgrade ASDF. *Note Upgrading ASDF: Loading ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+If you have a recent implementation, it should already come with ASDF 3
+or later. If you need a more recent version than is provided, we
+recommend you simply upgrade ASDF by installing a recent version in a
+path configured in your source-registry. *Note Upgrading ASDF::.
</span>
<span style="color: #000000;background-color: #ffdddd">- If this does not work, it is a bug, and you should report it. *Note
-report-bugs: FAQ. In the meantime, you can load `asdf.lisp' directly.
-*Note Loading an otherwise installed ASDF: Loading ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+ If you have an old implementation that does not provide ASDF 3, we
+recommend you replace your implementation's ASDF. *Note Replacing your
+implementation's ASDF::.
</span>
<span style="color: #000000;background-color: #ffdddd">-12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?"
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?, Prev: My Common Lisp implementation comes with an outdated version of ASDF. What to do?, Up: Issues with installing the proper version of ASDF
+
+13.4.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?"
</span> -------------------------------------------------------------------------------------
Since ASDF 2, it should always be a good time to upgrade to a recent
<span style="color: #000000;background-color: #ffdddd">-version of ASDF. You may consult with the maintainer for which
-specific version they recommend, but the latest `release' should be
-correct. We trust you to thoroughly test it with your implementation
-before you release it. If there are any issues with the current
-release, it's a bug that you should report upstream and that we will
-fix ASAP.
</span><span style="color: #000000;background-color: #ddffdd">+version of ASDF. You may consult with the maintainer for which specific
+version they recommend, but the latest 'release' should be correct.
+Though we do try to test ASDF releases against all implementations that
+we can, we may not be testing against all variants of your
+implementation, and we may not be running enough tests; we trust you to
+thoroughly test it with your own implementation before you release it.
+If there are any issues with the current release, it's a bug that you
+should report upstream and that we will fix ASAP.
</span>
As to how to include ASDF, we recommend the following:
<span style="color: #000000;background-color: #ffdddd">- * If ASDF isn't loaded yet, then `(require "asdf")' should load the
</span><span style="color: #000000;background-color: #ddffdd">+ * If ASDF isn't loaded yet, then '(require "asdf")' should load the
</span> version of ASDF that is bundled with your system. If possible so
<span style="color: #000000;background-color: #ffdddd">- should `(require "ASDF")'. You may have it load some other
- version configured by the user, if you allow such configuration.
</span><span style="color: #000000;background-color: #ddffdd">+ should '(require "ASDF")'. You may have it load some other version
+ configured by the user, if you allow such configuration.
</span>
<span style="color: #000000;background-color: #ffdddd">- * If your system provides a mechanism to hook into `CL:REQUIRE',
- then it would be nice to add ASDF to this hook the same way that
- ABCL, CCL, CLISP, CMUCL, ECL, SBCL and SCL do it. Please send us
</span><span style="color: #000000;background-color: #ddffdd">+ * If your system provides a mechanism to hook into 'cl:require', then
+ it would be nice to add ASDF to this hook the same way that ABCL,
+ CCL, CLISP, CMUCL, ECL, SBCL and SCL do it. Please send us
</span> appropriate code to this end.
<span style="color: #000000;background-color: #ffdddd">- * You may, like SBCL, have ASDF be implicitly used to require systems
- that are bundled with your Lisp distribution. If you do have a
- few magic systems that come with your implementation in a
- precompiled way such that one should only use the binary version
- that goes with your distribution, like SBCL does, then you should
- add them in the beginning of `wrapping-source-registry'.
-
- * If you have magic systems as above, like SBCL does, then we
- explicitly ask you to _NOT_ distribute `asdf.asd' as part of those
- magic systems. You should still include the file `asdf.lisp' in
</span><span style="color: #000000;background-color: #ddffdd">+ * You may, like SBCL since 1.1.13 or MKCL since 1.1.9, have ASDF
+ create bundle FASLs that are provided as modules by your Lisp
+ distribution. You may also, but we don't recommend that anymore,
+ as in SBCL up until 1.1.12, have ASDF be implicitly used to
+ 'cl:require' these modules that are provided by your Lisp
+ distribution; if you do, you should add these modules in the
+ beginning of both 'wrapping-source-registry' and
+ 'wrapping-output-translations'.
+
+ * If you have magic systems as above, like SBCL used to do, then we
+ explicitly ask you to _NOT_ distribute 'asdf.asd' as part of those
+ magic systems. You should still include the file 'asdf.lisp' in
</span> your source distribution and precompile it in your binary
<span style="color: #000000;background-color: #ffdddd">- distribution, but `asdf.asd' if included at all, should be
- secluded from the magic systems, in a separate file hierarchy.
- Alternatively, you may provide the system after renaming it and
- its `.asd' file to e.g. `asdf-ecl' and `asdf-ecl.asd', or
- `sb-asdf' and `sb-asdf.asd'. Indeed, if you made `asdf.asd' a
- magic system, then users would no longer be able to upgrade ASDF
- using ASDF itself to some version of their preference that they
- maintain independently from your Lisp distribution.
</span><span style="color: #000000;background-color: #ddffdd">+ distribution, but 'asdf.asd' if included at all, should be secluded
+ from the magic systems, in a separate file hierarchy.
+ Alternatively, you may provide the system after renaming it and its
+ '.asd' file to e.g. 'asdf-ecl' and 'asdf-ecl.asd', or 'sb-asdf'
+ and 'sb-asdf.asd'. Indeed, if you made 'asdf.asd' a magic system,
+ then users would no longer be able to upgrade ASDF using ASDF
+ itself to some version of their preference that they maintain
+ independently from your Lisp distribution.
</span>
* If you do not have any such magic systems, or have other non-magic
systems that you want to bundle with your implementation, then you
<span style="color: #000000;background-color: #ffdddd">- may add them to the `wrapping-source-registry', and you are
- welcome to include `asdf.asd' amongst them. Non-magic systems
- should be at the back of the `wrapping-source-registry' while
- magic systems are at the front.
</span><span style="color: #000000;background-color: #ddffdd">+ may add them to the 'wrapping-source-registry', and you are welcome
+ to include 'asdf.asd' amongst them. Non-magic systems should be at
+ the back of the 'wrapping-source-registry' while magic systems are
+ at the front. If they are precompiled, they should also be in the
+ 'wrapping-output-translations'.
+
+ * Since ASDF 3, the library UIOP comes transcluded in ASDF. But if
+ you want to be nice to users who care for UIOP but not for ASDF,
+ you may package UIOP separately, so that one may '(require "uiop")'
+ and not load ASDF, or one may '(require "asdf")' which would
+ implicitly require and load the former.
</span>
* Please send us upstream any patches you make to ASDF itself, so we
can merge them back in for the benefit of your users when they
upgrade to the upstream version.
<span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Issues with configuring ASDF, Next: Issues with using and extending ASDF to define systems, Prev: Issues with installing the proper version of ASDF, Up: FAQ
</span>
<span style="color: #000000;background-color: #ffdddd">-12.4 Issues with configuring ASDF
</span><span style="color: #000000;background-color: #ddffdd">+13.5 Issues with configuring ASDF
</span> =================================
<span style="color: #000000;background-color: #ffdddd">-12.4.1 "How can I customize where fasl files are stored?"
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* How can I customize where fasl files are stored?::
+* How can I wholly disable the compiler output cache?::
+
+
+File: asdf.info, Node: How can I customize where fasl files are stored?, Next: How can I wholly disable the compiler output cache?, Prev: Issues with configuring ASDF, Up: Issues with configuring ASDF
+
+13.5.1 "How can I customize where fasl files are stored?"
</span> ---------------------------------------------------------
*Note Controlling where ASDF saves compiled files::.
Note that in the past there was an add-on to ASDF called
<span style="color: #000000;background-color: #ffdddd">-`ASDF-binary-locations', developed by Gary King. That add-on has been
</span><span style="color: #000000;background-color: #ddffdd">+'ASDF-binary-locations', developed by Gary King. That add-on has been
</span> merged into ASDF proper, then superseded by the
<span style="color: #000000;background-color: #ffdddd">-`asdf-output-translations' facility.
</span><span style="color: #000000;background-color: #ddffdd">+'asdf-output-translations' facility.
</span>
<span style="color: #000000;background-color: #ffdddd">- Note that use of `asdf-output-translations' can interfere with one
-aspect of your systems -- if your system uses `*load-truename*' to find
-files (e.g., if you have some data files stored with your program),
-then the relocation that this ASDF customization performs is likely to
-interfere. Use `asdf:system-relative-pathname' to locate a file in the
</span><span style="color: #000000;background-color: #ddffdd">+ Note that use of 'asdf-output-translations' can interfere with one
+aspect of your systems -- if your system uses '*load-truename*' to find
+files (e.g., if you have some data files stored with your program), then
+the relocation that this ASDF customization performs is likely to
+interfere. Use 'asdf:system-relative-pathname' to locate a file in the
</span> source directory of some system, and use
<span style="color: #000000;background-color: #ffdddd">-`asdf:apply-output-translations' to locate a file whose pathname has
</span><span style="color: #000000;background-color: #ddffdd">+'asdf:apply-output-translations' to locate a file whose pathname has
</span> been translated by the facility.
<span style="color: #000000;background-color: #ffdddd">-12.4.2 "How can I wholly disable the compiler output cache?"
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: How can I wholly disable the compiler output cache?, Prev: How can I customize where fasl files are stored?, Up: Issues with configuring ASDF
+
+13.5.2 "How can I wholly disable the compiler output cache?"
</span> ------------------------------------------------------------
To permanently disable the compiler output cache for all future runs of
ASDF, you can:
mkdir -p ~/.config/common-lisp/asdf-output-translations.conf.d/
<span style="color: #000000;background-color: #ffdddd">- echo ':disable-cache' > ~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf
</span><span style="color: #000000;background-color: #ddffdd">+ echo ':disable-cache' > \
+ ~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf
</span>
This assumes that you didn't otherwise configure the ASDF files (if
you did, edit them again), and don't somehow override the configuration
at runtime with a shell variable (see below) or some other runtime
<span style="color: #000000;background-color: #ffdddd">-command (e.g. some call to `asdf:initialize-output-translations').
</span><span style="color: #000000;background-color: #ddffdd">+command (e.g. some call to 'asdf:initialize-output-translations').
</span>
To disable the compiler output cache in Lisp processes run by your
<span style="color: #000000;background-color: #ffdddd">-current shell, try (assuming `bash' or `zsh') (on Unix and cygwin only):
</span><span style="color: #000000;background-color: #ddffdd">+current shell, try (assuming 'bash' or 'zsh') (on Unix and cygwin only):
</span>
export ASDF_OUTPUT_TRANSLATIONS=/:
<span style="color: #aaaaaa">@@ -3742,85 +4974,80 @@ process, use (after loading ASDF but before using it):
</span>
(asdf:disable-output-translations)
<span style="color: #000000;background-color: #ffdddd">-12.5 Issues with using and extending ASDF to define systems
</span><span style="color: #000000;background-color: #ddffdd">+ Note that this does _NOT_ belong in a '.asd' file. Please do not
+tamper with ASDF configuration from a '.asd' file, and only do this from
+your personal configuration or build scripts.
+
+
+File: asdf.info, Node: Issues with using and extending ASDF to define systems, Next: ASDF development FAQs, Prev: Issues with configuring ASDF, Up: FAQ
+
+13.6 Issues with using and extending ASDF to define systems
</span> ===========================================================
<span style="color: #000000;background-color: #ffdddd">-12.5.1 "How can I cater for unit-testing in my system?"
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
+
+* How can I cater for unit-testing in my system?::
+* How can I cater for documentation generation in my system?::
+* How can I maintain non-Lisp (e.g. C) source files?::
+* I want to put my module's files at the top level. How do I do this?::
+* How do I create a system definition where all the source files have a .cl extension?::
+* How do I mark a source file to be loaded only and not compiled?::
+* How do I work with readtables?::
+
+
+File: asdf.info, Node: How can I cater for unit-testing in my system?, Next: How can I cater for documentation generation in my system?, Prev: Issues with using and extending ASDF to define systems, Up: Issues with using and extending ASDF to define systems
+
+13.6.1 "How can I cater for unit-testing in my system?"
</span> -------------------------------------------------------
<span style="color: #000000;background-color: #ffdddd">-ASDF provides a predefined test operation, `test-op'. *Note test-op:
</span><span style="color: #000000;background-color: #ddffdd">+ASDF provides a predefined test operation, 'test-op'. *Note test-op:
</span> Predefined operations of ASDF. The test operation, however, is largely
<span style="color: #000000;background-color: #ffdddd">-left to the system definer to specify. `test-op' has been a topic of
</span><span style="color: #000000;background-color: #ddffdd">+left to the system definer to specify. 'test-op' has been a topic of
</span> considerable discussion on the asdf-devel mailing list
<span style="color: #000000;background-color: #ffdddd">-(http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel), and on the
-launchpad bug-tracker (https://launchpad.net/asdf).
-
- Here are some guidelines:
-
- * For a given system, FOO, you will want to define a corresponding
- test system, such as FOO-TEST. The reason that you will want this
- separate system is that ASDF does not out of the box supply
- components that are conditionally loaded. So if you want to have
- source files (with the test definitions) that will not be loaded
- except when testing, they should be put elsewhere.
-
- * The FOO-TEST system can be defined in an asd file of its own or
- together with FOO. An aesthetic preference against cluttering up
- the filesystem with extra asd files should be balanced against the
- question of whether one might want to directly load FOO-TEST.
- Typically one would not want to do this except in early stages of
- debugging.
-
- * Record that testing is implemented by FOO-TEST. For example:
- (defsystem FOO
- :in-order-to ((test-op (test-op FOO-TEST)))
- ....)
-
- (defsystem FOO-TEST
- :depends-on (FOO MY-TEST-LIBRARY ...)
- ....)
-
- This procedure will allow you to support users who do not wish to
-install your test framework.
-
- One oddity of ASDF is that `operate' (*note operate: Operations.)
-does not return a value. So in current versions of ASDF there is no
-reliable programmatic means of determining whether or not a set of tests
-has passed, or which tests have failed. The user must simply read the
-console output. This limitation has been the subject of much
-discussion.
-
-12.5.2 "How can I cater for documentation generation in my system?"
</span><span style="color: #000000;background-color: #ddffdd">+(http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel) (*note
+Mailing list::), and on the launchpad bug-tracker
+(https://launchpad.net/asdf) (*note Where do I report a bug?::). We
+provide some guidelines in the discussion of 'test-op'.
+
+
+File: asdf.info, Node: How can I cater for documentation generation in my system?, Next: How can I maintain non-Lisp (e.g. C) source files?, Prev: How can I cater for unit-testing in my system?, Up: Issues with using and extending ASDF to define systems
+
+13.6.2 "How can I cater for documentation generation in my system?"
</span> -------------------------------------------------------------------
<span style="color: #000000;background-color: #ffdddd">-The ASDF developers are currently working to add a `doc-op' to the set
-of predefined ASDF operations. *Note Predefined operations of ASDF::.
-See also `https://bugs.launchpad.net/asdf/+bug/479470'.
</span><span style="color: #000000;background-color: #ddffdd">+Various ASDF extensions provide some kind of 'doc-op' operation. See
+also <https://bugs.launchpad.net/asdf/+bug/479470>.
+
+
+File: asdf.info, Node: How can I maintain non-Lisp (e.g. C) source files?, Next: I want to put my module's files at the top level. How do I do this?, Prev: How can I cater for documentation generation in my system?, Up: Issues with using and extending ASDF to define systems
</span>
<span style="color: #000000;background-color: #ffdddd">-12.5.3 "How can I maintain non-Lisp (e.g. C) source files?"
</span><span style="color: #000000;background-color: #ddffdd">+13.6.3 "How can I maintain non-Lisp (e.g. C) source files?"
</span> -----------------------------------------------------------
<span style="color: #000000;background-color: #ffdddd">-See `cffi''s `cffi-grovel'.
</span><span style="color: #000000;background-color: #ddffdd">+See 'cffi''s 'cffi-grovel'.
</span>
<span style="color: #000000;background-color: #ffdddd">-12.5.4 "I want to put my module's files at the top level. How do I do this?"
------------------------------------------------------------------------------
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: I want to put my module's files at the top level. How do I do this?, Next: How do I create a system definition where all the source files have a .cl extension?, Prev: How can I maintain non-Lisp (e.g. C) source files?, Up: Issues with using and extending ASDF to define systems
+
+13.6.4 "I want to put my module's files at the top level. How do I do this?"
+----------------------------------------------------------------------------
</span>
By default, the files contained in an asdf module go in a subdirectory
with the same name as the module. However, this can be overridden by
<span style="color: #000000;background-color: #ffdddd">-adding a `:pathname ""' argument to the module description. For
</span><span style="color: #000000;background-color: #ddffdd">+adding a ':pathname ""' argument to the module description. For
</span> example, here is how it could be done in the spatial-trees ASDF system
<span style="color: #000000;background-color: #ffdddd">-definition for ASDF 2:
</span><span style="color: #000000;background-color: #ddffdd">+definition for ASDF 2 or later:
</span>
<span style="color: #000000;background-color: #ffdddd">- (asdf:defsystem :spatial-trees
</span><span style="color: #000000;background-color: #ddffdd">+ (asdf:defsystem "spatial-trees"
</span> :components
<span style="color: #000000;background-color: #ffdddd">- ((:module base
</span><span style="color: #000000;background-color: #ddffdd">+ ((:module "base"
</span> :pathname ""
:components
((:file "package")
(:file "basedefs" :depends-on ("package"))
(:file "rectangles" :depends-on ("package"))))
(:module tree-impls
<span style="color: #000000;background-color: #ffdddd">- :depends-on (base)
</span><span style="color: #000000;background-color: #ddffdd">+ :depends-on ("base")
</span> :pathname ""
:components
((:file "r-trees")
<span style="color: #aaaaaa">@@ -3829,52 +5056,54 @@ definition for ASDF 2:
</span> (:file "rplus-trees" :depends-on ("r-trees"))
(:file "x-trees" :depends-on ("r-trees" "rstar-trees"))))
(:module viz
<span style="color: #000000;background-color: #ffdddd">- :depends-on (base)
</span><span style="color: #000000;background-color: #ddffdd">+ :depends-on ("base")
</span> :pathname ""
:components
((:static-file "spatial-tree-viz.lisp")))
(:module tests
<span style="color: #000000;background-color: #ffdddd">- :depends-on (base)
</span><span style="color: #000000;background-color: #ddffdd">+ :depends-on ("base")
</span> :pathname ""
:components
((:static-file "spatial-tree-test.lisp")))
(:static-file "LICENCE")
(:static-file "TODO")))
<span style="color: #000000;background-color: #ffdddd">- All of the files in the `tree-impls' module are at the top level,
-instead of in a `tree-impls/' subdirectory.
</span><span style="color: #000000;background-color: #ddffdd">+ All of the files in the 'tree-impls' module are at the top level,
+instead of in a 'tree-impls/' subdirectory.
</span>
<span style="color: #000000;background-color: #ffdddd">- Note that the argument to `:pathname' can be either a pathname
-object or a string. A pathname object can be constructed with the
-`#p"foo/bar/"' syntax, but this is discouraged because the results of
</span><span style="color: #000000;background-color: #ddffdd">+ Note that the argument to ':pathname' can be either a pathname object
+or a string. A pathname object can be constructed with the
+'#p"foo/bar/"' syntax, but this is discouraged because the results of
</span> parsing a namestring are not portable. A pathname can only be portably
<span style="color: #000000;background-color: #ffdddd">-constructed with such syntax as `#.(make-pathname :directory
-'(:relative "foo" "bar"))', and similarly the current directory can
-only be portably specified as `#.(make-pathname :directory
-'(:relative))'. However, as of ASDF 2, you can portably use a string
-to denote a pathname. The string will be parsed as a `/'-separated
-path from the current directory, such that the empty string `""'
-denotes the current directory, and `"foo/bar"' (no trailing `/'
-required in the case of modules) portably denotes the same subdirectory
-as above. When files are specified, the last `/'-separated component
-is interpreted either as the name component of a pathname (if the
-component class specifies a pathname type), or as a name component plus
-optional dot-separated type component (if the component class doesn't
-specifies a pathname type).
-
-12.5.5 How do I create a system definition where all the source files have a .cl extension?
</span><span style="color: #000000;background-color: #ddffdd">+constructed with such syntax as '#.(make-pathname :directory '(:relative
+"foo" "bar"))', and similarly the current directory can only be portably
+specified as '#.(make-pathname :directory '(:relative))'. However, as
+of ASDF 2, you can portably use a string to denote a pathname. The
+string will be parsed as a '/'-separated path from the current
+directory, such that the empty string '""' denotes the current
+directory, and '"foo/bar"' (no trailing '/' required in the case of
+modules) portably denotes the same subdirectory as above. When files
+are specified, the last '/'-separated component is interpreted either as
+the name component of a pathname (if the component class specifies a
+pathname type), or as a name component plus optional dot-separated type
+component (if the component class doesn't specifies a pathname type).
+
+
+File: asdf.info, Node: How do I create a system definition where all the source files have a .cl extension?, Next: How do I mark a source file to be loaded only and not compiled?, Prev: I want to put my module's files at the top level. How do I do this?, Up: Issues with using and extending ASDF to define systems
+
+13.6.5 How do I create a system definition where all the source files have a .cl extension?
</span> -------------------------------------------------------------------------------------------
Starting with ASDF 2.014.14, you may just pass the builtin class
<span style="color: #000000;background-color: #ffdddd">-`cl-source-file.cl' as the `:default-component-class' argument to
-`defsystem':
</span><span style="color: #000000;background-color: #ddffdd">+'cl-source-file.cl' as the ':default-component-class' argument to
+'defsystem':
</span>
(defsystem my-cl-system
:default-component-class cl-source-file.cl
...)
<span style="color: #000000;background-color: #ffdddd">- Another builtin class `cl-source-file.lsp' is offered for files
-ending in `.lsp'.
</span><span style="color: #000000;background-color: #ddffdd">+ Another builtin class 'cl-source-file.lsp' is offered for files
+ending in '.lsp'.
</span>
If you want to use a different extension for which ASDF doesn't
provide builtin support, or want to support versions of ASDF earlier
<span style="color: #aaaaaa">@@ -3894,10 +5123,10 @@ than 2.014.14 (but later than 2.000), you can define a class as follows:
</span> :default-component-class my-asdf-extension:cl-source-file.lis
...)
<span style="color: #000000;background-color: #ffdddd">- Of course, if you're in the same package, e.g. in the same file, you
-won't need to use the package qualifier before `cl-source-file.lis'.
-Actually, if all you're doing is defining this class and using it in
-the same file without other fancy definitions, you might skip package
</span><span style="color: #000000;background-color: #ddffdd">+ Of course, if you're in the same package, e.g. in the same file, you
+won't need to use the package qualifier before 'cl-source-file.lis'.
+Actually, if all you're doing is defining this class and using it in the
+same file without other fancy definitions, you might skip package
</span> complications:
(in-package :asdf)
<span style="color: #aaaaaa">@@ -3907,155 +5136,219 @@ complications:
</span> :default-component-class cl-source-file.lis
...)
<span style="color: #000000;background-color: #ffdddd">- It is possible to achieve the same effect in a way that supports
-both ASDF 1 and ASDF 2, but really, friends don't let friends use ASDF
-1. Please upgrade to ASDF 3. In short, though: do same as above, but
-_before_ you use the class in a `defsystem', you also define the
-following method:
-
- (defmethod source-file-type ((f cl-source-file.lis) (s system))
- (declare (ignorable f s))
- "lis")
-
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: TODO list, Next: Inspiration, Prev: FAQ, Up: Top
-
-13 TODO list
-************
-
-Here is an old list of things to do, in addition to the bugs that are
-now tracked on launchpad: `https://launchpad.net/asdf'.
-
-13.1 Outstanding spec questions, things to add
-==============================================
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: How do I mark a source file to be loaded only and not compiled?, Next: How do I work with readtables?, Prev: How do I create a system definition where all the source files have a .cl extension?, Up: Issues with using and extending ASDF to define systems
</span>
<span style="color: #000000;background-color: #ffdddd">-** packaging systems
</span><span style="color: #000000;background-color: #ddffdd">+13.6.6 How do I mark a source file to be loaded only and not compiled?
+----------------------------------------------------------------------
</span>
<span style="color: #000000;background-color: #ffdddd">- *** manual page component?
-
- ** style guide for .asd files
-
- You should either use keywords or be careful with the package that
-you evaluate defsystem forms in. Otherwise `(defsystem partition ...)'
-being read in the `cl-user' package will intern a `cl-user:partition'
-symbol, which will then collide with the `partition:partition' symbol.
-
- Actually there's a hairier packages problem to think about too.
-`in-order-to' is not a keyword: if you read `defsystem' forms in a
-package that doesn't use ASDF, odd things might happen.
-
- ** extending defsystem with new options
-
- You might not want to write a whole parser, but just to add options
-to the existing syntax. Reinstate `parse-option' or something akin.
-
- ** Diagnostics
-
- A "dry run" of an operation can be made with the following form:
-
- (let ((asdf::*verbose-out* *standard-output*))
- (loop :for (op . comp) :in
- (asdf::traverse (make-instance '<operation-name> :force t)
- (asdf:find-system <system-name>))
- :do (asdf:explain op comp)))
-
- This uses unexported symbols. What would be a nice interface for
-this functionality?
-
-13.2 Missing bits in implementation
-===================================
-
-** reuse the same scratch package whenever a system is reloaded from
-disk
-
- Have a package ASDF-USER instead of all these temporary packages?
-
- ** proclamations probably aren't
-
- ** A revert function
-
- Other possible interface: have a "revert" function akin to `make
-clean'.
-
- (asdf:revert 'asdf:compile-op 'araneida)
-
- would delete any files produced by `(compile-system :araneida)'. Of
-course, it wouldn't be able to do much about stuff in the image itself.
-
- How would this work?
-
- `traverse'
-
- There's a difference between a module's dependencies (peers) and its
-components (children). Perhaps there's a similar difference in
-operations? For example, `(load "use") depends-on (load "macros")' is
-a peer, whereas `(load "use") depends-on (compile "use")' is more of a
-"subservient" relationship.
</span><span style="color: #000000;background-color: #ddffdd">+There is no provision in ASDF for ensuring that some components are
+always loaded as source, while others are always compiled. There is
+'load-source-op' (*note load-source-op: Predefined operations of ASDF.),
+but that is an operation to be applied to a system as a whole, not to
+one or another specific source files. While this idea often comes up in
+discussions, it doesn't play well with either the linking model of ECL
+or with various bundle operations. In addition, the dependency model of
+ASDF would have to be modified incompatibly to allow for such a trick.
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: Inspiration, Next: Concept Index, Prev: TODO list, Up: Top
-
-14 Inspiration
-**************
-
-14.1 mk-defsystem (defsystem-3.x)
-=================================
-
-We aim to solve basically the same problems as `mk-defsystem' does.
-However, our architecture for extensibility better exploits CL language
-features (and is documented), and we intend to be portable rather than
-just widely-ported. No slight on the `mk-defsystem' authors and
-maintainers is intended here; that implementation has the unenviable
-task of supporting pre-ANSI implementations, which is no longer
-necessary.
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: How do I work with readtables?, Prev: How do I mark a source file to be loaded only and not compiled?, Up: Issues with using and extending ASDF to define systems
</span>
<span style="color: #000000;background-color: #ffdddd">- The surface defsystem syntax of asdf is more-or-less compatible with
-`mk-defsystem', except that we do not support the `source-foo' and
-`binary-foo' prefixes for separating source and binary files, and we
-advise the removal of all options to specify pathnames.
</span><span style="color: #000000;background-color: #ddffdd">+13.6.7 How do I work with readtables?
+-------------------------------------
</span>
<span style="color: #000000;background-color: #ffdddd">- The `mk-defsystem' code for topologically sorting a module's
-dependency list was very useful.
</span><span style="color: #000000;background-color: #ddffdd">+It is possible to configure the lisp syntax by modifying the
+currently-active readtable. However, this same readtable is shared
+globally by all software being compiled by ASDF, especially since 'load'
+and 'compile-file' both bind *READTABLE*, so that its value is the same
+across the build at the start of every file (unless overridden by some
+'perform :around' method), even if a file locally binds it to a
+different readtable during the build.
+
+ Therefore, the following hygiene restrictions apply. If you don't
+abide by these restrictions, there will be situations where your output
+files will be corrupted during an incremental build. We are not trying
+to prescribe new restrictions for the sake of good style: these
+restrictions have always applied implicitly, and we are simply
+describing what they have always been.
+
+ * It is forbidden to modifying any standard character or standard
+ macro dispatch defined in the CLHS.
+ * No two dependencies may assign different meanings to the same
+ non-standard character.
+ * Using any non-standard character while expecting the implementation
+ to treat some way counts as such an assignment of meaning.
+ * libraries need to document these assignments of meaning to
+ non-standard characters.
+ * free software libraries will register these changes on:
+ <http://www.cliki.net/Macro%20Characters>
+
+ If you want to use readtable modifications that cannot abide by those
+restrictions, you _must_ create a different readtable object and set
+*READTABLE* to temporarily bind it to your new readtable (which will be
+undone after processing the file).
+
+ For that, we recommend you use system 'named-readtables' to define or
+combine such readtables using 'named-readtables:defreadtable' and use
+them using 'named-readtables:in-readtable'. Equivalently, you can use
+system 'cl-syntax', that itself uses 'named-readtables', but may someday
+do more with, e.g. *PRINT-PPRINT-DISPATCH*.
+
+ For even more advanced syntax modification beyond what a readtable
+can express, you may consider either:
+ * a 'perform' method that compiles a constant file that contains a
+ single form '#.*code-read-with-alternate-reader*' in an environment
+ where this special variable was bound to the code read by your
+ alternate reader, or
+ * using the system 'reader-interception'.
+
+ Beware that it is unsafe to use ASDF from the REPL to compile or load
+systems while the readtable isn't the shared readtable previously used
+to build software. You _must_ manually undo any binding of *READTABLE*
+at the REPL and restore its initial value whenever you call 'operate'
+(via e.g. 'load-system', 'test-system' or 'require') from a REPL that
+is using a different readtable.
+
+13.6.7.1 How should my system use a readtable exported by another system?
+.........................................................................
+
+Use from the 'named-readtables' system the macro
+'named-readtables:in-readtable'.
+
+ If the other system fails to use 'named-readtables', fix it and send
+a patch upstream. In the day and age of Quicklisp and clbuild, there is
+little reason to eschew using such an important library anymore.
+
+13.6.7.2 How should my library make a readtable available to other systems?
+...........................................................................
+
+Use from the 'named-readtables' system the macro
+'named-readtables:defreadtable'.
</span>
<span style="color: #000000;background-color: #ffdddd">-14.2 defsystem-4 proposal
-=========================
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: ASDF development FAQs, Prev: Issues with using and extending ASDF to define systems, Up: FAQ
</span>
<span style="color: #000000;background-color: #ffdddd">-Marco and Peter's proposal for defsystem 4 served as the driver for
-many of the features in here. Notable differences are:
</span><span style="color: #000000;background-color: #ddffdd">+13.7 ASDF development FAQs
+==========================
</span>
<span style="color: #000000;background-color: #ffdddd">- * We don't specify output files or output file extensions as part of
- the system.
</span><span style="color: #000000;background-color: #ddffdd">+* Menu:
</span>
<span style="color: #000000;background-color: #ffdddd">- If you want to find out what files an operation would create, ask
- the operation.
</span><span style="color: #000000;background-color: #ddffdd">+* How do I run the tests interactively in a REPL?::
</span>
<span style="color: #000000;background-color: #ffdddd">- * We don't deal with CL packages
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: How do I run the tests interactively in a REPL?, Prev: ASDF development FAQs, Up: ASDF development FAQs
+
+13.7.1 How do I run the tests interactively in a REPL?
+------------------------------------------------------
+
+This not-so-frequently asked question is primarily for ASDF developers,
+but those who encounter an unexpected error in some test may be
+interested, too.
+
+ Here's the procedure for experimenting with tests in a REPL:
+ ;; BEWARE! Some tests expect you to be in the .../asdf/test directory
+ ;; If your REPL is not there yet, change your current directory:
+ ;; under SLIME, you may: ,change-directory ~/common-lisp/asdf/test/
+ ;; otherwise you may evaluate something like:
+ (require "asdf") (asdf:upgrade-asdf) ;load UIOP & update asdf.lisp
+ (uiop:chdir (asdf:system-relative-pathname :asdf "test/"))
+ (setf *default-pathname-defaults* (uiop:getcwd))
+
+ ;; Load the test script support.
+ (load "script-support.lisp")
+
+ ;; Initialize the script support.
+ ;; This will also change your *package* to asdf-test.
+ ;; NB: this function is also available from package cl-user,
+ ;; and also available with the shorter name da in both packages.
+ (asdf-test::debug-asdf)
+
+ ;; In case you modified ASDF since you last tested it,
+ ;; you need to update asdf.lisp itself by evaluating 'make' in a shell,
+ ;; or (require "asdf") (asdf:load-system :asdf) in another CL REPL,
+ ;; if not done in this REPL above.
+ ;; *Then*, in this REPL, you need to evaluate:
+ ;(asdf-test::compile-load-asdf)
+
+ ;; Now, you may experiment with test code from a .script file.
+ ;; See the instructions given at the end of your failing test
+ ;; to identify which form is needed, e.g.
+ (frob-packages)
+ (asdf::with-asdf-cache () (load "test-utilities.script"))
</span>
<span style="color: #000000;background-color: #ffdddd">- If you want to compile in a particular package, use an
- `in-package' form in that file (ilisp / SLIME will like you more
- if you do this anyway)
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Ongoing Work, Next: Bibliography, Prev: FAQ, Up: Top
</span>
<span style="color: #000000;background-color: #ffdddd">- * There is no proposal here that `defsystem' does version control.
</span><span style="color: #000000;background-color: #ddffdd">+Ongoing Work
+************
</span>
<span style="color: #000000;background-color: #ffdddd">- A system has a given version which can be used to check
- dependencies, but that's all.
</span><span style="color: #000000;background-color: #ddffdd">+For an active list of things to be done, see the 'TODO' file in the
+source repository.
</span>
<span style="color: #000000;background-color: #ffdddd">- The defsystem 4 proposal tends to look more at the external features,
-whereas this one centres on a protocol for system introspection.
</span><span style="color: #000000;background-color: #ddffdd">+ Also, bugs are currently tracked on launchpad:
+<https://launchpad.net/asdf>.
</span>
<span style="color: #000000;background-color: #ffdddd">-14.3 kmp's "The Description of Large Systems", MIT AI Memo 801
-==============================================================
</span><span style="color: #000000;background-color: #ddffdd">+
+File: asdf.info, Node: Bibliography, Next: Concept Index, Prev: Ongoing Work, Up: Top
</span>
<span style="color: #000000;background-color: #ffdddd">-Available in updated-for-CL form on the web at
-`http://nhplace.com/kent/Papers/Large-Systems.html'
</span><span style="color: #000000;background-color: #ddffdd">+Bibliography
+************
</span>
<span style="color: #000000;background-color: #ffdddd">- In our implementation we borrow kmp's overall `PROCESS-OPTIONS' and
-concept to deal with creating component trees from `defsystem' surface
-syntax. [ this is not true right now, though it used to be and
-probably will be again soon ]
</span><span style="color: #000000;background-color: #ddffdd">+ * Francois-Rene Rideau: "ASDF 3, or Why Lisp is Now an Acceptable
+ Scripting Language", 2014. This article describes the innovations
+ in ASDF 3 and 3.1, as well as historical information on previous
+ versions. <https://github.com/fare/asdf3-2013>
+ * Alastair Bridgewater: "Quick-build" (private communication), 2012.
+ 'quick-build' is a simple and robust one file, one package build
+ system, similar to 'faslpath', in 182 lines of code (117 of which
+ are not blank, not comments, not docstrings). Unhappily, it
+ remains unpublished and its IP status is unclear as of April 2014.
+ 'asdf/package-system' is mostly compatible with it, modulo a
+ different setup for toplevel hierarchies.
+ * Zach Beane: "Quicklisp", 2011. The Quicklisp blog and Xach's
+ livejournal contain information on Quicklisp.
+ <http://blog.quicklisp.org/> <http://xach.livejournal.com/>
+ * Francois-Rene Rideau and Robert Goldman: "Evolving ASDF: More
+ Cooperation, Less Coordination", 2010. This article describes the
+ main issues solved by ASDF 2.
+ <https://common-lisp.net/project/asdf/doc/ilc2010draft.pdf>
+ <https://gitlab.common-lisp.org/asdf/ilc2010>
+ * Francois-Rene Rideau and Spencer Brody: "XCVB: an eXtensible
+ Component Verifier and Builder for Common Lisp", 2009. This
+ article describes XCVB, a proposed competitor for ASDF; many of its
+ ideas have been incorporated into ASDF 2 and 3, though many other
+ ideas still haven't. <https://common-lisp.net/project/xcvb/>
+ * Peter von Etter: "faslpath", 2009. 'faslpath' is similar to the
+ latter 'quick-build' and our yet latter 'asdf/package-system'
+ extension, except that it uses dot '.' rather than slash '/' as a
+ separator. <https://code.google.com/p/faslpath/>
+ * Drew McDermott: "A Framework for Maintaining the Coherence of a
+ Running Lisp," International Lisp Conference, 2005, available in
+ pre-print form at
+ <http://www.cs.yale.edu/homes/dvm/papers/lisp05.pdf>
+ * Dan Barlow: "ASDF Manual", 2004. Older versions of this document
+ from the days of ASDF 1; they include ideas laid down by Dan
+ Barlow, and comparisons with older defsystems ('mk-defsystem') and
+ defsystem ('defsystem-4', kmp's Memo 801).
+ * Marco Antoniotti and Peter Van Eynde: "'DEFSYSTEM': A 'make' for
+ Common Lisp, A Thoughtful Re-Implementation of an Old Idea", 2002.
+ The 'defsystem-4' proposal available in the CLOCC repository.
+ * Mark Kantrovitz: "Defsystem: A Portable Make Facility for Common
+ Lisp", 1990. The classic 'mk-defsystem', later variants of which
+ are available in the CLOCC repository as 'defsystem-3.x'.
+ * Richard Elliot Robbins: "BUILD: A Tool for Maintaining Consistency
+ in Modular Systems", MIT AI TR 874, 1985.
+ <ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-874.pdf>
+ * Kent M. Pitman (kmp): "The Description of Large Systems", MIT AI
+ Memo 801, 1984. Available in updated-for-CL form on the web at
+ <http://nhplace.com/kent/Papers/Large-Systems.html>
+ * Dan Weinreb and David Moon: "Lisp Machine Manual", MIT, 1981. The
+ famous CHINE NUAL describes one of the earliest variants of
+ DEFSYSTEM.
+ <https://bitsavers.trailing-edge.com/pdf/mit/cadr/chinual_4thEd_Jul81.pdf>
</span>
<span style="color: #000000;background-color: #ffdddd">-File: asdf.info, Node: Concept Index, Next: Function and Class Index, Prev: Inspiration, Up: Top
</span><span style="color: #000000;background-color: #ddffdd">+File: asdf.info, Node: Concept Index, Next: Function and Class Index, Prev: Bibliography, Up: Top
</span>
Concept Index
*************
<span style="color: #aaaaaa">@@ -4063,48 +5356,92 @@ Concept Index
</span> [index ]
* Menu:
<span style="color: #000000;background-color: #ffdddd">-* :around-compile: Miscellaneous additional functionality.
- (line 12)
</span><span style="color: #000000;background-color: #ddffdd">+* *features*: How do I detect the ASDF version?.
+ (line 6)
+* :also-exclude source config directive: Configuration DSL. (line 6)
+* :around-compile: Controlling file compilation.
+ (line 6)
</span> * :asdf: Introduction. (line 6)
* :asdf2: Introduction. (line 6)
* :asdf3: Introduction. (line 6)
<span style="color: #000000;background-color: #ffdddd">-* :compile-check: Miscellaneous additional functionality.
- (line 12)
</span><span style="color: #000000;background-color: #ddffdd">+* :compile-check: Controlling file compilation.
+ (line 6)
+* :default-registry source config directive: Configuration DSL.
+ (line 6)
</span> * :defsystem-depends-on: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">- (line 106)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 120)
+* :directory source config directive: Configuration DSL. (line 6)
+* :exclude source config directive: Configuration DSL. (line 6)
+* :if-component-dep-fails component option: The defsystem grammar.
+ (line 382)
+* :if-feature component option: The defsystem grammar.
+ (line 359)
+* :ignore-invalid-entries source config directive: Configuration DSL.
+ (line 6)
+* :include source config directive: Configuration DSL. (line 6)
+* :inherit-configuration source config directive: Configuration DSL.
+ (line 6)
+* :require dependencies: The defsystem grammar.
+ (line 248)
+* :tree source config directive: Configuration DSL. (line 6)
+* :version: The defsystem form. (line 68)
</span> * :version <1>: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">- (line 214)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 217)
</span> * :version <2>: Common attributes of components.
<span style="color: #000000;background-color: #ffdddd">- (line 22)
-* :version: The defsystem form. (line 76)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 23)
</span> * :weakly-depends-on: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">- (line 114)
-* around-compile keyword: Miscellaneous additional functionality.
- (line 12)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 128)
+* also-exclude source config directive: Configuration DSL. (line 6)
+* around-compile keyword: Controlling file compilation.
+ (line 6)
</span> * ASDF versions: Introduction. (line 6)
<span style="color: #000000;background-color: #ffdddd">-* ASDF-BINARY-LOCATIONS compatibility: Controlling where ASDF saves compiled files.
- (line 81)
</span><span style="color: #000000;background-color: #ddffdd">+* ASDF-BINARY-LOCATIONS compatibility: Output Backward Compatibility.
+ (line 6)
</span> * asdf-output-translations: Controlling where ASDF saves compiled files.
(line 6)
* ASDF-related features: Introduction. (line 6)
<span style="color: #000000;background-color: #ffdddd">-* compile-check keyword: Miscellaneous additional functionality.
- (line 12)
</span><span style="color: #000000;background-color: #ddffdd">+* asdf-user: The defsystem form. (line 6)
+* ASDF-USER package: Components. (line 41)
+* bug tracker: Where do I report a bug?.
+ (line 6)
+* compile-check keyword: Controlling file compilation.
+ (line 6)
</span> * component: Components. (line 6)
* component designator: Components. (line 6)
<span style="color: #000000;background-color: #ffdddd">-* link farm: Loading ASDF. (line 6)
</span><span style="color: #000000;background-color: #ddffdd">+* default-registry source config directive: Configuration DSL.
+ (line 6)
+* DEFSYSTEM grammar: The defsystem grammar.
+ (line 6)
+* directory source config directive: Configuration DSL. (line 6)
+* exclude source config directive: Configuration DSL. (line 6)
+* ignore-invalid-entries source config directive: Configuration DSL.
+ (line 6)
+* immutable systems: Operations. (line 65)
+* immutable systems <1>: Miscellaneous Functions.
+ (line 91)
+* include source config directive: Configuration DSL. (line 6)
+* inherit-configuration source config directive: Configuration DSL.
+ (line 6)
+* launchpad: Where do I report a bug?.
+ (line 6)
</span> * logical pathnames: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">- (line 233)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 258)
+* mailing list: Mailing list. (line 6)
</span> * operation: Operations. (line 6)
* pathname specifiers: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">- (line 143)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 150)
+* Primary system name: Components. (line 70)
+* readtables: How do I work with readtables?.
+ (line 6)
</span> * serial dependencies: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">- (line 279)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 304)
</span> * system: Components. (line 6)
* system designator: Components. (line 6)
<span style="color: #000000;background-color: #ffdddd">-* system directory designator: Loading ASDF. (line 6)
</span><span style="color: #000000;background-color: #ddffdd">+* System names: Components. (line 70)
</span> * Testing for ASDF: Introduction. (line 6)
<span style="color: #000000;background-color: #ddffdd">+* tree source config directive: Configuration DSL. (line 6)
</span> * version specifiers: The defsystem grammar.
<span style="color: #000000;background-color: #ffdddd">- (line 214)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 217)
</span>
File: asdf.info, Node: Function and Class Index, Next: Variable Index, Prev: Concept Index, Up: Top
<span style="color: #aaaaaa">@@ -4115,88 +5452,167 @@ Function and Class Index
</span> [index ]
* Menu:
<span style="color: #000000;background-color: #ffdddd">-* already-loaded-systems: Using ASDF. (line 80)
-* apply-output-translations: Controlling where ASDF saves compiled files.
- (line 356)
-* clear-configuration: Using ASDF. (line 11)
-* clear-output-translations <1>: Configuring ASDF. (line 114)
-* clear-output-translations: Controlling where ASDF saves compiled files.
- (line 341)
-* clear-source-registry: Controlling where ASDF searches for systems.
- (line 372)
-* clear-system: Miscellaneous additional functionality.
- (line 207)
-* compile-file*: Miscellaneous additional functionality.
- (line 12)
-* compile-op: Predefined operations of ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+* already-loaded-systems: Convenience Functions.
+ (line 25)
+* apply-output-translations: Output location API. (line 36)
+* asdf-version: How do I detect the ASDF version?.
+ (line 6)
+* binary-op (obsolete): What happened to the bundle operations.
+ (line 6)
+* clear-configuration: Resetting the ASDF configuration.
+ (line 10)
+* clear-output-translations: Configuring where ASDF stores object files.
+ (line 6)
+* clear-output-translations <1>: Output location API. (line 22)
+* clear-source-registry: Configuration API. (line 19)
+* clear-system: Miscellaneous Functions.
+ (line 34)
+* coerce-name: Creating new operations.
+ (line 70)
+* coerce-name <1>: Components. (line 140)
+* coerce-name <2>: Common attributes of components.
</span> (line 12)
<span style="color: #000000;background-color: #ffdddd">-* compile-system: Loading ASDF. (line 6)
-* concatenate-source-op: Predefined operations of ASDF.
- (line 167)
-* disable-output-translations: Controlling where ASDF saves compiled files.
- (line 336)
-* enable-asdf-binary-locations-compatibility: Controlling where ASDF saves compiled files.
- (line 107)
-* ensure-output-translations: Controlling where ASDF saves compiled files.
- (line 351)
-* ensure-source-registry: Controlling where ASDF searches for systems.
- (line 381)
-* fasl-op: Predefined operations of ASDF.
- (line 94)
-* find-component: Components. (line 56)
-* find-system: Components. (line 18)
-* initialize-output-translations: Controlling where ASDF saves compiled files.
- (line 327)
-* initialize-source-registry: Controlling where ASDF searches for systems.
- (line 363)
-* load-op: Predefined operations of ASDF.
</span><span style="color: #000000;background-color: #ddffdd">+* compile-bundle-op: What happened to the bundle operations.
+ (line 6)
+* 'compile-bundle-op': Predefined operations of ASDF.
+ (line 93)
+* compile-file*: Controlling file compilation.
+ (line 6)
+* 'compile-op': Predefined operations of ASDF.
+ (line 11)
+* compile-system: Convenience Functions.
+ (line 6)
+* component: The object model of ASDF.
+ (line 6)
+* component-depends-on: Creating new operations.
+ (line 45)
+* component-pathname: Common attributes of components.
+ (line 155)
+* 'concatenate-source-op': Predefined operations of ASDF.
+ (line 178)
+* defsystem: The defsystem form. (line 6)
+* defsystem <1>: A more involved example.
+ (line 6)
+* defsystem <2>: The defsystem grammar.
+ (line 6)
+* deliver-asd-op: What happened to the bundle operations.
+ (line 6)
+* disable-output-translations: Output location API. (line 17)
+* enable-asdf-binary-locations-compatibility: Output Backward Compatibility.
+ (line 27)
+* ensure-output-translations: Output location API. (line 31)
+* ensure-source-registry: Configuration API. (line 28)
+* fasl-op (obsolete): What happened to the bundle operations.
+ (line 6)
+* file-type: Pitfalls of the transition to ASDF 2.
+ (line 77)
+* find-component: Creating new operations.
+ (line 70)
+* find-component <1>: Components. (line 132)
+* find-system: Components. (line 21)
+* initialize-output-translations: Output location API. (line 8)
+* initialize-source-registry: Configuration API. (line 10)
+* input-files: Creating new operations.
+ (line 81)
+* input-files <1>: Creating new operations.
+ (line 88)
+* load-asd: The defsystem form. (line 6)
+* load-bundle-op: What happened to the bundle operations.
+ (line 6)
+* load-fasl-op (obsolete): What happened to the bundle operations.
+ (line 6)
+* 'load-op': Predefined operations of ASDF.
+ (line 25)
+* 'load-source-op': Predefined operations of ASDF.
+ (line 45)
+* load-system: Convenience Functions.
+ (line 6)
+* load-system <1>: Convenience Functions.
</span> (line 25)
<span style="color: #000000;background-color: #ffdddd">-* load-source-op: Predefined operations of ASDF.
- (line 42)
-* load-system: Loading ASDF. (line 6)
-* merge-pathnames*: Miscellaneous additional functionality.
- (line 329)
</span><span style="color: #000000;background-color: #ddffdd">+* locate-system: Components. (line 97)
+* make: Convenience Functions.
+ (line 6)
+* merge-pathnames*: Some Utility Functions.
+ (line 62)
</span> * module: Pre-defined subclasses of component.
(line 23)
<span style="color: #000000;background-color: #ffdddd">-* oos <1>: Operations. (line 31)
-* oos: Loading ASDF. (line 6)
-* operate <1>: Operations. (line 29)
-* operate: Loading ASDF. (line 6)
-* OPERATION-ERROR: Error handling. (line 6)
-* parse-unix-namestring: Miscellaneous additional functionality.
- (line 282)
-* prepare-op: Predefined operations of ASDF.
- (line 36)
-* register-preloaded-system: Miscellaneous additional functionality.
- (line 239)
-* require-system: Loading ASDF. (line 6)
-* run-program: Miscellaneous additional functionality.
- (line 355)
-* run-shell-command: Miscellaneous additional functionality.
- (line 252)
-* slurp-input-stream: Miscellaneous additional functionality.
- (line 430)
</span><span style="color: #000000;background-color: #ddffdd">+* monolithic-binary-op (obsolete): What happened to the bundle operations.
+ (line 6)
+* monolithic-compile-bundle-op: What happened to the bundle operations.
+ (line 6)
+* monolithic-deliver-asd-op: What happened to the bundle operations.
+ (line 6)
+* monolithic-fasl-op (obsolete): What happened to the bundle operations.
+ (line 6)
+* monolithic-load-bundle-op: What happened to the bundle operations.
+ (line 6)
+* monolithic-load-fasl-op (obsolete): What happened to the bundle operations.
+ (line 6)
+* oos: Convenience Functions.
+ (line 13)
+* 'oos': Operations. (line 33)
+* operate: Convenience Functions.
+ (line 13)
+* 'operate': Operations. (line 31)
+* operation: The object model of ASDF.
+ (line 6)
+* operation-done-p: Creating new operations.
+ (line 92)
+* OPERATION-ERROR: Error handling. (line 5)
+* output-files: Creating new operations.
+ (line 33)
+* parse-unix-namestring: Some Utility Functions.
+ (line 12)
+* perform: Creating new operations.
+ (line 19)
+* 'prepare-op': Predefined operations of ASDF.
+ (line 38)
+* primary-system-name: Components. (line 70)
+* primary-system-name <1>: Components. (line 91)
+* register-immutable-system: Operations. (line 65)
+* register-immutable-system <1>: Miscellaneous Functions.
+ (line 75)
+* register-preloaded-system: Miscellaneous Functions.
+ (line 61)
+* require-system: Convenience Functions.
+ (line 6)
+* require-system <1>: Convenience Functions.
+ (line 25)
+* run-program: Some Utility Functions.
+ (line 89)
+* run-shell-command: Miscellaneous Functions.
+ (line 93)
+* slurp-input-stream: Some Utility Functions.
+ (line 161)
</span> * source-file: Pre-defined subclasses of component.
<span style="color: #000000;background-color: #ffdddd">- (line 7)
-* source-file-type: FAQ. (line 287)
-* subpathname: Miscellaneous additional functionality.
- (line 338)
-* subpathname*: Miscellaneous additional functionality.
- (line 350)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 6)
+* source-file-type: Pitfalls of the transition to ASDF 2.
+ (line 77)
+* subpathname: Some Utility Functions.
+ (line 71)
+* subpathname*: Some Utility Functions.
+ (line 84)
</span> * system: Pre-defined subclasses of component.
<span style="color: #000000;background-color: #ffdddd">- (line 50)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 51)
</span> * SYSTEM-DEFINITION-ERROR: Error handling. (line 6)
<span style="color: #000000;background-color: #ffdddd">-* system-relative-pathname: Miscellaneous additional functionality.
- (line 182)
-* system-source-directory: Miscellaneous additional functionality.
- (line 199)
-* test-op: Predefined operations of ASDF.
- (line 60)
-* test-system: Loading ASDF. (line 6)
-* VERSION: Functions. (line 7)
-* version-satisfies <1>: Functions. (line 6)
</span><span style="color: #000000;background-color: #ddffdd">+* system-defsystem-depends-on: Information about system dependencies.
+ (line 10)
+* system-depends-on: Information about system dependencies.
+ (line 12)
+* system-relative-pathname: Miscellaneous Functions.
+ (line 8)
+* system-source-directory: Miscellaneous Functions.
+ (line 25)
+* system-weakly-depends-on: Information about system dependencies.
+ (line 14)
+* 'test-op': Predefined operations of ASDF.
+ (line 52)
+* test-system: Convenience Functions.
+ (line 6)
+* traverse: Operations. (line 73)
</span> * version-satisfies: Common attributes of components.
<span style="color: #000000;background-color: #ffdddd">- (line 22)
</span><span style="color: #000000;background-color: #ddffdd">+ (line 23)
+* version-satisfies <1>: Functions. (line 6)
</span>
File: asdf.info, Node: Variable Index, Prev: Function and Class Index, Up: Top
<span style="color: #aaaaaa">@@ -4207,54 +5623,160 @@ Variable Index
</span> [index ]
* Menu:
<span style="color: #000000;background-color: #ffdddd">-* *central-registry*: Loading ASDF. (line 6)
-* *compile-file-errors-behavior*: Error handling. (line 19)
</span><span style="color: #000000;background-color: #ddffdd">+* *compile-file-failure-behaviour*: Error handling. (line 19)
</span> * *compile-file-warnings-behaviour*: Error handling. (line 19)
<span style="color: #000000;background-color: #ffdddd">-* *default-source-registry-exclusions*: Controlling where ASDF searches for systems.
- (line 319)
</span><span style="color: #000000;background-color: #ddffdd">+* *default-source-registry-exclusions*: Search Algorithm. (line 6)
</span> * *features*: Introduction. (line 6)
<span style="color: #000000;background-color: #ddffdd">+* *image-dump-hook*: Resetting the ASDF configuration.
+ (line 14)
+* *load-system-operation*: Convenience Functions.
+ (line 25)
+* *nil-pathname*: Some Utility Functions.
+ (line 43)
+* *oldest-forward-compatible-asdf-version*: Pitfalls of the upgrade to ASDF 3.
+ (line 83)
+* *source-registry-parameter*: *source-registry-parameter* variable.
+ (line 6)
</span> * *system-definition-search-functions*: Components. (line 6)
<span style="color: #000000;background-color: #ddffdd">+* 'asdf::*user-cache*': Output Configuration DSL.
+ (line 118)
</span> * ASDF_OUTPUT_TRANSLATIONS: Controlling where ASDF saves compiled files.
(line 6)
Tag Table:
<span style="color: #000000;background-color: #ffdddd">-Node: Top1687
-Node: Introduction3739
-Node: Loading ASDF5819
-Node: Configuring ASDF13441
-Ref: Configuring ASDF-Footnote-121589
-Ref: Configuring ASDF-Footnote-221821
-Node: Using ASDF22534
-Node: Defining systems with defsystem26836
-Node: The defsystem form27222
-Ref: The defsystem form-Footnote-130809
-Node: A more involved example30892
-Node: The defsystem grammar32924
-Node: Other code in .asd files48535
-Node: The object model of ASDF49625
-Node: Operations54177
-Ref: operate55087
-Node: Predefined operations of ASDF57060
-Ref: test-op59879
-Node: Creating new operations66512
-Node: Components71498
-Node: Common attributes of components75247
-Node: Pre-defined subclasses of component81739
-Node: Creating new component types84100
-Node: Functions85476
-Node: Controlling where ASDF searches for systems87299
-Node: Controlling where ASDF saves compiled files108946
-Node: Error handling126833
-Node: Miscellaneous additional functionality127665
-Node: Getting the latest version153111
-Node: FAQ154137
-Ref: report-bugs175672
-Node: TODO list180560
-Node: Inspiration182961
-Node: Concept Index185261
-Node: Function and Class Index188478
-Node: Variable Index194871
</span><span style="color: #000000;background-color: #ddffdd">+Node: Top1684
+Node: Introduction7633
+Node: Quick start summary9936
+Node: Loading ASDF11643
+Node: Loading a pre-installed ASDF11945
+Ref: Loading a pre-installed ASDF-Footnote-113758
+Node: Checking whether ASDF is loaded13940
+Node: Upgrading ASDF14854
+Node: Replacing your implementation's ASDF15842
+Node: Loading ASDF from source17265
+Node: Configuring ASDF18366
+Node: Configuring ASDF to find your systems19139
+Ref: Configuring ASDF to find your systems-Footnote-122444
+Ref: Configuring ASDF to find your systems-Footnote-222691
+Ref: Configuring ASDF to find your systems-Footnote-322973
+Node: Configuring ASDF to find your systems --- old style23434
+Ref: Configuring ASDF to find your systems --- old style-Footnote-125861
+Ref: Configuring ASDF to find your systems --- old style-Footnote-226093
+Ref: Configuring ASDF to find your systems --- old style-Footnote-326860
+Node: Configuring where ASDF stores object files27016
+Node: Resetting the ASDF configuration28419
+Node: Using ASDF29476
+Node: Loading a system29687
+Node: Convenience Functions30704
+Ref: Convenience Functions-Footnote-133849
+Node: Moving on33927
+Node: Defining systems with defsystem34298
+Node: The defsystem form34726
+Node: A more involved example38132
+Ref: A more involved example-Footnote-145114
+Node: The defsystem grammar45796
+Ref: if-feature-option61935
+Node: Other code in .asd files63767
+Node: The package-inferred-system extension64903
+Node: The object model of ASDF69170
+Ref: The object model of ASDF-Footnote-171500
+Ref: The object model of ASDF-Footnote-271852
+Node: Operations72179
+Ref: operate73284
+Node: Predefined operations of ASDF75767
+Ref: test-op77882
+Node: Creating new operations85765
+Node: Components90978
+Ref: System names94462
+Ref: Components-Footnote-199134
+Ref: Components-Footnote-299430
+Node: Common attributes of components99752
+Ref: required-features101314
+Node: Pre-defined subclasses of component107161
+Node: Creating new component types109595
+Node: Dependencies110885
+Node: Functions112756
+Node: Controlling where ASDF searches for systems114590
+Node: Configurations115212
+Node: Truenames and other dangers118687
+Node: XDG base directory119973
+Node: Backward Compatibility121387
+Node: Configuration DSL122103
+Node: Configuration Directories127658
+Node: The here directive129485
+Node: Shell-friendly syntax for configuration131378
+Node: Search Algorithm132395
+Node: Caching Results133896
+Node: Configuration API137140
+Node: Introspection139179
+Node: *source-registry-parameter* variable139443
+Node: Information about system dependencies140012
+Node: Status140928
+Node: Rejected ideas141383
+Node: TODO143764
+Node: Credits for the source-registry143949
+Node: Controlling where ASDF saves compiled files144484
+Ref: Controlling where ASDF saves compiled files-Footnote-1145896
+Node: Output Configurations145940
+Ref: Output Configurations-Footnote-1148801
+Node: Output Backward Compatibility148867
+Node: Output Configuration DSL151593
+Node: Output Configuration Directories157048
+Node: Output Shell-friendly syntax for configuration158605
+Node: Semantics of Output Translations159914
+Node: Output Caching Results161483
+Node: Output location API161963
+Node: Credits for output translations164385
+Node: Error handling164905
+Node: Miscellaneous additional functionality165746
+Node: Controlling file compilation166218
+Node: Controlling source file character encoding169484
+Node: Miscellaneous Functions176299
+Ref: system-relative-pathname176596
+Ref: Miscellaneous Functions-Footnote-1182220
+Node: Some Utility Functions182331
+Node: Getting the latest version193059
+Node: FAQ194004
+Node: Where do I report a bug?194399
+Node: Mailing list194764
+Node: What has changed between ASDF 1 ASDF 2 and ASDF 3?195099
+Node: What are ASDF 1 2 3?197273
+Node: How do I detect the ASDF version?198314
+Node: ASDF can portably name files in subdirectories200621
+Node: Output translations202171
+Node: Source Registry Configuration203198
+Node: Usual operations are made easier to the user204825
+Node: Many bugs have been fixed205411
+Node: ASDF itself is versioned207243
+Node: ASDF can be upgraded208118
+Node: Decoupled release cycle209270
+Node: Pitfalls of the transition to ASDF 2210199
+Node: Pitfalls of the upgrade to ASDF 3214469
+Ref: Pitfalls of the upgrade to ASDF 3-Footnote-1218836
+Node: What happened to the bundle operations219006
+Node: Issues with installing the proper version of ASDF220108
+Node: My Common Lisp implementation comes with an outdated version of ASDF. What to do?220579
+Node: I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?221512
+Node: Issues with configuring ASDF225395
+Node: How can I customize where fasl files are stored?225770
+Node: How can I wholly disable the compiler output cache?226863
+Node: Issues with using and extending ASDF to define systems228242
+Node: How can I cater for unit-testing in my system?228966
+Node: How can I cater for documentation generation in my system?229855
+Node: How can I maintain non-Lisp (e.g. C) source files?230376
+Ref: report-bugs230808
+Node: I want to put my module's files at the top level. How do I do this?230808
+Node: How do I create a system definition where all the source files have a .cl extension?233958
+Node: How do I mark a source file to be loaded only and not compiled?235931
+Node: How do I work with readtables?236927
+Node: ASDF development FAQs240613
+Node: How do I run the tests interactively in a REPL?240852
+Node: Ongoing Work242718
+Node: Bibliography242997
+Node: Concept Index246433
+Node: Function and Class Index252725
+Node: Variable Index264553
</span>
End Tag Table
</code></pre>
<br>
</li>
<li id='diff-3'>
<a href='https://gitlab.common-lisp.net/cmucl/cmucl/compare/b239ce3f44b62821701e3447437705d3d914a5b4...1d034d24f6c87575de73422e32cdca5501d37ef5#diff-3'>
<strong>
src/contrib/asdf/doc/asdf.pdf
</strong>
</a>
<hr>
<pre class="highlight"><code>Binary files a/src/contrib/asdf/doc/asdf.pdf and b/src/contrib/asdf/doc/asdf.pdf differ
</code></pre>
<br>
</li>
</div>
<div class='footer' style='margin-top: 10px;'>
<p>
—
<br>
<a href="https://gitlab.common-lisp.net/cmucl/cmucl/compare/b239ce3f44b62821701e3447437705d3d914a5b4...1d034d24f6c87575de73422e32cdca5501d37ef5">View it on GitLab</a>
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":["merge_requests","issues","commit"],"url":"https://gitlab.common-lisp.net/cmucl/cmucl/compare/b239ce3f44b62821701e3447437705d3d914a5b4...1d034d24f6c87575de73422e32cdca5501d37ef5"}}</script>
</p>
</div>
</body>
</html>