[cmucl/cmucl][master] 2 commits: Add asdf documentation.

Raymond Toy rtoy at common-lisp.net
Fri Apr 17 03:41:34 UTC 2015


Raymond Toy pushed to master at cmucl / cmucl


Commits:
64f8e6a9 by Raymond Toy at 2015-04-16T20:25:33Z
Add asdf documentation.

- - - - -
48c324f4 by Raymond Toy at 2015-04-16T20:41:01Z
Install the asdf docs too.

Also, install the asdf/defsystem sources before the fasls so that the
fasls have a newer timestamp than the source.

- - - - -


4 changed files:

- bin/make-main-dist.sh
- + src/contrib/asdf/doc/asdf.html
- + src/contrib/asdf/doc/asdf.info
- + src/contrib/asdf/doc/asdf.pdf


Changes:

=====================================
bin/make-main-dist.sh
=====================================
--- a/bin/make-main-dist.sh
+++ b/bin/make-main-dist.sh
@@ -126,11 +126,11 @@ do
     install ${GROUP} ${OWNER} -m 0644 $f $DESTDIR/lib/cmucl/lib/ext-formats/
 done
 
-# Create the directories and install the fasl files for asdf and defsystem
-for f in asdf defsystem
+set -x
+# Create the directories for asdf and defsystem
+for f in asdf defsystem asdf/doc
 do
     install -d ${GROUP} ${OWNER} -m 0755 $DESTDIR/lib/cmucl/lib/contrib/$f
-    install ${GROUP} ${OWNER} -m 0644 $TARGET/contrib/$f/$f.$FASL $DESTDIR/lib/cmucl/lib/contrib/$f
 done
 
 # Copy the source files for asdf and defsystem
@@ -139,6 +139,19 @@ do
     install ${GROUP} ${OWNER} -m 0644 src/$f $DESTDIR/lib/cmucl/lib/$f
 done
 
+# Install the fasl files for asdf and defsystem
+for f in asdf defsystem
+do
+    install ${GROUP} ${OWNER} -m 0644 $TARGET/contrib/$f/$f.$FASL $DESTDIR/lib/cmucl/lib/contrib/$f
+done
+
+# Install the docs for asdf
+for f in src/contrib/asdf/doc/*
+do
+    base=`basename $f`
+    install ${GROUP} ${OWNER} -m 0644 $f $DESTDIR/lib/cmucl/lib/contrib/asdf/doc/$base
+done
+
 install ${GROUP} ${OWNER} -m 0644 src/general-info/cmucl.1 \
 	$DESTDIR/${MANDIR}/
 install ${GROUP} ${OWNER} -m 0644 src/general-info/lisp.1 \

=====================================
src/contrib/asdf/doc/asdf.html
=====================================
--- /dev/null
+++ b/src/contrib/asdf/doc/asdf.html
@@ -0,0 +1,4661 @@
+<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
+for Common Lisp programs and libraries.
+
+You can find the latest version of this manual at
+`http://common-lisp.net/project/asdf/asdf.html'.
+
+ASDF Copyright (C) 2001-2013 Daniel Barlow and contributors.
+
+This manual Copyright (C) 2001-2013 Daniel Barlow and contributors.
+
+This manual revised (C) 2009-2013 Robert P. Goldman and Francois-Rene Rideau.
+
+Permission is hereby granted, free of charge, to any person obtaining
+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:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+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.-->
+<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>
+
+
+
+<!--  -->
+<p><a name="Top"></a>
+
+<h2 class="unnumbered">asdf: another system definition facility</h2>
+
+<p>This manual describes ASDF, a system definition facility
+for Common Lisp programs and libraries.
+
+   <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>.
+
+   <p>ASDF Copyright © 2001-2013 Daniel Barlow and contributors.
+
+   <p>This manual Copyright © 2001-2013 Daniel Barlow and contributors.
+
+   <p>This manual revised © 2009-2013 Robert P. Goldman and Francois-Rene Rideau.
+
+   <p>Permission is hereby granted, free of charge, to any person obtaining
+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:
+
+   <p>The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+   <p>THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
+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.
+
+<!--  -->
+<p><a name="Introduction"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h2 class="chapter">1 Introduction</h2>
+
+<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:
+a tool for specifying how 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.
+
+   <p>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 software who want to specify how to build their systems,
+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. 
+See <a href="#Defining-systems-with-defsystem">Defining systems with defsystem</a>,
+to learn how to define a system of your own. 
+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.
+
+   <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>.
+
+   <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.
+
+<p><a name="Loading-ASDF"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h2 class="chapter">2 Loading ASDF</h2>
+
+<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 -->
+
+<h3 class="section">2.1 Loading a pre-installed ASDF</h3>
+
+<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:
+
+<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.
+
+   <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.
+
+   <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.
+
+<h3 class="section">2.3 Upgrading ASDF</h3>
+
+<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.
+
+   <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:
+
+<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>
+
+<h3 class="section">2.4 Loading an otherwise installed ASDF</h3>
+
+<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:
+
+<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.
+
+   <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>.
+
+   <p>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.
+
+<p><a name="Configuring-ASDF"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h2 class="chapter">3 Configuring ASDF</h2>
+
+<h3 class="section">3.1 Configuring ASDF to find your systems</h3>
+
+<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.
+
+   <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>.
+
+   <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.
+
+   <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:
+
+   <p><kbd>(:directory "/home/luser/.asd-link-farm/")</kbd>
+
+   <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:
+
+   <p><kbd>(:tree "/home/luser/lisp/")</kbd>
+
+   <p>Note that your Operating System distribution or your system administrator
+may already have configured system-managed libraries for you.
+
+   <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.
+
+   <p>ASDF will automatically read your configuration
+the first time you try to find a system. 
+You can reset the source-registry configuration with:
+
+<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.
+
+<h3 class="section">3.2 Configuring ASDF to find your systems — old style</h3>
+
+<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>.
+
+   <p>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 starts
+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:
+
+<pre class="lisp">     (push "/home/me/src/foo/" asdf:*central-registry*)
+</pre>
+   <p>Note the trailing slash: when searching for a system,
+ASDF will evaluate each entry of the central registry
+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
+in a common directory
+and push <em>that</em> directory (the “link farm”)
+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.
+
+<h3 class="section">3.3 Configuring where ASDF stores object files</h3>
+
+<p><a name="index-clear_002doutput_002dtranslations-17"></a>
+ASDF lets you configure where object files will be stored. 
+Sensible defaults are provided and
+you shouldn't normally have to worry about it.
+
+   <p>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.
+
+   <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. 
+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>.
+
+   <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:
+
+   <p><kbd>("/foo/bar/baz/quux/" "/where/i/want/my/fasls/")</kbd>
+
+   <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:
+
+   <p><kbd>("/toto/tata/")</kbd>
+
+   <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:
+
+   <p><kbd>(t t)</kbd>
+
+   <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.
+
+   <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.
+
+   <p>ASDF will automatically read your configuration
+the first time you try to find a system. 
+You can reset the source-registry configuration with:
+
+<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,
+other ASDF add-ons offered the same 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 just delegate this functionality to ASDF.
+
+<p><a name="Using-ASDF"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h3 class="section">3.4 Resetting Configuration</h3>
+
+<p>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:
+
+<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>
+
+<h3 class="section">4.1 Loading a system</h3>
+
+<p>The system <var>foo</var> is loaded (and compiled, if necessary)
+by evaluating the following Lisp form:
+
+<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:
+
+<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. 
+The name must be a suitable value for the <code>:name</code> initarg
+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
+
+<h3 class="section">4.2 Other Operations</h3>
+
+<p>ASDF provides three commands for the most common system operations:
+<code>load-system</code>, <code>compile-system</code> or <code>test-system</code>. 
+It also provides <code>require-system</code>, a version of <code>load-system</code>
+that skips trying to update systems that are already loaded.
+
+   <p>Because ASDF is an extensible system
+for defining <em>operations</em> on <em>components</em>,
+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
+compiling, loading and testing.
+
+   <p>Output from ASDF and ASDF extensions are supposed to be sent
+to the CL stream <code>*standard-output*</code>,
+and so rebinding that stream around calls to <code>asdf:operate</code>
+should redirect all output from ASDF operations.
+
+   <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.
+
+   </ul>
+
+<h3 class="section">4.4 Moving on</h3>
+
+<p>That's all you need to know to use ASDF to load systems written by others. 
+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.
+
+<p><a name="Defining-systems-with-defsystem"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h2 class="chapter">5 Defining systems with defsystem</h2>
+
+<p>This chapter describes how to use asdf to define systems and develop
+software.
+
+<p><a name="The-defsystem-form"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h3 class="section">5.1 The defsystem form</h3>
+
+<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,
+then gives the full grammar of <code>defsystem</code>.
+
+   <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 at 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>
+that contains three source files:
+<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.
+
+     <p><a name="index-g_t_003aversion-20"></a>
+</ul>
+
+<p><a name="A-more-involved-example"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h3 class="section">5.2 A more involved example</h3>
+
+<p>Let's illustrate some more involved uses of <code>defsystem</code> via a
+slightly convoluted example:
+
+<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>).
+
+   <p>The method-form tokens provide a shorthand for defining methods on
+particular components.  This part
+
+<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
+
+<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. 
+In this case <code>...</code> would expand to something like
+
+<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>. 
+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>.
+
+<!-- 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>
+
+<p>Component names (<code>simple-component-name</code>)
+may be either strings or symbols.
+
+<h4 class="subsection">5.3.2 Component types</h4>
+
+<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>.
+
+   <p><code>system</code> and its subclasses are <em>not</em>
+allowed as component types for such children components.
+
+<h4 class="subsection">5.3.3 System class names</h4>
+
+<p>A system class name will be looked up
+in the same way as a Component type (see above),
+except that only <code>system</code> and its subclasses are allowed. 
+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
+
+<pre class="example">     :class :MY-NEW-SYSTEM-SUBCLASS
+</pre>
+   <p>This practice will ensure that package name conflicts are avoided. 
+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.
+
+<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
+programmer to specify another ASDF-defined system or set of systems that
+must be loaded <em>before</em> the system definition is processed. 
+Typically this is used to load an ASDF extension that is used in the
+system definition.
+
+<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. 
+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,
+and offer some special variable and/or some hook to specialize its behavior;
+then you should write a system <var>foo+bar</var>
+that does the hooking of things together.
+
+   <p>The (deprecated) <code>:weakly-depends-on</code> option to <code>defsystem</code>
+allows the programmer to specify another ASDF-defined system or set of systems
+that ASDF should <em>try</em> to load,
+but need not load in order to be successful. 
+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.
+
+   <p>Currently, although it is specified to be an option only to <code>defsystem</code>,
+this option is accepted at any component, but it probably
+only makes sense at the <code>defsystem</code> level. 
+Programmers are cautioned not
+to use this component option except at the <code>defsystem</code> level, as
+this anomalous behavior may be removed without warning.
+
+   <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>.
+
+<h4 class="subsection">5.3.6 Pathname specifiers</h4>
+
+<p><a name="index-pathname-specifiers-23"></a>
+A pathname specifier (<code>pathname-specifier</code>)
+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.
+
+   <p>If a string is given, which is the usual case,
+the string will be interpreted as a Unix-style pathname
+where <code>/</code> characters will be interpreted as directory separators. 
+Usually, Unix-style relative pathnames are used
+(i.e. not starting with <code>/</code>, as opposed to absolute pathnames);
+they are relative to the path of the parent component. 
+Finally, depending on the <code>component-type</code>,
+the pathname may be interpreted as either a file or a directory,
+and if it's a file,
+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).
+
+   <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>. 
+On the other hand, the <code>component-type</code> <code>:file</code>
+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>. 
+Finally, the <code>component-type</code> <code>:static-file</code>
+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. 
+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 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.
+
+   <p>Pathname objects may be given to override the path for a component. 
+Such objects are typically specified using reader macros such as <code>#p</code>
+or <code>#.(make-pathname ...)</code>. 
+Note however, that <code>#p...</code> is
+a shorthand for <code>#.(parse-namestring ...)</code>
+and that the behavior of <code>parse-namestring</code> is completely non-portable,
+unless you are using Common Lisp <code>logical-pathname</code>s,
+which themselves involve other non-portable behavior
+(see <a href="#The-defsystem-grammar">Using logical pathnames</a>, below). 
+Pathnames made with <code>#.(make-pathname ...)</code>
+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 <code>#.(make-pathname ...)</code> syntax had to be used. 
+An alternative to <code>#.</code> read-time evaluation is to use
+<code>(eval `(defsystem ... ,pathname ...))</code>.
+
+   <p>Note that when specifying pathname objects,
+ASDF does not do any 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.
+
+<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>,
+quite unlike what would have happened
+had the version strings been interpreted as decimal fractions.
+
+   <p>System definers are encouraged to use version identifiers of the form
+<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.
+
+   <p>See <a href="#Common-attributes-of-components">Common attributes of components</a>.
+
+<h4 class="subsection">5.3.8 Using logical pathnames</h4>
+
+<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. 
+However, we do support the use of logical pathnames by old timers,
+when such is their preference.
+
+   <p>To use logical pathnames,
+you will have to provide a pathname object as a <code>:pathname</code> specifier
+to components that use it, using such syntax as
+<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,
+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 <em>not</em>
+otherwise directly supported in the ASDF syntax
+for pathname specifiers as strings.
+
+   <p>The <code>asdf-output-translation</code> layer will
+avoid trying to resolve and 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 translations,
+any system that uses logical pathnames will behave differently under
+asdf-output-translations than other systems you use.
+
+   <p>If you wish to use logical pathnames you will have to configure the
+translations yourself before they may be used. 
+ASDF currently provides no specific support
+for defining logical pathname translations.
+
+   <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,
+(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 implementations supported by ASDF
+is more than we can document. 
+As for the second issue, mind that the limitation is notably enforced on SBCL,
+and that you therefore can't portably violate the limitations
+but must instead define some encoding of your own and add individual mappings
+to name physical pathnames that do not fit the restrictions. 
+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.
+
+<h4 class="subsection">5.3.9 Serial dependencies</h4>
+
+<p><a name="index-serial-dependencies-27"></a>
+If the <code>:serial t</code> option is specified for a module,
+ASDF will add dependencies for each child component,
+on all the children textually preceding it. 
+This is done as if by <code>:depends-on</code>.
+
+<pre class="lisp">     :serial t
+     :components ((:file "a") (:file "b") (:file "c"))
+</pre>
+   <p>is equivalent to
+
+<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>
+
+<p>The <code>:pathname</code> option is optional in all cases for systems
+defined via <code>defsystem</code>,
+and in the usual case the user is recommended not to supply it.
+
+   <p>Instead, ASDF follows a hairy set of rules that are designed so that
+     <ol type=1 start=1>
+<li><code>find-system</code>
+will load a system from disk
+and have its pathname default to the right place.
+
+     <li>This pathname information will not be overwritten with
+<code>*default-pathname-defaults*</code>
+(which could be somewhere else altogether)
+if the user loads up the <samp><span class="file">.asd</span></samp> file into his editor
+and interactively re-evaluates that form.
+        </ol>
+
+   <p>If a system is being loaded for the first time,
+its top-level pathname will be set to:
+
+     <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>
+(so that an updated source location is reflected in the system definition)
+
+     <li>changed if it had previously been set from <code>*default-pathname-defaults*</code>
+
+     <li>left as before, if it had previously been set from <code>*load-truename*</code>
+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)
+</ul>
+
+<h4 class="subsection">5.3.11 if-feature option</h4>
+
+<p>This option allows you to specify a feature expression to be evaluated
+as if by <code>#+</code> to conditionally include a component in your build. 
+If the expression is false, the component is dropped
+as well as any dependency pointing to it. 
+As compared to using <code>#+</code> which is expanded at read-time,
+this allows you to have an object in your component hierarchy
+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. 
+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 <code>if-feature</code> option instead.
+
+<p><a name="Other-code-in-.asd-files"></a>
+<a name="Other-code-in-_002easd-files"></a>
+
+<h3 class="section">5.4 Other code in .asd files</h3>
+
+<p>Files containing <code>defsystem</code> forms
+are regular Lisp files that are executed by <code>load</code>. 
+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 <code>defsystem</code> extensions
+that you use with <code>:defsystem-depends-on</code>.
+
+   <p>If however, you might insist on including code in the <code>.asd</code> file itself,
+e.g., to examine and adjust the compile-time environment,
+possibly adding appropriate features to <code>*features*</code>. 
+If so, here are some conventions we recommend you follow,
+so that users can control certain details of execution
+of the Lisp in <samp><span class="file">.asd</span></samp> files:
+
+     <ul>
+<li>Any informative output
+(other than warnings and errors,
+which are the condition system's to dispose of)
+should be sent to the standard CL stream <code>*standard-output*</code>,
+so that users can easily control the disposition
+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.
+
+   <p>This chapter deals with <code>component</code>s and <code>operation</code>s.
+
+   <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.
+
+   <p>An <code>Operation</code> represents a transformation that can be performed on a component,
+turning them from source files to intermediate results to final outputs.
+
+   <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>
+
+<p><a name="index-operation-28"></a>
+An <dfn>operation</dfn> object of the appropriate type is instantiated
+whenever the user wants to do something with a system like
+
+     <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. 
+There are a bunch of methods specialised on operation and component type
+that actually do the grunt work.
+
+   <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.
+
+        <p>The <var>initargs</var> are passed to the <code>make-instance</code> call
+when creating 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 <var>initargs</var> as the original one.
+
+        <p>If <var>force</var> is <code>:all</code>, then all systems
+are forced to be recompiled even if not modified since last compilation. 
+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,
+but other systems are not affected. 
+If <var>force</var> is a list, then it specifies a list of systems that
+are forced to be recompiled even if not modified since last compilation. 
+If <var>force-not</var> is <code>:all</code>, then all systems
+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. 
+If <var>force-not</var> is a list, then it specifies a list of systems that
+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.
+
+        <p>To see what <code>operate</code> would do, you can use:
+     <pre class="example">          (asdf:traverse operation-class system-name)
+</pre>
+        </blockquote></div>
+
+<p><a name="Predefined-operations-of-ASDF"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h4 class="subsection">6.1.1 Predefined operations of ASDF</h4>
+
+<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.
+
+<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. 
+All the children and dependencies of a system or module
+will be recursively compiled by <code>compile-op</code>.
+
+        <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. 
+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,
+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. 
+A <code>cl-source-file</code> will have its compiled fasl <code>load</code>ed,
+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
+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
+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. 
+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>.
+
+        <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. 
+The default dependency is to require
+<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
+—
+we assume that if you invoke the <code>test-op</code>,
+you want to test the system, even if you have already done so.
+
+        <p>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.
+
+        <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”
+for all the contents of each system in an application,
+or for the entire application.
+
+        <p><code>fasl-op</code> 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. 
+<code>monolithic-fasl-op</code> will create a single fasl file for target system
+and all its dependencies,
+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>,
+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;
+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>. 
+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,
+<em>before</em> you try to use any newly created <samp><span class="file">.asd</span></samp> files,
+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.
+
+        <p>The <code>program-op</code> operation will create an executable program
+from 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 point <code>my-app:main</code>
+by specifying in your <code>defsystem</code>
+the option <code>:entry-point "my-app:main"</code>. 
+Depending on your implementation,
+running <code>(asdf:operate 'asdf:program-op :my-app)</code>
+may quit the current Lisp image upon completion. 
+See the example in
+<samp><span class="file">test/hello-world-example.asd</span></samp> and <samp><span class="file">test/hello.lisp</span></samp>,
+as built and tested by
+<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>)
+from all linkable object dependencies (FFI files, and on ECL, Lisp files too),
+and its monolithic equivalent <code>monolithic-lib-op</code>. 
+And there is also <code>dll-op</code>
+(respectively its monolithic equivalent <code>monolithic-lib-op</code>)
+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>)
+to create a single dynamic library
+for all the extra FFI code to be linked into each of your systems
+(respectively your entire application).
+
+        <p>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 separate system <code>asdf-bundle</code>,
+itself descended from the ECL-only <code>asdf-ecl</code>.
+
+        <p>The pathname of the output of bundle operations
+is subject to output-translation as usual,
+unless the operation is equal to
+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
+(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.
+
+        <p>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.
+
+        <p>ASDF itself is notably delivered as a single source file this way
+using <code>monolithic-concatenate-source-op</code>,
+transcluding a prelude and the <code>uiop</code> library
+before the <code>asdf/defsystem</code> system itself. 
+</p></blockquote></div>
+
+<p><a name="Creating-new-operations"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h4 class="subsection">6.1.2 Creating new operations</h4>
+
+<p>ASDF was designed to be extensible in an object-oriented fashion. 
+To teach ASDF new tricks, a programmer can implement the behaviour he wants
+by creating a subclass of <code>operation</code>.
+
+   <p>ASDF's pre-defined operations are in no way “privileged”,
+but it is requested that developers never use the <code>asdf</code> package
+for operations they develop themselves. 
+The rationale for this rule is that we don't want to establish a
+“global asdf operation name registry”,
+but also want to avoid name clashes.
+
+   <p>Your operation <em>must</em> usually provide methods
+for one or more of the following generic functions:
+
+     <ul>
+<li><code>perform</code>
+Unless your operation, like <code>prepare-op</code>,
+is for dependency propagation only,
+the most important function for which to define a method
+is usually <code>perform</code>,
+which will be called to perform the operation on a specified component,
+after all dependencies have been performed.
+
+     <p>The <code>perform</code> method must call <code>output-files</code> (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 <code>output-files</code>. 
+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.
+
+     <li><code>output-files</code>
+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.
+
+     <p>Your method may return two values, a list of pathnames, and a boolean. 
+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
+in some implementation-dependent cache. 
+If the boolean is <code>t</code> then the pathnames are marked
+not be translated by the enclosing <code>:around</code> method.
+
+     <li><code>component-depends-on</code>
+If the action of performing the operation on a component has dependencies,
+you must define a method on <code>component-depends-on</code>.
+
+     <p>Your method will take as specialized arguments
+an operation and a component which together identify an action,
+and return a list of entries describing actions that this action depends on. 
+The format of entries is described below.
+
+     <p>It is <em>strongly</em> advised that
+you should always append the results of <code>(call-next-method)</code>
+to the results of your method,
+or “interesting” failures will likely occur,
+unless you're a true specialist of ASDF internals. 
+It is unhappily too late to compatibly use the <code>append</code> method combination,
+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:
+either an operation object designating itself, or
+a symbol that names an operation class
+(that ASDF will instantiate using <code>make-operation</code>). 
+For instance, <code>load-op</code>, <code>compile-op</code> and <code>prepare-op</code>
+are common such names, denoting the respective operations.
+
+     <p>The rest of each entry is a list of component designators:
+either a component object designating itself,
+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. 
+The identifier is typically a string,
+a symbol (to be downcased as per <code>coerce-name</code>),
+or a list of strings or symbols. 
+In particular, the empty list <code>nil</code> denotes the parent itself.
+
+   </ul>
+
+   <p>An operation <em>may</em> provide methods for the following generic functions:
+
+     <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.
+
+     <li><code>operation-done-p</code>
+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>).
+
+     <p>For instance, the method for <code>test-op</code> always returns <code>nil</code>,
+so that tests are always run afresh. 
+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>.
+
+   </ul>
+
+   <p>Operations that print output should send that output to the standard
+CL stream <code>*standard-output*</code>, as the Lisp compiler and loader do.
+
+<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
+that can be found via <code>find-system</code>.
+
+   <p>A <dfn>system designator</dfn> is a system itself,
+or a string or symbol that behaves just like any other component name
+(including with regard to the case conversion rules for component names).
+
+   <p>A <dfn>component designator</dfn>, relative to a base component,
+is either a component itself,
+or a string or symbol,
+or a list of designators.
+
+<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. 
+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.
+
+        <p>To find and update systems, <code>find-system</code> funcalls each element
+in the <code>*system-definition-search-functions*</code> list,
+expecting a 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:
+
+          <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
+of the system in memory
+</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.
+
+        <p>The default value of <code>*system-definition-search-functions*</code>
+is a list of two functions. 
+The first function looks in each of the directories given
+by evaluating members of <code>*central-registry*</code>
+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. 
+The second function does something similar,
+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),
+and a <var>path</var>, find the component designated by the <var>path</var>
+starting from the <var>base</var>.
+
+        <p>If <var>path</var> is a component object, it designates itself,
+independently from the base.
+
+        <p>If <var>path</var> is a string, or symbol denoting a string via <code>coerce-name</code>,
+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>.
+
+        <p>If <var>path</var> is a <code>cons</code> cell,
+<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
+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>,
+it designates a system as per <code>find-system</code>.
+
+        <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>
+
+<p><a name="Common-attributes-of-components"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h4 class="subsection">6.2.1 Common attributes of components</h4>
+
+<p>All components, regardless of type, have the following attributes. 
+All attributes except <code>name</code> are optional.
+
+<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,
+the name will be interpreted as a pathname specifier according
+to a Unix-style syntax. 
+See <a href="#The-defsystem-grammar">Pathname specifiers</a>.
+
+<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. 
+The version should typically be a string of integers separated by dots,
+for example ‘<samp><span class="samp">1.0.11</span></samp>’. 
+For more information on version specifiers, see <a href="#The-defsystem-grammar">The defsystem grammar</a>.
+
+   <p>A version may then be queried by the generic function <code>version-satisfies</code>,
+to see if <code>:version</code> dependencies are satisfied,
+and when specifying dependencies, a constraint of minimal version to satisfy
+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>. 
+Presumably it is much less useful within a given system,
+wherein the library author is responsible to keep the various files in synch.
+
+<h5 class="subsubsection">6.2.1.3 Required features</h5>
+
+<p>Traditionally defsystem users have used <code>#+</code> 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.
+
+   <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. 
+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.
+
+   <p>For instance, <code>:if-feature (:and :x86 (:or :sbcl :cmu :scl))</code> 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. 
+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>
+
+<p>This attribute specifies dependencies of the component on its siblings. 
+It is optional but often necessary.
+
+   <p>There is an excitingly complicated relationship between the initarg
+and the method that you use to ask about dependencies
+
+   <p>Dependencies are between (operation component) pairs. 
+In your initargs for the component, you can say
+
+<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
+load-op on <var>a</var> and <var>b</var>, and compile-op on <var>c</var>,
+<li>before performing <code>load-op</code>, we have to load <var>foo</var>
+</ul>
+
+   <p>The syntax is approximately
+
+<pre class="verbatim">(this-op @{(other-op required-components)@}+)
+
+simple-component-name := string
+                      |  symbol
+
+required-components := simple-component-name
+                     | (required-components required-components)
+
+component-name := simple-component-name
+                | (:version simple-component-name minimum-version-object)
+</pre>
+
+   <p>Side note:
+
+   <p>This is on a par with what ACL defsystem does. 
+mk-defsystem is less general: it has an implied dependency
+
+<pre class="verbatim">  for all source file x, (load x) depends on (compile x)
+</pre>
+
+   <p>and using a <code>:depends-on</code> argument to say that <var>b</var> depends on
+<var>a</var> <em>actually</em> means that
+
+<pre class="verbatim">  (compile b) depends on (load a)
+</pre>
+
+   <p>This is insufficient for e.g. the McCLIM system, which requires that
+all the files are loaded before any of them can be compiled ]
+
+   <p>End side note
+
+   <p>In ASDF, the dependency information for a given component and operation
+can be queried using <code>(component-depends-on operation component)</code>,
+which returns a list
+
+<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
+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.
+
+   <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. 
+If you have the time for some CLISP hacking,
+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. 
+See the discussion of the semantics of <code>:version</code>
+in the defsystem grammar.
+
+<!-- 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>
+
+<p>This attribute is optional and if absent (which is the usual case),
+the component name will be used.
+
+   <p>See <a href="#The-defsystem-grammar">Pathname specifiers</a>,
+for an explanation of how this attribute is interpreted.
+
+   <p>Note that the <code>defsystem</code> macro (used to create a “top-level” system)
+does additional processing to set the filesystem location of
+the top component in that system. 
+This is detailed elsewhere. See <a href="#Defining-systems-with-defsystem">Defining systems with defsystem</a>.
+
+<h5 class="subsubsection">6.2.1.6 properties</h5>
+
+<p>This attribute is optional.
+
+   <p>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.
+
+   <p><code>(component-property component property-name)</code> and
+associated <code>setf</code> method will allow
+the programmatic update of this information. 
+Property names are compared as if by <code>EQL</code>,
+so use symbols or keywords or something.
+
+<p><a name="Pre-defined-subclasses-of-component"></a>
+<a name="Pre_002ddefined-subclasses-of-component"></a>
+
+<!-- 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
+generate from other components of the system.
+
+        <p>Note that this is not necessarily the same thing as
+“a file containing data that is typically fed to a compiler”. 
+If a file is generated by some pre-processor stage
+(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. 
+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.
+
+        <p>Subclasses of source-file exist for various languages. 
+<em>FIXME: describe these.</em>
+</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.
+
+        <p>A module component has the following extra initargs:
+
+          <ul>
+<li><code>:components</code> the components contained in this module
+
+          <li><code>:default-component-class</code>
+All children components which don't specify their class explicitly
+are inferred to be of this type.
+
+          <li><code>:if-component-dep-fails</code>
+This attribute was removed in ASDF 3. Do not use it. 
+Use <code>:if-feature</code> instead.
+
+          <li><code>:serial</code> When this attribute is set,
+each subcomponent of this component is assumed to depend on all subcomponents
+before it in the list given to <code>:components</code>, i.e. 
+all of them are loaded before a compile or load operation is performed on it.
+
+        </ul>
+
+        <p>The default operation knows how to traverse a module, so
+most operations will not need to provide methods specialised on modules.
+
+        <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. 
+See <a href="#The-defsystem-grammar">The defsystem grammar</a>.
+
+        <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>
+
+<p>New component types are defined by subclassing one of the existing
+component classes and specializing methods on the new component class.
+
+   <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
+functionality that we want to isolate
+in one subdirectory per Lisp implementation our system supports. 
+We create a subclass of
+<code>cl-source-file</code>:
+
+<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
+of an <code>unportable-cl-source-file</code>.
+
+<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.
+
+        <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. 
+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>.
+
+        <p>Note that in versions of ASDF prior to 3.0.1,
+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);
+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 with ASDF 3.0.1,
+<code>version-satisfies</code> does not treat the major version number specially,
+and returns T simply if the first argument designates a version that isn't older
+than the one specified as a second argument. 
+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
+as well as an inclusive lower bound. 
+</p></blockquote></div>
+
+<p><a name="Controlling-where-ASDF-searches-for-systems"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h2 class="chapter">7 Controlling where ASDF searches for systems</h2>
+
+<h3 class="section">7.1 Configurations</h3>
+
+<p>Configurations specify paths where to find system files.
+
+     <ol type=1 start=1>
+
+     <li>The search registry may use some hardcoded wrapping registry specification. 
+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.
+
+     <li>An application may explicitly initialize the source-registry configuration
+using the configuration API
+(see <a href="#Controlling-where-ASDF-searches-for-systems">Configuration API</a>, 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.
+
+     <li>The source registry will be configured from
+the environment variable <code>CL_SOURCE_REGISTRY</code> if it exists.
+
+     <li>The source registry will be configured from
+user configuration file
+<samp><span class="file">$XDG_CONFIG_DIRS/common-lisp/source-registry.conf</span></samp>
+(which defaults to
+<samp><span class="file">~/.config/common-lisp/source-registry.conf</span></samp>)
+if it exists.
+
+     <li>The source registry will be configured from
+user configuration directory
+<samp><span class="file">$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/</span></samp>
+(which defaults to
+<samp><span class="file">~/.config/common-lisp/source-registry.conf.d/</span></samp>)
+if it exists.
+
+     <li>The source registry will be configured from
+system configuration file
+<samp><span class="file">/etc/common-lisp/source-registry.conf</span></samp>
+if it exists/
+
+     <li>The source registry will be configured from
+system configuration directory
+<samp><span class="file">/etc/common-lisp/source-registry.conf.d/</span></samp>
+if it exists.
+
+     <li>The source registry will be configured from a default 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 initialized) as well as
+<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.
+
+        </ol>
+
+   <p>Each of these configurations is specified as an s-expression
+in a trivial domain-specific language (defined below). 
+Additionally, a more shell-friendly syntax is available
+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
+includes its inherited configuration.
+
+   <p>Additionally, some implementation-specific directories
+may be automatically prepended to whatever directories are specified
+in configuration files, no matter if the last one inherits or not.
+
+<h3 class="section">7.2 Truenames and other dangers</h3>
+
+<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
+that is easy to control programmatically. 
+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.
+
+   <p>Addtionally, some people dislike truename,
+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,
+and not to other files in the same intended project. 
+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>.
+
+   <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>
+
+<p>Note that we purport to respect the XDG base directory specification
+as to where configuration files are located,
+where data files are located,
+where output file caches are located. 
+Mentions of XDG variables refer to that document.
+
+   <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
+to customize how applications behave to his preferences.
+
+   <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. 
+Since support for querying the Windows registry
+is not possible to do in reasonable amounts of portable Common Lisp code,
+ASDF 3 relies on the environment variables that Windows usually exports.
+
+<h3 class="section">7.4 Backward Compatibility</h3>
+
+<p>For backward compatibility as well as to provide a practical backdoor for hackers,
+ASDF will first search for <code>.asd</code> files in the directories specified in
+<code>asdf:*central-registry*</code>
+before it searches in the source registry above.
+
+   <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,
+but will take precedence over the new mechanism if you do use it.
+
+<h3 class="section">7.5 Configuration DSL</h3>
+
+<p>Here is the grammar of the s-expression (SEXP) DSL for source-registry
+configuration:
+
+<!-- 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. 
+The DSL is resolved by the function <code>asdf::resolve-location</code>,
+to be documented and exported at some point in the future.
+
+<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>,
+which is the default place ASDF looks for this configuration, once contained:
+<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>
+
+<p>Configuration directories consist in files each containing
+a list of directives without any enclosing <code>(:source-registry ...)</code> form. 
+The files will be sorted by namestring as if by <code>string<</code> and
+the lists of directives of these files with be concatenated in order. 
+An implicit <code>:inherit-configuration</code> will be included
+at the <em>end</em> of the list.
+
+   <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,
+the names of files in 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 <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
+or namestring in an <code>:include</code> directive, e.g.:
+
+<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,
+I could simply create a file
+<samp><span class="file">~/.config/common-lisp/source-registry.conf.d/33-home-fare-cl.conf</span></samp>
+alone in its directory with the following contents:
+<pre class="example">     (:tree "/home/fare/cl/")
+</pre>
+   <h4 class="subsection">7.6.1 The :here directive</h4>
+
+<p>The <code>:here</code> directive is an absolute pathname designator that
+refers to the directory containing the configuration file currently
+being processed.
+
+   <p>The <code>:here</code> 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.
+
+   <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
+might simply have the user add a directive that would look something
+like this:
+<pre class="example">        (:tree  "path/to/dir")
+</pre>
+   <p>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 <samp><span class="file">dir/src/lisp/</span></samp> and <samp><span class="file">dir/extlib/lisp/</span></samp>, and
+these are the only directories that should be searched.
+
+   <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
+contains the following:
+<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
+repository, she need only add
+<pre class="example">     (:include "/path/to/my/checkout/directory/asdf.conf")
+</pre>
+   <p>to one of her previously-existing asdf source location configuration
+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
+directory according to X's (relative) instructions.
+
+<h3 class="section">7.7 Shell-friendly syntax for configuration</h3>
+
+<p>When considering environment variable <code>CL_SOURCE_REGISTRY</code>
+ASDF will skip to next configuration if it's an empty string. 
+It will <code>READ</code> the string as a SEXP in the DSL
+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
+   by a <code>:</code> (colon) on Unix platforms (including cygwin),
+   by a <code>;</code> (semicolon) on other platforms (mainly, Windows).
+
+   <p>* each entry is a directory to add to the search path.
+
+   <p>* if the entry ends with a double slash <code>//</code>
+    then it instead indicates a tree in the subdirectories
+    of which to recurse.
+
+   <p>* if the entry is the empty string (which may only appear once),
+    then it indicates that the inherited configuration should be
+    spliced there.
+
+<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
+when searching for a system of a given name,
+directives are processed in order.
+
+   <p>When looking in a directory, if the system is found, the search succeeds,
+otherwise it continues.
+
+   <p>When looking in a tree, if one system is found, the search succeeds. 
+If multiple systems are found, the consequences are unspecified:
+the search may succeed with any of the found systems,
+or an error may be raised. 
+ASDF currently returns the first system found,
+XCVB currently raised an error. 
+If none is found, the search continues.
+
+   <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. 
+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>.
+
+   <p>Include statements cause the search to recurse with the path specifications
+from the file specified.
+
+   <p>An inherit-configuration statement cause the search to recurse with the path
+specifications from the next configuration
+(see <a href="#Controlling-where-ASDF-searches-for-systems">Configurations</a> above).
+
+<h3 class="section">7.9 Caching Results</h3>
+
+<p>The implementation is allowed to either eagerly compute the information
+from the configurations and file system, or to lazily re-compute it
+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.
+
+<h3 class="section">7.10 Configuration API</h3>
+
+<p>The specified functions are exported from your build system's package. 
+Thus for ASDF the corresponding functions are in package ASDF,
+and for XCVB the corresponding functions are in package XCVB.
+
+<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. 
+   You may extend or override configuration
+   from the environment and configuration files
+   with the given <var>PARAMETER</var>, which can be
+   <code>nil</code> (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). 
+</p></blockquote></div>
+
+<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. 
+   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,
+   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. 
+</p></blockquote></div>
+
+<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>
+
+   <p>Every time you use ASDF's <code>find-system</code>, or
+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>,
+which the first time around causes your configuration to be read. 
+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.
+
+<h3 class="section">7.11 Status</h3>
+
+<p>This mechanism is vastly successful, and we have declared
+that <code>asdf:*central-registry*</code> is not recommended anymore,
+though we will continue to support it. 
+All hooks into implementation-specific search mechanisms
+have been integrated in the <code>wrapping-source-registry</code>
+that everyone uses implicitly.
+
+<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,
+   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.
+
+     <li>Keep <code>asdf:*central-registry*</code> 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.
+
+     <li>Completely remove <code>asdf:*central-registry*</code>
+   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.
+
+     <li>Replace <code>asdf:*central-registry*</code> 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.
+        </ol>
+
+   <p>I've been suggested the below features, but have rejected them,
+for the sake of keeping ASDF no more complex than strictly necessary.
+
+     <ul>
+<li>  More syntactic sugar: synonyms for the configuration directives, such as
+  <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>.
+
+     <li>   The possibility to register individual files instead of directories.
+
+     <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? 
+  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>
+
+     <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>
+
+<h3 class="section">7.13 TODO</h3>
+
+     <ul>
+<li>Add examples
+</ul>
+
+<h3 class="section">7.14 Credits for the source-registry</h3>
+
+<p>Thanks a lot to Stelian Ionescu for the initial idea.
+
+   <p>Thanks to Rommel Martinez for the initial implementation attempt.
+
+   <p>All bad design ideas and implementation bugs are to mine, not theirs. 
+But so are good design ideas and elegant implementation tricks.
+
+   <p>— Francois-Rene Rideau <a href="mailto:fare at tunes.org">fare at 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>
+
+<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”). 
+If you use multiple implementations
+(or multiple versions of the same implementation),
+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
+as you switch from one implementation to the next.
+
+   <p>Since ASDF 2, ASDF includes the <code>asdf-output-translations</code> facility
+to mitigate the problem.
+
+<h3 class="section">8.1 Configurations</h3>
+
+<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>.
+
+     <ol type=1 start=1>
+
+     <li>Some hardcoded wrapping output translations configuration may be used. 
+This allows special output translations (or usually, invariant directories)
+to be specified corresponding to the similar special entries in the source registry.
+
+     <li>An application may explicitly initialize the output-translations
+configuration using the Configuration API
+in which case this takes precedence. 
+(see <a href="#Controlling-where-ASDF-saves-compiled-files">Configuration API</a>.) 
+It may itself compute this configuration from the command-line,
+from a script, from its own configuration file, etc.
+
+     <li>The source registry will be configured from
+the environment variable <code>ASDF_OUTPUT_TRANSLATIONS</code> if it exists.
+
+     <li>The source registry will be configured from
+user configuration file
+<samp><span class="file">$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf</span></samp>
+(which defaults to
+<samp><span class="file">~/.config/common-lisp/asdf-output-translations.conf</span></samp>)
+if it exists.
+
+     <li>The source registry will be configured from
+user configuration directory
+<samp><span class="file">$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf.d/</span></samp>
+(which defaults to
+<samp><span class="file">~/.config/common-lisp/asdf-output-translations.conf.d/</span></samp>)
+if it exists.
+
+     <li>The source registry will be configured from
+system configuration file
+<samp><span class="file">/etc/common-lisp/asdf-output-translations.conf</span></samp>
+if it exists.
+
+     <li>The source registry will be configured from
+system configuration directory
+<samp><span class="file">/etc/common-lisp/asdf-output-translations.conf.d/</span></samp>
+if it exists.
+
+        </ol>
+
+   <p>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).
+
+   <p>Each of these configurations is only used if the previous
+configuration explicitly or implicitly specifies that it
+includes its inherited configuration.
+
+   <p>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.
+
+<h3 class="section">8.2 Backward Compatibility</h3>
+
+<p><a name="index-ASDF_002dBINARY_002dLOCATIONS-compatibility-58"></a>
+
+   <p>We purposefully do NOT provide backward compatibility with earlier versions of
+<code>ASDF-Binary-Locations</code> (8 Sept 2009),
+<code>common-lisp-controller</code> (7.0) or
+<code>cl-launch</code> (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 <code>asdf-output-translations</code> API as defined below:
+<code>common-lisp-controller</code> (7.2) and <code>cl-launch</code> (3.000). 
+<code>ASDF-Binary-Locations</code> is fully superseded and not to be used anymore.
+
+   <p>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 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.
+
+   <p>Nevertheless, if you are a fan of <code>ASDF-Binary-Locations</code>,
+we provide a limited emulation mode:
+
+<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. 
+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>
+you will now have to pass the same values as keyword arguments to this function. 
+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>
+instead of just strings and pathnames. 
+</p></blockquote></div>
+
+   <p>If you insist, you can also keep using the old <code>ASDF-Binary-Locations</code>
+(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.
+
+   <p>Also, note that output translation is enabled by default. 
+To disable it, use <code>(asdf:disable-output-translations)</code>.
+
+<h3 class="section">8.3 Configuration DSL</h3>
+
+<p>Here is the grammar of the SEXP DSL
+for <code>asdf-output-translations</code> configuration:
+
+<pre class="verbatim">;; A configuration is single SEXP starting with keyword :source-registry
+;; followed by a list of directives.
+CONFIGURATION := (:output-translations 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
+
+    ;; include a configuration file or directory
+    (:include PATHNAME-DESIGNATOR) |
+
+    ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/ or something.
+    :enable-user-cache |
+    ;; Disable global cache. Map / to /
+    :disable-cache |
+
+    ;; add a single directory to be scanned (no recursion)
+    (DIRECTORY-DESIGNATOR DIRECTORY-DESIGNATOR)
+
+    ;; use a function to return the translation of a directory designator
+    (DIRECTORY-DESIGNATOR (:function TRANSLATION-FUNCTION))
+
+DIRECTORY-DESIGNATOR :=
+    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
+
+TRANSLATION-FUNCTION :=
+    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
+
+</pre>
+
+   <p>Relative components better be either relative
+or subdirectories of the path before them, or bust.
+
+   <p>The last component, if not a pathname, is notionally completed by <samp><span class="file">/**/*.*</span></samp>. 
+You can specify more fine-grained patterns
+by using a pathname object as the last component
+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
+to anything but themselves (same as if the second designator was the same as the first).
+
+   <p>When the first designator is <code>t</code>,
+the mapping always matches. 
+When the first designator starts with <code>:root</code>,
+the mapping matches any host and device. 
+In either of these cases, if the second designator
+isn't <code>t</code> and doesn't start with <code>:root</code>,
+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.
+
+   <p>When the second designator is <code>t</code>, the mapping is the identity. 
+When the second designator starts with <code>:root</code>,
+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 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:
+<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:
+	<code>`(:root (:root :**/ :implementation :*.*.*))</code>
+
+   <p><code>:include</code> statements cause the search to recurse with the path specifications
+from the file specified.
+
+   <p>If the <code>translate-pathname</code> 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 <code>directory-designator</code>
+the first element of which is the keyword <code>:function</code>,
+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.
+
+   <p>An <code>:inherit-configuration</code> statement cause the search to recurse with the path
+specifications from the next configuration. 
+See <a href="#Controlling-where-ASDF-saves-compiled-files">Configurations</a>, above.
+
+     <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>
+which by default is the same as using
+<code>("/var/cache/common-lisp" :uid :implementation-type)</code>
+(on Unix and cygwin), or something semi-sensible on Windows. 
+</ul>
+
+<h3 class="section">8.4 Configuration Directories</h3>
+
+<p>Configuration directories consist in files each contains
+a list of directives without any enclosing
+<code>(:output-translations ...)</code> form. 
+The files will be sorted by namestring as if by <code>string<</code> and
+the lists of directives of these files with be concatenated in order. 
+An implicit <code>:inherit-configuration</code> will be included
+at the <em>end</em> of the list.
+
+   <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,
+the names of files in 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 <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
+or namestring in an <code>:include</code> directive, e.g.:
+<pre class="verbatim">	(:include "/foo/bar/")
+</pre>
+
+<h3 class="section">8.5 Shell-friendly syntax for configuration</h3>
+
+<p>When considering environment variable <code>ASDF_OUTPUT_TRANSLATIONS</code>
+ASDF will skip to next configuration if it's an empty string. 
+It will <code>READ</code> the string as an SEXP in the DSL
+if it begins with a paren <code>(</code>
+and it will be interpreted as a list of directories. 
+Directories should come by pairs, indicating a mapping directive. 
+Entries are separated
+by a <code>:</code> (colon) on Unix platforms (including cygwin),
+by a <code>;</code> (semicolon) on other platforms (mainly, Windows).
+
+   <p>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 that the directory specified first is to be left untranslated
+(which has the same effect as if the directory had been repeated).
+
+<h3 class="section">8.6 Semantics of Output Translations</h3>
+
+<p>From the specified configuration,
+a list of mappings is extracted in a straightforward way:
+mappings are collected in order, recursing through
+included or inherited configuration as specified. 
+To this list is prepended some implementation-specific mappings,
+and is appended a global default.
+
+   <p>The list is then compiled to a mapping table as follows:
+for each entry, in order, resolve the first designated directory
+into an actual 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 location to the output location,
+and add another mapping from the output location to itself
+(unless a mapping already exists for the output location).
+
+   <p>Based on the table, a mapping function is defined,
+mapping source pathnames to output pathnames:
+given a source pathname, locate the longest matching prefix
+in the source column of the mapping table. 
+Replace that prefix by the corresponding output column
+in the same row of the table, and return the result. 
+If no match is found, return the source pathname. 
+(A global default mapping the filesystem root to itself
+may ensure that there will always be a match,
+with same fall-through semantics).
+
+<h3 class="section">8.7 Caching Results</h3>
+
+<p>The implementation is allowed to either eagerly compute the information
+from the configurations and file system, or to lazily re-compute it
+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.
+
+<h3 class="section">8.8 Output location API</h3>
+
+<p>The specified functions are exported from package ASDF.
+
+<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. 
+   You may extend or override configuration
+   from the environment and configuration files
+   with the given <var>PARAMETER</var>, which can be
+   <code>nil</code> (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). 
+</p></blockquote></div>
+
+<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
+   that maps every pathname to itself,
+   effectively disabling the output translation facility. 
+</p></blockquote></div>
+
+<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. 
+   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,
+   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. 
+</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
+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>,
+which the first time around causes your configuration to be read. 
+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.
+
+<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>.
+
+   <p>All bad design ideas and implementation bugs are to mine, not theirs. 
+But so are good design ideas and elegant implementation tricks.
+
+   <p>— Francois-Rene Rideau <a href="mailto:fare at tunes.org">fare at 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>
+
+<p>If ASDF detects an incorrect system definition, it will signal a generalised instance of
+<code>SYSTEM-DEFINITION-ERROR</code>.
+
+   <p>Operations may go wrong (for example when source files contain errors). 
+These are signalled using generalised instances of
+<code>OPERATION-ERROR</code>.
+
+<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. 
+The variables <var>*compile-file-warnings-behaviour*</var> and
+<var>*compile-file-errors-behavior*</var>
+control the handling of any such events. 
+The valid values for these variables are
+<code>:error</code>, <code>:warn</code>, and <code>:ignore</code>.
+
+<p><a name="Miscellaneous-additional-functionality"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h2 class="chapter">10 Miscellaneous additional functionality</h2>
+
+<p>ASDF includes several additional features that are generally
+useful for system definition and development.
+
+<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>. 
+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.
+
+   <p>The argument must be a either <code>nil</code>, a fbound symbol,
+a lambda-expression (e.g. <code>(lambda (thunk) ...(funcall thunk ...) ...)</code>)
+a function object (e.g. using <code>#.#'</code> but that's discouraged
+because it prevents the introspection done by e.g. asdf-dependency-grovel),
+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. 
+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>.
+
+   <p>One notable argument that is heeded by <code>compile-file*</code> is
+<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;
+it may issue warnings or errors before it returns <code>nil</code>. 
+(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.
+
+   <p>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 the hook with <code>nil</code> for all the modules and files
+that are compiled before the hook is defined.
+
+   <p>Using this hook, you may achieve such effects as:
+locally renaming packages,
+binding <var>*readtables*</var> and other syntax-controlling variables,
+handling warnings and other conditions,
+proclaiming consistent optimization settings,
+saving code coverage information,
+maintaining meta-data about compilation timings,
+setting gensym counters and PRNG seeds and other sources of non-determinism,
+overriding the source-location and/or timestamping systems,
+checking that some compile-time side-effects were properly balanced,
+etc.
+
+   <p>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 <code>package-renaming</code> system).
+
+<h3 class="section">10.2 Controlling source file character encoding</h3>
+
+<p>Starting with ASDF 2.21, components accept a <code>:encoding</code> option
+so 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 at any point,
+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. 
+We recommend that you avoid using unprotected <code>:encoding</code> specifications
+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),
+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,
+already used by the vast majority of libraries that use more than ASCII. 
+On implementations that do not support unicode,
+the feature <code>:asdf-unicode</code> is absent, and
+the <code>:default</code> external-format is used
+to read even source files declared as <code>:utf-8</code>. 
+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 <code>lambda-reader</code>.
+
+   <p>We invite you to embrace UTF-8
+as the encoding for non-ASCII characters starting today,
+even without any explicit specification in your <code>.asd</code> files. 
+Indeed, on some implementations and configurations,
+UTF-8 is already the <code>:default</code>,
+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 <em>not</em> use a BOM),
+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,
+use the extension system <code>asdf-encodings</code>, by specifying
+<code>:defsystem-depends-on (:asdf-encodings)</code> in your <code>defsystem</code>. 
+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>
+in your <code>.asd</code> file. 
+Using the <code>*encoding-detection-hook*</code> it will also
+eventually implement some autodetection of a file's encoding
+from an emacs-style <code>-*- mode: lisp ; coding: latin1 -*-</code> 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 <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>
+or
+<kbd>git clone ssh://common-lisp.net/project/asdf/git/asdf-encodings.git</kbd>. 
+You can also browse the repository on
+<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>
+
+<p>These functions are exported by ASDF for your convenience.
+
+<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. 
+The <code>system-relative-pathname</code> function meets this need.
+
+        <p>It takes two mandatory arguments <var>system</var> and <var>name</var>
+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>.
+
+        <p>It returns a pathname built from the location of the system's
+source directory and the relative pathname. For example:
+
+     <pre class="lisp">          > (asdf:system-relative-pathname 'cl-ppcre "regex.data")
+          #P"/repository/other/cl-ppcre/regex.data"
+</pre>
+        </blockquote></div>
+
+<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
+data (or other miscellaneous) files
+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;
+the next time the system <code>foo</code> or one that depends on it is re-loaded,
+<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. 
+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 <code>update-instance-for-redefined-class</code>
+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>,
+created by <code>make-instance</code> with extra keys <var>keys</var>
+(e.g. <code>:version</code>),
+is registered as <em>preloaded</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 yet no source code is found,
+it is considered as already provided,
+and ASDF will not raise a <code>missing-component</code> error.
+
+        <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>,
+and want to register systems so that dependencies will work uniformly
+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. 
+The following documentation is only for the purpose of your migrating away from it
+in a way that preserves semantics.
+
+        <p>Instead we recommend the use <code>run-program</code>, described in the next section, and
+available as part of ASDF since ASDF 3.
+
+        <p><code>run-shell-command</code> takes as arguments a format <code>control-string</code>
+and arguments to be passed to <code>format</code> 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 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). 
+</p></blockquote></div>
+
+<h3 class="section">10.4 Some Utility Functions</h3>
+
+<p>The below functions are not exported by ASDF itself, but by UIOP, available since ASDF 3. 
+Some of them have precursors in ASDF 2, but we recommend
+you rely on ASDF 3 for active developments. 
+UIOP provides many, many more utility functions, and we recommend
+you read its README and sources for more information.
+
+<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. 
+This is what <code>parse-unix-namestring</code> provides, and why we use it in ASDF.
+
+        <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. 
+When given a <code>string</code>, portably decompose it into a pathname as below.
+
+        <p><code>#\/</code> separates directory components.
+
+        <p>The last <code>#\/</code>-separated substring is interpreted as follows:
+1- If <var>type</var> is <code>:directory</code> or <var>ensure-directory</var> is true,
+ 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>. 
+2- If <var>type</var> is <code>nil</code>, the substring is a file-namestring,
+ and its <code>name</code> and <code>type</code> are separated by <code>split-name-type</code>. 
+3- If <var>type</var> is a string, it is the given <code>type</code>, and the whole string is the <code>name</code>.
+
+        <p>Directory components with an empty name the name <code>.</code> are removed. 
+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>.
+
+        <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>. 
+No host or device can be specified in the string itself,
+which makes it unsuitable for absolute pathnames outside Unix.
+
+        <p>For relative pathnames, these components (and hence the defaults) won't matter
+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>.
+
+        <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
+even though the OS may not be Unixish, we recommend you use <code>:want-relative t</code>
+to throw an error if the pathname is absolute
+</p></blockquote></div>
+
+<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
+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.
+
+        </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>. 
+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>.
+
+        <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
+a list of a 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 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,
+and returned only one value,
+the one for the output if any handler was specified, or else the exit code;
+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. 
+If it is <code>nil</code>, then the output is redirected to the null device,
+that will discard it. 
+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>,
+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. 
+Otherwise, <var>output</var> should be a value that is a suitable first argument to
+<code>slurp-input-stream</code> (see below), or
+a list of such a value and keyword arguments. 
+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
+(or if it's a list the first element of <var>output</var> and the rest as keywords). 
+The primary value resulting from that call
+(or <code>nil</code> if no call was needed)
+will be the first value returned by <code>run-program</code>. 
+E.g., using <code>:output :string</code>
+will have it return the entire output stream as a string. 
+And using <code>:output '(:string :stripped t)</code>
+will have it return the same string stripped of any ending newline.
+
+        <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>. 
+Also <code>:output</code> means redirecting the error output to the output stream,
+in which case <code>nil</code> is returned.
+
+        <p><var>input</var> is similar to <var>output</var>, except that
+<code>vomit-output-stream</code> is used, no value is returned,
+and <code>t</code> designates the <var>*standard-input*</var>.
+
+        <p><code>element-type</code> and <code>external-format</code> are passed on
+to your Lisp implementation, when applicable, for creation of the output stream.
+
+        <p>One and only one of the stream slurping or vomiting may or may not happen
+in parallel in parallel with the subprocess,
+depending on 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.
+
+        <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,
+except on implementations that (erroneously, IMNSHO)
+insist on consulting <code>$SHELL</code> like clisp.
+
+        <p><code>ignore-error-status</code> causes <code>run-program</code>
+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 <code>subprocess-error</code> is raised in this case.
+
+        <p><code>run-program</code> works on all platforms supported by ASDF, except Genera. 
+See the source code for more documentation.
+
+        </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
+a list of the input stream.
+
+        <p>If the object is an output stream, the contents of the input stream are copied to it. 
+If the <var>linewise</var> keyword argument is provided, copying happens line by line,
+and an optional <var>prefix</var> is printed before each line. 
+Otherwise, copying happen based on a buffer of size <var>buffer-size</var>,
+using the specified <var>element-type</var>.
+
+        <p>If the object is <code>'string</code> or <code>:string</code>, the content is captured into a string. 
+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>.
+
+        <p>If the object is <code>:lines</code>, the content is captured as a list of strings,
+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.
+
+        <p>If the object is <code>:line</code>, the content is capture as with <code>:lines</code> above,
+and then its sub-object is extracted with the <var>at</var> argument,
+which defaults to <code>0</code>, extracting the first line. 
+A number will extract the corresponding line. 
+See the documentation for <code>uiop:access-at</code>.
+
+        <p>If the object is <code>:forms</code>, the content is captured as a list of S-expressions,
+as read by the Lisp reader. 
+If the <var>count</var> argument is provided,
+it is a maximum count of lines to be read. 
+We recommend you control the syntax with such macro as
+<code>uiop:with-safe-io-syntax</code>.
+
+        <p>If the object is <code>:form</code>, the content is capture as with <code>:forms</code> above,
+and then its sub-object is extracted with the <var>at</var> argument,
+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>. 
+We recommend you control the syntax with such macro as
+<code>uiop:with-safe-io-syntax</code>.
+
+        </blockquote></div>
+
+<p><a name="Getting-the-latest-version"></a>
+
+<!-- node-name,  next,  previous,  up -->
+<h2 class="chapter">11 Getting the latest version</h2>
+
+<p>Decide which version you want. 
+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.
+
+   <p>The <code>release</code> branch is what cautious people should be using;
+it has usually been tested more, and releases are cut at a point
+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. 
+You can also browse the repository on
+<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 at 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>
+
+<h3 class="section">12.1 “Where do I report a bug?”</h3>
+
+<p>ASDF bugs are tracked on launchpad: <a href="https://launchpad.net/asdf">https://launchpad.net/asdf</a>.
+
+   <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>
+
+<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.
+
+   <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.
+
+   <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.
+
+   <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.
+
+<h4 class="subsection">12.2.2 ASDF can portably name files in subdirectories</h4>
+
+<p>Common Lisp namestrings are not portable,
+except maybe for logical pathnamestrings,
+that themselves have various limitations and require a lot of setup
+that is itself ultimately non-portable.
+
+   <p>In ASDF 1, the only portable ways to refer to pathnames inside systems and components
+were very awkward, using <code>#.(make-pathname ...)</code> and
+<code>#.(merge-pathnames ...)</code>. 
+Even the above were themselves were inadequate in the general case
+due to host and device issues, unless horribly complex patterns were used. 
+Plenty of simple cases that looked portable actually weren't,
+leading to much confusion and greavance.
+
+   <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>,
+<code>merge-pathnames*</code>,
+<code>coerce-pathname</code>.
+
+   <p>On the other hand, there are places where systems used to accept namestrings
+where you must now use an explicit pathname object:
+<code>(defsystem ... :pathname "LOGICAL-HOST:PATH;TO;SYSTEM;" ...)</code>
+must now be written with the <code>#p</code> syntax:
+<code>(defsystem ... :pathname #p"LOGICAL-HOST:PATH;TO;SYSTEM;" ...)</code>
+
+   <p>See <a href="#The-defsystem-grammar">Pathname specifiers</a>.
+
+<h4 class="subsection">12.2.3 Output translations</h4>
+
+<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.
+
+   <p>Output pathname translation is essential to share
+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.
+
+   <p>In ASDF 2, a standard mechanism is provided for that,
+<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.
+
+   <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>
+
+<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.
+
+   <p>This made for awkward configuration files and startup scripts
+that could not be shared between users, managed by administrators
+or packaged by distributions.
+
+   <p>ASDF 2 provides a well-documented way to configure ASDF,
+with sensible defaults, adequate configuration languages,
+and a coherent set of configuration files and hooks.
+
+   <p>We believe it's a vast improvement because it decouples
+application distribution from library distribution. 
+The application writer can avoid thinking where the libraries are,
+and the library distributor (dpkg, clbuild, advanced user, etc.) 
+can configure them once and for every application. 
+Yet settings can be easily overridden where needed,
+so whoever needs control has exactly as much as required.
+
+   <p>At the same time, ASDF 2 remains compatible
+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.
+
+   <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>
+
+<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>.
+
+   <p>In ASDF 2, you can use shortcuts for the usual operations:
+<code>(asdf:load-system :foo)</code>, and
+similarly for <code>compile-system</code>, <code>test-system</code>.
+
+<h4 class="subsection">12.2.6 Many bugs have been fixed</h4>
+
+<p>The following issues and many others have been fixed:
+
+     <ul>
+<li>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.
+
+     <li>Performance has been notably improved for large systems
+(say with thousands of components) by using
+hash-tables instead of linear search,
+and linear-time list accumulation
+instead of quadratic-time recursive appends.
+
+     <li>Many features used to not be portable,
+especially where pathnames were involved. 
+Windows support was notably quirky because of such non-portability.
+
+     <li>The internal test suite used to massively fail on many implementations. 
+While still incomplete, it now fully passes
+on all implementations supported by the test suite,
+except for GCL (due to GCL bugs).
+
+     <li>Support was lacking for some implementations. 
+ABCL and GCL were notably wholly broken. 
+ECL extensions were not integrated with ASDF release.
+
+     <li>The documentation was grossly out of date.
+
+   </ul>
+
+<h4 class="subsection">12.2.7 ASDF itself is versioned</h4>
+
+<p>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 available and worked,
+or take great pains to have the correct version of ASDF installed.
+
+   <p>With ASDF 2, we provide a new stable set of working features
+that everyone can rely on from now on. 
+Use <code>#+asdf2</code> to detect presence of ASDF 2,
+<code>(asdf:version-satisfies (asdf:asdf-version) "2.345.67")</code>
+to check the availability of a version no earlier than required.
+
+<h4 class="subsection">12.2.8 ASDF can be upgraded</h4>
+
+<p>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.
+
+   <p>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 upgrade, though,
+most notably the fact that after you upgrade ASDF,
+you must also reload or upgrade all ASDF extensions.
+
+<h4 class="subsection">12.2.9 Decoupled release cycle</h4>
+
+<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.
+
+   <p>With ASDF 2, upgrade is possible, easy and can be recommended. 
+This means that vendors can safely ship a recent version of ASDF,
+confident that if a user isn't fully satisfied,
+he can easily upgrade ASDF and deal
+with a supported recent version of it. 
+This means that release cycles will be causally decoupled,
+the practical consequence of which will mean faster convergence
+towards the latest version for everyone.
+
+<h4 class="subsection">12.2.10 Pitfalls of the transition to ASDF 2</h4>
+
+<p>The main pitfalls in upgrading to ASDF 2 seem to be related
+to the output translation mechanism.
+
+     <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. 
+See <a href="#FAQ">“How can I wholly disable the compiler output cache?”</a>.
+
+     <li>Some systems in the large have been known
+not to play well with output translations. 
+They were relatively easy to fix. 
+Once again, it is also easy to disable output translations,
+or to override its configuration.
+
+     <li>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. 
+See <code>enable-asdf-binary-locations-compatibility</code> in
+see <a href="#Controlling-where-ASDF-saves-compiled-files">Backward Compatibility</a>. 
+But thou shalt not load ABL on top of ASDF 2.
+
+   </ul>
+
+   <p>Other issues include the following:
+
+     <ul>
+<li>ASDF pathname designators are now specified
+in places where they were unspecified,
+and a few small adjustments have to be made to some non-portable defsystems. 
+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,
+where it wasn't necessary in the toplevel <code>:pathname</code> argument
+(but necessary in other <code>:pathname</code> arguments).
+
+     <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. 
+Try to <code>(time (asdf:initialize-source-registry))</code>
+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 configuration
+and not use any deep <code>:tree</code> entry but only <code>:directory</code> entries
+or shallow <code>:tree</code> entries. 
+Or you can fix your implementation to not be quite that slow
+when recursing through directories. 
+<em>Update</em>: This performance bug fixed the hard way in 2.010.
+
+     <li>On Windows, only LispWorks supports proper default configuration pathnames
+based on the Windows registry. 
+Other implementations make do with environment variables,
+that you may have to define yourself
+if you're using an older version of Windows. 
+Windows support is somewhat less tested than Unix support. 
+Please help report and fix bugs. 
+<em>Update</em>: As of ASDF 2.21, all implementations
+should now use the same proper default configuration pathnames
+and they should actually work, though they haven't all been tested.
+
+     <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. 
+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))))
+  (declare (ignorable component system)) "lis")</code>. 
+Now, the pathname for a component is eagerly computed when defining the system,
+and instead you will <code>(defclass cl-source-file.lis (cl-source-file) ((type :initform "lis")))</code>
+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.
+
+     <p><a name="index-source_002dfile_002dtype-85"></a>
+
+   </ul>
+
+<h3 class="section">12.3 Issues with installing the proper version of ASDF</h3>
+
+<h4 class="subsection">12.3.1 “My Common Lisp implementation comes with an outdated version of ASDF. What to do?”</h4>
+
+<p>We recommend you upgrade ASDF. 
+See <a href="#Loading-ASDF">Upgrading ASDF</a>.
+
+   <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>.
+
+<h4 class="subsection">12.3.2 “I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?”</h4>
+
+<p>Since ASDF 2,
+it should always be a good time to upgrade to a recent version of ASDF. 
+You may consult with the maintainer for which specific version they recommend,
+but the latest <code>release</code> 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.
+
+   <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>. 
+You may have it load some other version configured by the user,
+if you allow such configuration.
+
+     <li>If your system provides a mechanism to hook into <code>CL:REQUIRE</code>,
+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 appropriate code to this end.
+
+     <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>.
+
+     <li>If you have magic systems as above, like SBCL does,
+then we explicitly ask you to <em>NOT</em> distribute
+<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
+and precompile it in your binary distribution,
+but <samp><span class="file">asdf.asd</span></samp> 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 <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,
+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.
+
+     <li>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 may add them to the <code>wrapping-source-registry</code>,
+and you are welcome to include <samp><span class="file">asdf.asd</span></samp> amongst them. 
+Non-magic systems should be at the back of the <code>wrapping-source-registry</code>
+while magic systems are at the front.
+
+     <li>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.
+
+   </ul>
+
+<h3 class="section">12.4 Issues with configuring ASDF</h3>
+
+<h4 class="subsection">12.4.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>Note that in the past there was an add-on to ASDF called
+<code>ASDF-binary-locations</code>, developed by Gary King. 
+That add-on has been merged into ASDF proper,
+then superseded by the <code>asdf-output-translations</code> facility.
+
+   <p>Note that use of <code>asdf-output-translations</code>
+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
+is likely to interfere. 
+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.
+
+<h4 class="subsection">12.4.2 “How can I wholly disable the compiler output cache?”</h4>
+
+<p>To permanently disable the compiler output cache
+for all future runs of ASDF, you can:
+
+<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
+(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 command
+(e.g. some call to <code>asdf:initialize-output-translations</code>).
+
+   <p>To disable the compiler output cache in Lisp processes
+run by your current shell, try (assuming <code>bash</code> or <code>zsh</code>)
+(on Unix and cygwin only):
+
+<pre class="example">     export ASDF_OUTPUT_TRANSLATIONS=/:
+</pre>
+   <p>To disable the compiler output cache just in the current Lisp process,
+use (after loading ASDF but before using it):
+
+<pre class="example">     (asdf:disable-output-translations)
+</pre>
+   <h3 class="section">12.5 Issues with using and extending ASDF to define systems</h3>
+
+<h4 class="subsection">12.5.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. 
+<code>test-op</code> has been
+a topic of considerable discussion on the
+<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel">asdf-devel mailing list</a>,
+and on the
+<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>
+
+   <p>This procedure will allow you to support users who do not wish to
+install your test framework.
+
+   <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.
+
+<h4 class="subsection">12.5.2 “How can I cater for documentation generation in my system?”</h4>
+
+<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>.
+
+<h4 class="subsection">12.5.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>
+
+<h4 class="subsection">12.5.4 “I want to put my module's files at the top level.  How do I do this?”</h4>
+
+<p>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 adding a <code>:pathname ""</code> argument
+to the module description. 
+For example, here is how it could be done
+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. 
+A pathname can only be portably constructed with such syntax as
+<code>#.(make-pathname :directory '(:relative "foo" "bar"))</code>,
+and similarly the current directory can only be portably specified as
+<code>#.(make-pathname :directory '(:relative))</code>. 
+However, as of ASDF 2, you can portably use a string to denote a pathname. 
+The string will be parsed as a <code>/</code>-separated path from the current directory,
+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. 
+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
+(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>
+
+<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>:
+
+<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,
+or want to support versions of ASDF
+earlier than 2.014.14 (but later than 2.000),
+you can define a class as follows:
+
+<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
+and using it in the same file without other fancy definitions,
+you might skip package complications:
+
+<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>
+
+<p>Marco and Peter's proposal for defsystem 4 served as the driver for
+many of the features in here.  Notable differences are:
+
+     <ul>
+<li>We don't specify output files or output file extensions
+as part of the system.
+
+     <p>If you want to find out what files an operation would create,
+ask the operation.
+
+     <li>We don't deal with CL packages
+
+     <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)
+
+     <li>There is no proposal here that <code>defsystem</code> does version control.
+
+     <p>A system has a given version which can be used to check dependencies,
+but that's all. 
+</ul>
+
+   <p>The defsystem 4 proposal tends to look more at the external features,
+whereas this one centres on a protocol for system introspection.
+
+<h3 class="section">14.3 kmp's “The Description of Large Systems”, MIT AI Memo 801</h3>
+
+<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>
+
+   <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 ]
+
+<!--  -->
+<p><a name="Concept-Index"></a>
+
+<h2 class="unnumbered">Concept Index</h2>
+
+<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>
+
+<h2 class="unnumbered">Function and Class Index</h2>
+
+
+
+<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>
+
+<h2 class="unnumbered">Variable Index</h2>
+
+
+
+<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">
+<hr>
+<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:
+search forward for
+<code>*system-definition-search-functions*</code>. 
+See <a href="#Defining-systems-with-defsystem">Defining systems with defsystem</a>.</p>
+
+   <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,
+in which case the <code>eval</code> 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.
+
+   <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
+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”. 
+</p>
+
+   <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>
+
+</body></html>
+

=====================================
src/contrib/asdf/doc/asdf.info
=====================================
--- /dev/null
+++ b/src/contrib/asdf/doc/asdf.info
@@ -0,0 +1,4260 @@
+This is asdf.info, produced by makeinfo version 4.13 from asdf.texinfo.
+
+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.
+
+   You can find the latest version of this manual at
+`http://common-lisp.net/project/asdf/asdf.html'.
+
+   ASDF Copyright (C) 2001-2013 Daniel Barlow and contributors.
+
+   This manual Copyright (C) 2001-2013 Daniel Barlow and contributors.
+
+   This manual revised (C) 2009-2013 Robert P. Goldman and
+Francois-Rene Rideau.
+
+   Permission is hereby granted, free of charge, to any person obtaining
+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:
+
+   The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+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.
+
+
+File: asdf.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)
+
+asdf: another system definition facility
+****************************************
+
+This manual describes ASDF, a system definition facility for Common
+Lisp programs and libraries.
+
+   You can find the latest version of this manual at
+`http://common-lisp.net/project/asdf/asdf.html'.
+
+   ASDF Copyright (C) 2001-2013 Daniel Barlow and contributors.
+
+   This manual Copyright (C) 2001-2013 Daniel Barlow and contributors.
+
+   This manual revised (C) 2009-2013 Robert P. Goldman and
+Francois-Rene Rideau.
+
+   Permission is hereby granted, free of charge, to any person obtaining
+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:
+
+   The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+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.
+
+* Menu:
+
+* Introduction::
+* Loading ASDF::
+* Configuring ASDF::
+* Using ASDF::
+* Defining systems with defsystem::
+* The object model of ASDF::
+* Controlling where ASDF searches for systems::
+* Controlling where ASDF saves compiled files::
+* Error handling::
+* Miscellaneous additional functionality::
+* Getting the latest version::
+* FAQ::
+* TODO list::
+* Inspiration::
+* Concept Index::
+* Function and Class Index::
+* Variable Index::
+
+
+File: asdf.info,  Node: Introduction,  Next: Loading ASDF,  Prev: Top,  Up: Top
+
+1 Introduction
+**************
+
+ASDF is Another System Definition Facility: a tool for specifying how
+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.
+
+   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
+software who want to specify how to build their systems, one for
+implementers of Common Lisp extensions who want to extend the build
+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.
+
+
+File: asdf.info,  Node: Loading ASDF,  Next: Configuring ASDF,  Prev: Introduction,  Up: Top
+
+2 Loading ASDF
+**************
+
+2.1 Loading a pre-installed ASDF
+================================
+
+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:
+
+     (require "asdf")
+
+   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.
+
+   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
+===================================
+
+To check whether ASDF is properly loaded in your current Lisp image,
+you can run this form:
+
+     (asdf:asdf-version)
+
+   If it returns a string, that is the version of ASDF that is
+currently installed.
+
+   If it raises an error, then either ASDF is not loaded, or you are
+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"))))
+
+   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 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.
+
+2.3 Upgrading ASDF
+==================
+
+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.
+
+   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:
+
+     (require "asdf")
+     (asdf:load-system :asdf)
+
+   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:
+
+     (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:
+
+     (load "/path/to/your/installed/asdf.lisp")
+
+   The single file `asdf.lisp' is all you normally need to use ASDF.
+
+   You can extract this file from latest release tarball on the ASDF
+website (http://common-lisp.net/project/asdf/).  If you are daring and
+willing to report bugs, you can get the latest and greatest version of
+ASDF from its git repository.  *Note Getting the latest version::.
+
+   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.
+
+
+File: asdf.info,  Node: Configuring ASDF,  Next: Using ASDF,  Prev: Loading ASDF,  Up: Top
+
+3 Configuring ASDF
+******************
+
+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::.
+
+   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.
+
+   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:
+
+   `(:directory "/home/luser/.asd-link-farm/")'
+
+   If you want all the subdirectories under `/home/luser/lisp/' to be
+recursively scanned for `.asd' files, instead use:
+
+   `(:tree "/home/luser/lisp/")'
+
+   Note that your Operating System distribution or your system
+administrator may already have configured system-managed libraries for
+you.
+
+   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-source-registry)
+
+   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.
+
+3.2 Configuring ASDF to find your systems -- old style
+======================================================
+
+The old way to configure ASDF to find your systems is by `push'ing
+directory pathnames onto the variable `asdf:*central-registry*'.
+
+   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
+starts your Common Lisp software system.  (For instance, some SBCL
+users used to put it in their `~/.sbclrc'.)
+
+   The `asdf:*central-registry*' 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(1).
+
+   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:
+
+     (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
+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:
+
+     $ cd /home/me/cl/systems/
+     $ ln -s ~/src/foo/foo.asd .
+
+   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.
+
+3.3 Configuring where ASDF stores object files
+==============================================
+
+ASDF lets you configure where object files will be stored.  Sensible
+defaults are provided and you shouldn't normally have to worry about it.
+
+   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.
+
+   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::.
+
+   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:
+
+   `("/foo/bar/baz/quux/" "/where/i/want/my/fasls/")'
+
+   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:
+
+   `("/toto/tata/")'
+
+   To wholly disable output translations for all directories, you can
+create a file `00-disable.conf' with the line:
+
+   `(t t)'
+
+   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
+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
+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".
+
+
+File: asdf.info,  Node: Using ASDF,  Next: Defining systems with defsystem,  Prev: Configuring ASDF,  Up: Top
+
+3.4 Resetting Configuration
+===========================
+
+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
+     undoes any ASDF configuration,    regarding source-registry or
+     output-translations.
+
+   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*)
+
+   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.
+
+4 Using ASDF
+************
+
+4.1 Loading a system
+====================
+
+The system FOO is loaded (and compiled, if necessary) by evaluating the
+following Lisp form:
+
+     (asdf:load-system :FOO)
+
+   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:
+
+     (require :FOO)
+
+   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
+====================
+
+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.
+
+   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
+===========
+
+To use ASDF:
+
+   * Load ASDF itself into your Lisp image, either through `(require
+     "asdf")' or else through `(load "/path/to/asdf.lisp")'.
+
+   * Make sure ASDF can find system definitions thanks to proper
+     source-registry configuration.
+
+   * Load a system with `(asdf:load-system :my-system)' or use some
+     other operation on some system of your choice.
+
+
+4.4 Moving on
+=============
+
+That's all you need to know to use ASDF to load systems written by
+others.  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.
+
+
+File: asdf.info,  Node: Defining systems with defsystem,  Next: The object model of ASDF,  Prev: Using ASDF,  Up: Top
+
+5 Defining systems with defsystem
+*********************************
+
+This chapter describes how to use asdf to define systems and develop
+software.
+
+* Menu:
+
+* The defsystem form::
+* A more involved example::
+* The defsystem grammar::
+* Other code in .asd files::
+
+
+File: asdf.info,  Node: The defsystem form,  Next: A more involved example,  Prev: Defining systems with defsystem,  Up: Defining systems with defsystem
+
+5.1 The defsystem form
+======================
+
+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'.
+
+   Let's look at a simple system.  This is a complete file that would
+usually be saved as `hello-lisp.asd':
+
+     (in-package :asdf)
+
+     (defsystem "hello-lisp"
+       :description "hello-lisp: a sample Lisp system."
+       :version "0.2.1"
+       :author "Joe User <joe at example.com>"
+       :licence "Public Domain"
+       :components ((:file "packages")
+                    (:file "macros" :depends-on ("packages"))
+                    (:file "hello" :depends-on ("macros"))))
+
+   Some notes about this example:
+
+   * 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.
+
+
+File: asdf.info,  Node: A more involved example,  Next: The defsystem grammar,  Prev: The defsystem form,  Up: Defining systems with defsystem
+
+5.2 A more involved example
+===========================
+
+Let's illustrate some more involved uses of `defsystem' via a slightly
+convoluted example:
+
+     (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")))
+
+   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::.
+
+
+File: asdf.info,  Node: The defsystem grammar,  Next: Other code in .asd files,  Prev: A more involved example,  Up: Defining systems with defsystem
+
+5.3 The defsystem grammar
+=========================
+
+     system-definition := ( defsystem system-designator SYSTEM-OPTION* )
+
+     system-option := :defsystem-depends-on system-list
+                      | :weakly-depends-on SYSTEM-LIST
+                      | :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 ( DEPENDENCY-DEF* )
+             | :in-order-to ( DEPENDENCY+ )
+
+
+     system-list := ( SIMPLE-COMPONENT-NAME* )
+
+     component-list := ( COMPONENT-DEF* )
+
+     component-def  := ( component-type simple-component-name OPTION* )
+
+     component-type := :module | :file | :static-file | other-component-type
+
+     other-component-type := symbol-by-name (*note Component types: The defsystem grammar.)
+
+     # This is used in :depends-on, as opposed to ``dependency,''
+     # which is used in :in-order-to
+     dependency-def := simple-component-name
+                    | (feature FEATURE-NAME)
+                    | ( :version simple-component-name version-specifier)
+
+     # ``dependency'' is used in :in-order-to, as opposed to
+     # ``dependency-def''
+     dependency := (dependent-op REQUIREMENT+)
+     requirement := (required-op REQUIRED-COMPONENT+)
+                  | (:feature FEATURE-NAME)
+     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 FEATURE-EXPRESSION*)
+                           | (:or FEATURE-EXPRESSION*) | (:not FEATURE-EXPRESSION)
+
+5.3.1 Component names
+---------------------
+
+Component names (`simple-component-name') may be either strings or
+symbols.
+
+5.3.2 Component types
+---------------------
+
+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 `my-component-type', in the
+current package `my-system-asd' can be specified as
+`:my-component-type', or `my-component-type'.
+
+   `system' and its subclasses are _not_ allowed as component types for
+such children components.
+
+5.3.3 System class names
+------------------------
+
+A system class name will be looked up in the same way as a Component
+type (see above), except that only `system' and its subclasses are
+allowed.  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 `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
+
+     :class :MY-NEW-SYSTEM-SUBCLASS
+
+   This practice will ensure that package name conflicts are avoided.
+Otherwise, the symbol `MY-NEW-SYSTEM-SUBCLASS' will be read into the
+current package _before_ it has been exported from the ASDF extension
+loaded by `:defsystem-depends-on', causing a name conflict in the
+current package.
+
+5.3.4 Defsystem depends on
+--------------------------
+
+The `:defsystem-depends-on' option to `defsystem' allows the programmer
+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.
+
+5.3.5 Weakly depends on
+-----------------------
+
+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.
+
+   The (deprecated) `:weakly-depends-on' option to `defsystem' allows
+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
+that, if present, could provide additional functionality, but which are
+not necessary for basic function.
+
+   Currently, although it is specified to be an option only to
+`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
+-------------------------
+
+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.
+
+   If a string is given, which is the usual case, the string will be
+interpreted as a Unix-style pathname where `/' characters will be
+interpreted as directory separators.  Usually, Unix-style relative
+pathnames are used (i.e. not starting with `/', as opposed to absolute
+pathnames); they are relative to the path of the parent component.
+Finally, depending on the `component-type', the pathname may be
+interpreted as either a file or a directory, and if it's a file, a file
+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.
+
+   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
+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.
+
+   Pathname objects may be given to override the path for a component.
+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 ...))'.
+
+   Note that when specifying pathname objects, ASDF does not do any
+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
+------------------------
+
+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.
+
+   System definers are encouraged to use version identifiers of the form
+X.Y.Z for major version, minor version and patch level, where
+significant API incompatibilities are signaled by an increased major
+number.
+
+   *Note Common attributes of components::.
+
+5.3.8 Using logical pathnames
+-----------------------------
+
+We do not generally recommend the use of logical pathnames, especially
+not so to newcomers to Common Lisp.  However, we do support the use of
+logical pathnames by old timers, when such is their preference.
+
+   To use logical pathnames, you will have to provide a pathname object
+as a `:pathname' specifier to components that use it, using such syntax
+as `#p"LOGICAL-HOST:absolute;path;to;component.lisp"'.
+
+   You only have to specify such logical pathname for your system or
+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.
+
+   The `asdf-output-translation' layer will avoid trying to resolve and
+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
+translations, any system that uses logical pathnames will behave
+differently under asdf-output-translations than other systems you use.
+
+   If you wish to use logical pathnames you will have to configure the
+translations yourself before they may be used.  ASDF currently provides
+no specific support for defining logical pathname translations.
+
+   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, (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
+implementations supported by ASDF is more than we can document.  As for
+the second issue, mind that the limitation is notably enforced on SBCL,
+and that you therefore can't portably violate the limitations but must
+instead define some encoding of your own and add individual mappings to
+name physical pathnames that do not fit the restrictions.  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.
+
+5.3.9 Serial dependencies
+-------------------------
+
+If the `:serial t' option is specified for a module, ASDF will add
+dependencies for each child component, on all the children textually
+preceding it.  This is done as if by `:depends-on'.
+
+     :serial t
+     :components ((:file "a") (:file "b") (:file "c"))
+
+   is equivalent to
+
+     :components ((:file "a")
+                  (:file "b" :depends-on ("a"))
+                  (:file "c" :depends-on ("a" "b")))
+
+5.3.10 Source location
+----------------------
+
+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.
+
+   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
+     default to the right place.
+
+  2. This pathname information will not be overwritten with
+     `*default-pathname-defaults*' (which could be somewhere else
+     altogether) if the user loads up the `.asd' file into his editor
+     and interactively re-evaluates that form.
+
+   If a system is being loaded for the first time, its top-level
+pathname will be set to:
+
+   * The host/device/directory parts of `*load-truename*', if it is
+     bound.
+
+   * `*default-pathname-defaults*', otherwise.
+
+   If a system is being redefined, the top-level pathname will be
+
+   * changed, if explicitly supplied or obtained from `*load-truename*'
+     (so that an updated source location is reflected in the system
+     definition)
+
+   * changed if it had previously been set from
+     `*default-pathname-defaults*'
+
+   * left as before, if it had previously been set from
+     `*load-truename*' and `*load-truename*' is currently unbound (so
+     that a developer can evaluate a `defsystem' form from within an
+     editor without clobbering its source location)
+
+5.3.11 if-feature option
+------------------------
+
+This option allows you to specify a feature expression to be evaluated
+as if by `#+' to conditionally include a component in your build.  If
+the expression is false, the component is dropped as well as any
+dependency pointing to it.  As compared to using `#+' which is expanded
+at read-time, this allows you to have an object in your component
+hierarchy that can be used for manipulations beside building your
+project.  This option was added in ASDF 3.
+
+5.3.12 if-component-dep-fails option
+------------------------------------
+
+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.
+
+
+File: asdf.info,  Node: Other code in .asd files,  Prev: The defsystem grammar,  Up: Defining systems with defsystem
+
+5.4 Other code in .asd files
+============================
+
+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'.
+
+   If however, you might insist on including code in the `.asd' file
+itself, e.g., to examine and adjust the compile-time environment,
+possibly adding appropriate features to `*features*'.  If so, here are
+some conventions we recommend you follow, so that users can control
+certain details of execution of the Lisp in `.asd' files:
+
+   * Any informative output (other than warnings and errors, which are
+     the condition system's to dispose of) should be sent to the
+     standard CL stream `*standard-output*', so that users can easily
+     control the disposition of output from ASDF operations.
+
+
+File: asdf.info,  Node: The object model of ASDF,  Next: Controlling where ASDF searches for systems,  Prev: Defining systems with defsystem,  Up: Top
+
+6 The object model of ASDF
+**************************
+
+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.
+
+   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.
+
+* Menu:
+
+* Operations::
+* Components::
+* Functions::
+
+
+File: asdf.info,  Node: Operations,  Next: Components,  Prev: The object model of ASDF,  Up: The object model of ASDF
+
+6.1 Operations
+==============
+
+An "operation" object of the appropriate type is instantiated whenever
+the user wants to do something with a system like
+
+   * compile all its files
+
+   * load the files into a running lisp environment
+
+   * 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
+work.
+
+   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.
+
+   Operations are invoked on systems via `operate'.
+
+ -- Generic function: `operate' OPERATION SYSTEM &rest INITARGS &key
+          `force' `force-not' `verbose' &allow-other-keys
+ -- Generic function: `oos' OPERATION SYSTEM &rest INITARGS &key
+          &allow-other-keys
+     `operate' invokes OPERATION on SYSTEM.  `oos' is a synonym for
+     `operate'.
+
+     OPERATION is a symbol that is passed, along with the supplied
+     INITARGS, to `make-instance' to create the operation object.
+     SYSTEM is a system designator.
+
+     The INITARGS are passed to the `make-instance' call when creating
+     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.
+
+     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
+     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
+     compilation.  If FORCE-NOT is `:all', then all systems are forced
+     not to be recompiled even if modified since last compilation.  If
+     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:
+          (asdf:traverse operation-class system-name)
+
+
+* Menu:
+
+* Predefined operations of ASDF::
+* Creating new operations::
+
+
+File: asdf.info,  Node: Predefined operations of ASDF,  Next: Creating new operations,  Prev: Operations,  Up: Operations
+
+6.1.1 Predefined operations of ASDF
+-----------------------------------
+
+All the operations described in this section are in the `asdf' package.
+They are invoked via the `operate' generic function.
+
+     (asdf:operate 'asdf:OPERATION-NAME :SYSTEM-NAME {OPERATION-OPTIONS ...})
+
+ -- Operation: `compile-op'
+     This operation compiles the specified component.  A
+     `cl-source-file' will be `compile-file''d.  All the children and
+     dependencies of a system or module will be recursively compiled by
+     `compile-op'.
+
+     `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',
+     all these dependencies will be loaded as well as compiled; yet,
+     some parts of the system main remain unloaded, because nothing
+     depends on them.  Use `load-op' to load a system.
+
+ -- Operation: `load-op'
+     This operation loads the compiled code for a specified component.
+     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'.
+
+     `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
+     parent's dependencies.
+
+ -- 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'
+     This operation will perform some tests on the module.  The default
+     method will do nothing.  The default dependency is to require
+     `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'
+     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.
+
+     `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
+     the dynamic linking involved in loading tens of individual fasls
+     can be noticeably more expensive than loading a single one.
+
+     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
+     delivered with the fasl will look like this:
+          (defsystem :mysystem :class :precompiled-system
+              :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
+     source-registry from the filesystem.
+
+     The `program-op' operation will create an executable program from
+     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
+     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
+     current Lisp image upon completion.  See the example in
+     `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
+     ECL, Lisp files too), and its monolithic equivalent
+     `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).
+
+     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
+     separate system `asdf-bundle', itself descended from the ECL-only
+     `asdf-ecl'.
+
+     The pathname of the output of bundle operations is subject to
+     output-translation as usual, unless the operation is equal to the
+     `:build-operation' argument to `defsystem'.  This behavior is not
+     very satisfactory and may change in the future.  Maybe you have
+     suggestions on how to better configure it?
+
+ -- 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.
+
+
+File: asdf.info,  Node: Creating new operations,  Prev: Predefined operations of ASDF,  Up: Operations
+
+6.1.2 Creating new operations
+-----------------------------
+
+ASDF was designed to be extensible in an object-oriented fashion.  To
+teach ASDF new tricks, a programmer can implement the behaviour he wants
+by creating a subclass of `operation'.
+
+   ASDF's pre-defined operations are in no way "privileged", but it is
+requested that developers never use the `asdf' package for operations
+they develop themselves.  The rationale for this rule is that we don't
+want to establish a "global asdf operation name registry", but also
+want to avoid name clashes.
+
+   Your operation _must_ usually provide methods for one or more of the
+following generic functions:
+
+   * `perform' Unless your operation, like `prepare-op', is for
+     dependency propagation only, the most important function for which
+     to define a method is usually `perform', which will be called to
+     perform the operation on a specified component, after all
+     dependencies have been performed.
+
+     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
+     returns the first and only list element.
+
+   * `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.
+
+     Your method may return two values, a list of pathnames, and a
+     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'
+     method.
+
+   * `component-depends-on' If the action of performing the operation
+     on a component has dependencies, you must define a method on
+     `component-depends-on'.
+
+     Your method will take as specialized arguments an operation and a
+     component which together identify an action, and return a list of
+     entries describing actions that this action depends on.  The
+     format of entries is described below.
+
+     It is _strongly_ advised that you should always append the results
+     of `(call-next-method)' to the results of your method, or
+     "interesting" failures will likely occur, unless you're a true
+     specialist of ASDF internals.  It is unhappily too late to
+     compatibly use the `append' method combination, but conceptually
+     that's the protocol that is being manually implemented.
+
+     Each entry returned by `component-depends-on' is itself a list.
+
+     The first element of an entry is an operation designator: either
+     an operation object designating itself, or a symbol that names an
+     operation class (that ASDF will instantiate using
+     `make-operation').  For instance, `load-op', `compile-op' and
+     `prepare-op' are common such names, denoting the respective
+     operations.
+
+     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
+     current component's parent as parent, and the identifier as second
+     argument.  The identifier is typically a string, a symbol (to be
+     downcased as per `coerce-name'), or a list of strings or symbols.
+     In particular, the empty list `nil' denotes the parent itself.
+
+
+   An operation _may_ provide methods for the following generic
+functions:
+
+   * `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.
+
+   * `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').
+
+     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'.
+
+
+   Operations that print output should send that output to the standard
+CL stream `*standard-output*', as the Lisp compiler and loader do.
+
+
+File: asdf.info,  Node: Components,  Next: Functions,  Prev: Operations,  Up: The object model of ASDF
+
+6.2 Components
+==============
+
+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'.
+
+   A "system designator" is a system itself, or a string or symbol that
+behaves just like any other component name (including with regard to
+the case conversion rules for component names).
+
+   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)
+     Given a system designator, `find-system' finds and returns a
+     system.  If no system is found, an error of type
+     `missing-component' is thrown, or `nil' is returned if `error-p'
+     is false.
+
+     To find and update systems, `find-system' funcalls each element in
+     the `*system-definition-search-functions*' list, expecting a
+     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
+
+        * the pathname is different from that which was previously
+          loaded
+
+        * the file's `last-modified' time exceeds the `last-modified'
+          time of the system in memory
+
+     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.
+
+ -- Function: find-component base path
+     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.
+
+     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.
+
+     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.
+
+     If BASE is a component object, it designates itself.
+
+     If BASE is null, then PATH is used as the base, with `nil' as the
+     path.
+
+     If BASE is a string, or symbol denoting a string via `coerce-name',
+     it designates a system as per `find-system'.
+
+     If BASE is a `cons' cell, it designates the component found by
+     `find-component' with its `car' as base and `cdr' as path.
+
+* Menu:
+
+* Common attributes of components::
+* Pre-defined subclasses of component::
+* Creating new component types::
+
+
+File: asdf.info,  Node: Common attributes of components,  Next: Pre-defined subclasses of component,  Prev: Components,  Up: Components
+
+6.2.1 Common attributes of components
+-------------------------------------
+
+All components, regardless of type, have the following attributes.  All
+attributes except `name' are optional.
+
+6.2.1.1 Name
+............
+
+A component name is a string or a symbol.  If a symbol, its name is
+taken and lowercased.
+
+   Unless overridden by a `:pathname' attribute, the name will be
+interpreted as a pathname specifier according to a Unix-style syntax.
+*Note Pathname specifiers: The defsystem grammar.
+
+6.2.1.2 Version identifier
+..........................
+
+This optional attribute specifies a version for the current component.
+The version should typically be a string of integers separated by dots,
+for example `1.0.11'.  For more information on version specifiers, see
+*note The defsystem grammar::.
+
+   A version may then be queried by the generic function
+`version-satisfies', to see if `:version' dependencies are satisfied,
+and when specifying dependencies, a constraint of minimal version to
+satisfy can be specified using e.g. `(:version "mydepname" "1.0.11")'.
+
+   Note that in the wild, we typically see version numbering only on
+components of type `system'.  Presumably it is much less useful within
+a given system, wherein the library author is responsible to keep the
+various files in synch.
+
+6.2.1.3 Required features
+.........................
+
+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))'
+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.
+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.
+
+6.2.1.4 Dependencies
+....................
+
+This attribute specifies dependencies of the component on its siblings.
+It is optional but often necessary.
+
+   There is an excitingly complicated relationship between the initarg
+and the method that you use to ask about dependencies
+
+   Dependencies are between (operation component) pairs.  In your
+initargs for the component, you can say
+
+     :in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))
+                   (load-op (load-op "foo")))
+
+   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,
+
+   * before performing `load-op', we have to load FOO
+
+   The syntax is approximately
+
+(this-op @{(other-op required-components)@}+)
+
+simple-component-name := string
+                      |  symbol
+
+required-components := simple-component-name
+                     | (required-components required-components)
+
+component-name := simple-component-name
+                | (:version simple-component-name minimum-version-object)
+
+   Side note:
+
+   This is on a par with what ACL defsystem does.  mk-defsystem is less
+general: it has an implied dependency
+
+  for all source file x, (load x) depends on (compile x)
+
+   and using a `:depends-on' argument to say that B depends on A
+_actually_ means that
+
+  (compile b) depends on (load a)
+
+   This is insufficient for e.g. the McCLIM system, which requires that
+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
+operation can be queried using `(component-depends-on operation
+component)', which returns a list
+
+     ((load-op "a") (load-op "b") (compile-op "c") ...)
+
+   `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.
+
+   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
+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
+(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.
+
+6.2.1.5 pathname
+................
+
+This attribute is optional and if absent (which is the usual case), the
+component name will be used.
+
+   *Note Pathname specifiers: The defsystem grammar, for an explanation
+of how this attribute is interpreted.
+
+   Note that the `defsystem' macro (used to create a "top-level" system)
+does additional processing to set the filesystem location of the top
+component in that system.  This is detailed elsewhere. *Note Defining
+systems with defsystem::.
+
+6.2.1.6 properties
+..................
+
+This attribute is optional.
+
+   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.
+
+   `(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.
+
+* Menu:
+
+* Pre-defined subclasses of component::
+* Creating new component types::
+
+
+File: asdf.info,  Node: Pre-defined subclasses of component,  Next: Creating new component types,  Prev: Common attributes of components,  Up: Components
+
+6.2.2 Pre-defined subclasses of component
+-----------------------------------------
+
+ -- Component: source-file
+     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
+     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
+     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
+     purposes.
+
+     Subclasses of source-file exist for various languages.  _FIXME:
+     describe these._
+
+ -- Component: module
+     A module is a collection of sub-components.
+
+     A module component has the following extra initargs:
+
+        * `:components' the components contained in this module
+
+        * `:default-component-class' All children components which
+          don't specify their class explicitly are inferred to be of
+          this type.
+
+        * `:if-component-dep-fails' This attribute was removed in ASDF
+          3. Do not use it.  Use `:if-feature' instead.
+
+        * `:serial' When this attribute is set, each subcomponent of
+          this component is assumed to depend on all subcomponents
+          before it in the list given to `:components', i.e.  all of
+          them are loaded before a compile or load operation is
+          performed on it.
+
+
+     The default operation knows how to traverse a module, so most
+     operations will not need to provide methods specialised on modules.
+
+     `module' may be subclassed to represent components such as
+     foreign-language linked libraries or archive files.
+
+ -- Component: system
+     `system' is a subclass of `module'.
+
+     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
+     `defsystem' macro takes a `:class' keyword argument.
+
+
+File: asdf.info,  Node: Creating new component types,  Prev: Pre-defined subclasses of component,  Up: Components
+
+6.2.3 Creating new component types
+----------------------------------
+
+New component types are defined by subclassing one of the existing
+component classes and specializing methods on the new component class.
+
+   _FIXME: this should perhaps be explained more throughly, not only by
+example ..._
+
+   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
+`cl-source-file':
+
+     (defclass unportable-cl-source-file (cl-source-file)
+       ())
+
+   Function `asdf:implementation-type' (exported since 2.014.14) gives
+us the name of the subdirectory.  All that's left is to define how to
+calculate the pathname of an `unportable-cl-source-file'.
+
+     (defmethod component-pathname ((component unportable-cl-source-file))
+       (merge-pathnames*
+        (parse-unix-namestring (format nil "~(~A~)/" (asdf:implementation-type)))
+        (call-next-method)))
+
+   The new component type is used in a `defsystem' form in this way:
+
+     (defsystem :foo
+         :components
+         ((:file "packages")
+          ...
+          (:unportable-cl-source-file "threads"
+           :depends-on ("packages" ...))
+          ...
+         )
+
+
+File: asdf.info,  Node: Functions,  Prev: Components,  Up: The object model of ASDF
+
+6.3 Functions
+=============
+
+ -- version-satisfies: VERSION VERSION-SPEC
+     Does VERSION satisfy the VERSION-SPEC.  A generic function.  ASDF
+     provides built-in methods for VERSION being a `component' or
+     `string'.  VERSION-SPEC should be a string.  If it's a component,
+     its version is extracted as a string before further processing.
+
+     A version string satisfies the version-spec if after parsing, the
+     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::.
+
+     Note that in versions of ASDF prior to 3.0.1, including the entire
+     ASDF 1 and ASDF 2 series, `version-satisfies' would also require
+     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
+     with ASDF 3.0.1, `version-satisfies' does not treat the major
+     version number specially, and returns T simply if the first
+     argument designates a version that isn't older than the one
+     specified as a second argument.  If needs be, the `(:version ...)'
+     syntax for specifying dependencies could be in the future extended
+     to specify an exclusive upper bound for compatible versions as
+     well as an inclusive lower bound.
+
+
+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
+
+7 Controlling where ASDF searches for systems
+*********************************************
+
+7.1 Configurations
+==================
+
+Configurations specify paths where to find system files.
+
+  1. The search registry may use some hardcoded wrapping registry
+     specification.  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.
+
+  2. An application may explicitly initialize the source-registry
+     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.
+
+  3. The source registry will be configured from the environment
+     variable `CL_SOURCE_REGISTRY' if it exists.
+
+  4. The source registry will be configured from user configuration file
+     `$XDG_CONFIG_DIRS/common-lisp/source-registry.conf' (which
+     defaults to `~/.config/common-lisp/source-registry.conf') if it
+     exists.
+
+  5. The source registry will be configured from user configuration
+     directory `$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/'
+     (which defaults to `~/.config/common-lisp/source-registry.conf.d/')
+     if it exists.
+
+  6. The source registry will be configured from system configuration
+     file `/etc/common-lisp/source-registry.conf' if it exists/
+
+  7. The source registry will be configured from system configuration
+     directory `/etc/common-lisp/source-registry.conf.d/' if it exists.
+
+  8. The source registry will be configured from a default
+     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
+     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.
+
+
+   Each of these configurations is specified as an s-expression in a
+trivial domain-specific language (defined below).  Additionally, a more
+shell-friendly syntax is available for the environment variable
+(defined yet below).
+
+   Each of these configurations is only used if the previous
+configuration explicitly or implicitly specifies that it includes its
+inherited configuration.
+
+   Additionally, some implementation-specific directories may be
+automatically prepended to whatever directories are specified in
+configuration files, no matter if the last one inherits or not.
+
+7.2 Truenames and other dangers
+===============================
+
+One great innovation of the original ASDF was its ability to leverage
+`CL:TRUENAME' to locate where your source code was and where to build
+it, allowing for symlink farms as a simple but effective configuration
+mechanism that is easy to control programmatically.  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.
+
+   Addtionally, some people dislike truename, 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, and not to other files in the same intended
+project.  For these people, ASDF 3 allows to eschew the `TRUENAME'
+mechanism, by setting the variable ASDF:*RESOLVE-SYMLINKS* to `nil'.
+
+   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.
+
+7.3 XDG base directory
+======================
+
+Note that we purport to respect the XDG base directory specification as
+to where configuration files are located, where data files are located,
+where output file caches are located.  Mentions of XDG variables refer
+to that document.
+
+`http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html'
+
+   This specification allows the user to specify some environment
+variables to customize how applications behave to his preferences.
+
+   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
+support for querying the Windows registry is not possible to do in
+reasonable amounts of portable Common Lisp code, ASDF 3 relies on the
+environment variables that Windows usually exports.
+
+7.4 Backward Compatibility
+==========================
+
+For backward compatibility as well as to provide a practical backdoor
+for hackers, ASDF will first search for `.asd' files in the directories
+specified in `asdf:*central-registry*' before it searches in the source
+registry above.
+
+   *Note Configuring ASDF to find your systems -- old style:
+Configuring ASDF.
+
+   By default, `asdf:*central-registry*' will be empty.
+
+   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.
+
+7.5 Configuration DSL
+=====================
+
+Here is the grammar of the s-expression (SEXP) DSL for source-registry
+configuration:
+
+     ;; 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. `"_darcs"' will match `#p"/foo/bar/_darcs/src/bar.asd"'
+
+   Pathnames are designated using another DSL, shared with the
+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.
+
+     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
+
+   For instance, as a simple case, my
+`~/.config/common-lisp/source-registry.conf', which is the default
+place ASDF looks for this configuration, once contained:
+     (:source-registry
+       (:tree (:home "cl")) ;; will expand to e.g. "/home/joeluser/cl/"
+       :inherit-configuration)
+
+7.6 Configuration Directories
+=============================
+
+Configuration directories consist in files each containing a list of
+directives without any enclosing `(:source-registry ...)' 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 list.
+
+   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.
+
+   The convention is that, for sorting purposes, the names of files in
+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'.
+
+   Directories may be included by specifying a directory pathname or
+namestring in an `:include' directive, e.g.:
+
+     	(:include "/foo/bar/")
+
+   Hence, to achieve the same effect as my example
+`~/.config/common-lisp/source-registry.conf' above, I could simply
+create a file
+`~/.config/common-lisp/source-registry.conf.d/33-home-fare-cl.conf'
+alone in its directory with the following contents:
+     (:tree "/home/fare/cl/")
+
+7.6.1 The :here directive
+-------------------------
+
+The `:here' directive is an absolute pathname designator that refers to
+the directory containing the configuration file currently being
+processed.
+
+   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.
+
+   Consider a person X who has set up the source code repository for a
+complex project with a master directory `dir/'.  Ordinarily, one might
+simply have the user add a directive that would look something like
+this:
+        (: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
+the following:
+     (:source-registry
+        (:tree (:here "src/lisp/"))
+        (:tree (:here "extlib/lisp"))
+        (:directory (:here "outlier/")))
+
+   Then when someone else (call her Y) checks out a copy of this
+repository, she need only add
+     (:include "/path/to/my/checkout/directory/asdf.conf")
+   to one of her previously-existing asdf source location configuration
+files, or invoke `initialize-source-registry' 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 directory
+according to X's (relative) instructions.
+
+7.7 Shell-friendly syntax for configuration
+===========================================
+
+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
+
+   * paths are separated    by a `:' (colon) on Unix platforms
+(including cygwin),    by a `;' (semicolon) on other platforms (mainly,
+Windows).
+
+   * each entry is a directory to add to the search path.
+
+   * 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.
+
+7.8 Search Algorithm
+====================
+
+In case that isn't clear, the semantics of the configuration is that
+when searching for a system of a given name, directives are processed
+in order.
+
+   When looking in a directory, if the system is found, the search
+succeeds, otherwise it continues.
+
+   When looking in a tree, if one system is found, the search succeeds.
+If multiple systems are found, the consequences are unspecified: the
+search may succeed with any of the found systems, or an error may be
+raised.  ASDF currently returns the first system found, XCVB currently
+raised an error.  If none is found, the search continues.
+
+   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.  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
+`asdf::*default-source-registry-exclusions*'.
+
+   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
+Configurations: Controlling where ASDF searches for systems. above).
+
+7.9 Caching Results
+===================
+
+The implementation is allowed to either eagerly compute the information
+from the configurations and file system, or to lazily re-compute it
+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.
+
+7.10 Configuration API
+======================
+
+The specified functions are exported from your build system's package.
+Thus for ASDF the corresponding functions are in package ASDF, and for
+XCVB the corresponding functions are in package XCVB.
+
+ -- Function: initialize-source-registry &optional PARAMETER
+     will read the configuration and initialize all internal variables.
+       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).
+
+ -- Function: clear-source-registry
+     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.
+
+ -- Function: ensure-source-registry &optional PARAMETER
+     checks whether a source registry has been initialized.     If not,
+     initialize it with the given PARAMETER.
+
+   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
+configuration to be read.  If you change a configuration file, you need
+to explicitly `initialize-source-registry' again, or maybe simply to
+`clear-source-registry' (or `clear-configuration') which will cause the
+initialization to happen next time around.
+
+7.11 Status
+===========
+
+This mechanism is vastly successful, and we have declared that
+`asdf:*central-registry*' is not recommended anymore, though we will
+continue to support it.  All hooks into implementation-specific search
+mechanisms have been integrated in the `wrapping-source-registry' that
+everyone uses implicitly.
+
+7.12 Rejected ideas
+===================
+
+Alternatives I considered and rejected included:
+
+  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
+     cleanups and extensions.
+
+  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.
+
+  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.
+
+  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.
+
+   I've been suggested the below features, but have rejected them, for
+the sake of keeping ASDF no more complex than strictly necessary.
+
+   *   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)'.
+
+   *    The possibility to register individual files instead of
+     directories.
+
+   *   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'
+
+   *   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.
+
+7.13 TODO
+=========
+
+   * Add examples
+
+7.14 Credits for the source-registry
+====================================
+
+Thanks a lot to Stelian Ionescu for the initial idea.
+
+   Thanks to Rommel Martinez for the initial implementation attempt.
+
+   All bad design ideas and implementation bugs are to mine, not theirs.
+But so are good design ideas and elegant implementation tricks.
+
+   -- Francois-Rene Rideau <fare at tunes.org>, Mon, 22 Feb 2010 00:07:33
+-0500
+
+
+File: asdf.info,  Node: Controlling where ASDF saves compiled files,  Next: Error handling,  Prev: Controlling where ASDF searches for systems,  Up: Top
+
+8 Controlling where ASDF saves compiled files
+*********************************************
+
+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
+to mitigate the problem.
+
+8.1 Configurations
+==================
+
+Configurations specify mappings from input locations to output
+locations.  Once again we rely on the XDG base directory specification
+for configuration.  *Note XDG base directory: Controlling where ASDF
+searches for systems.
+
+  1. Some hardcoded wrapping output translations configuration may be
+     used.  This allows special output translations (or usually,
+     invariant directories) to be specified corresponding to the
+     similar special entries in the source registry.
+
+  2. An application may explicitly initialize the output-translations
+     configuration using the Configuration API in which case this takes
+     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.
+
+  3. The source registry will be configured from the environment
+     variable `ASDF_OUTPUT_TRANSLATIONS' if it exists.
+
+  4. The source registry will be configured from user configuration file
+     `$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf'
+     (which defaults to
+     `~/.config/common-lisp/asdf-output-translations.conf') if it
+     exists.
+
+  5. The source registry will be configured from user configuration
+     directory
+     `$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf.d/'
+     (which defaults to
+     `~/.config/common-lisp/asdf-output-translations.conf.d/') if it
+     exists.
+
+  6. The source registry will be configured from system configuration
+     file `/etc/common-lisp/asdf-output-translations.conf' if it exists.
+
+  7. The source registry will be configured from system configuration
+     directory `/etc/common-lisp/asdf-output-translations.conf.d/' if
+     it exists.
+
+
+   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).
+
+   Each of these configurations is only used if the previous
+configuration explicitly or implicitly specifies that it includes its
+inherited configuration.
+
+   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.
+
+8.2 Backward Compatibility
+==========================
+
+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.
+
+   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
+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.
+
+   Nevertheless, if you are a fan of `ASDF-Binary-Locations', we
+provide a limited emulation mode:
+
+ -- 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
+     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
+     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.
+     Note however that as an extension the `:source-to-target-mappings'
+     keyword argument will accept any valid pathname designator for
+     `asdf-output-translations' instead of just strings and pathnames.
+
+   If you insist, you can also keep using the old
+`ASDF-Binary-Locations' (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 `asdf-output-translations' with
+`(asdf:disable-output-translations)', or you might experience
+"interesting" issues.
+
+   Also, note that output translation is enabled by default.  To
+disable it, use `(asdf:disable-output-translations)'.
+
+8.3 Configuration DSL
+=====================
+
+Here is the grammar of the SEXP DSL for `asdf-output-translations'
+configuration:
+
+;; A configuration is single SEXP starting with keyword :source-registry
+;; followed by a list of directives.
+CONFIGURATION := (:output-translations 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
+
+    ;; include a configuration file or directory
+    (:include PATHNAME-DESIGNATOR) |
+
+    ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/ or something.
+    :enable-user-cache |
+    ;; Disable global cache. Map / to /
+    :disable-cache |
+
+    ;; add a single directory to be scanned (no recursion)
+    (DIRECTORY-DESIGNATOR DIRECTORY-DESIGNATOR)
+
+    ;; use a function to return the translation of a directory designator
+    (DIRECTORY-DESIGNATOR (:function TRANSLATION-FUNCTION))
+
+DIRECTORY-DESIGNATOR :=
+    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
+
+TRANSLATION-FUNCTION :=
+    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
+
+   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
+`/**/*.*'.  You can specify more fine-grained patterns by using a
+pathname object as the last component e.g.
+`#p"some/path/**/foo*/bar-*.fasl"'
+
+   You may use `#+features' to customize the configuration file.
+
+   The second designator of a mapping may be `nil', indicating that
+files are not mapped to anything but themselves (same as if the second
+designator was the same as the first).
+
+   When the first designator is `t', the mapping always matches.  When
+the first designator starts with `:root', the mapping matches any host
+and device.  In either of these cases, if the second designator isn't
+`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
+configuration file, or you may use
+`enable-asdf-binary-locations-compatibility' with
+`:centralize-lisp-binaries nil' which will do the same thing internally
+for you:
+  #.(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
+:**/ :implementation :*.*.*))'
+
+   `:include' statements cause the search to recurse with the path
+specifications from the file specified.
+
+   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"
+     "common-lisp" :implementation)'.
+
+   * `: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.
+
+8.4 Configuration Directories
+=============================
+
+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
+list.
+
+   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.
+
+   The convention is that, for sorting purposes, the names of files in
+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'.
+
+   Directories may be included by specifying a directory pathname or
+namestring in an `:include' directive, e.g.:
+	(:include "/foo/bar/")
+
+8.5 Shell-friendly syntax for configuration
+===========================================
+
+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).
+
+   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
+that the directory specified first is to be left untranslated (which
+has the same effect as if the directory had been repeated).
+
+8.6 Semantics of Output Translations
+====================================
+
+From the specified configuration, a list of mappings is extracted in a
+straightforward way: mappings are collected in order, recursing through
+included or inherited configuration as specified.  To this list is
+prepended some implementation-specific mappings, and is appended a
+global default.
+
+   The list is then compiled to a mapping table as follows: for each
+entry, in order, resolve the first designated directory into an actual
+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
+location to the output location, and add another mapping from the
+output location to itself (unless a mapping already exists for the
+output location).
+
+   Based on the table, a mapping function is defined, mapping source
+pathnames to output pathnames: given a source pathname, locate the
+longest matching prefix in the source column of the mapping table.
+Replace that prefix by the corresponding output column in the same row
+of the table, and return the result.  If no match is found, return the
+source pathname.  (A global default mapping the filesystem root to
+itself may ensure that there will always be a match, with same
+fall-through semantics).
+
+8.7 Caching Results
+===================
+
+The implementation is allowed to either eagerly compute the information
+from the configurations and file system, or to lazily re-compute it
+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.
+
+8.8 Output location API
+=======================
+
+The specified functions are exported from package ASDF.
+
+ -- Function: initialize-output-translations &optional PARAMETER
+     will read the configuration and initialize all internal variables.
+       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).
+
+ -- Function: disable-output-translations
+     will initialize output translations in a way    that maps every
+     pathname to itself,    effectively disabling the output
+     translation facility.
+
+ -- Function: clear-output-translations
+     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.
+
+ -- Function: ensure-output-translations &optional PARAMETER
+     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.
+
+ -- Function: apply-output-translations PATHNAME
+     Applies the configured output location translations to PATHNAME
+     (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
+===================================
+
+Thanks a lot to Bjorn Lindberg and Gary King for
+`ASDF-Binary-Locations', and to Peter van Eynde for `Common Lisp
+Controller'.
+
+   All bad design ideas and implementation bugs are to mine, not theirs.
+But so are good design ideas and elegant implementation tricks.
+
+   -- Francois-Rene Rideau <fare at tunes.org>
+
+
+File: asdf.info,  Node: Error handling,  Next: Miscellaneous additional functionality,  Prev: Controlling where ASDF saves compiled files,  Up: Top
+
+9 Error handling
+****************
+
+9.1 ASDF errors
+===============
+
+If ASDF detects an incorrect system definition, it will signal a
+generalised instance of `SYSTEM-DEFINITION-ERROR'.
+
+   Operations may go wrong (for example when source files contain
+errors).  These are signalled using generalised instances of
+`OPERATION-ERROR'.
+
+9.2 Compilation error and warning handling
+==========================================
+
+ASDF checks for warnings and errors when a file is compiled.  The
+variables *COMPILE-FILE-WARNINGS-BEHAVIOUR* and
+*COMPILE-FILE-ERRORS-BEHAVIOR* control the handling of any such events.
+The valid values for these variables are `:error', `:warn', and
+`:ignore'.
+
+
+File: asdf.info,  Node: Miscellaneous additional functionality,  Next: Getting the latest version,  Prev: Error handling,  Up: Top
+
+10 Miscellaneous additional functionality
+*****************************************
+
+ASDF includes several additional features that are generally useful for
+system definition and development.
+
+10.1 Controlling file compilation
+=================================
+
+When declaring a component (system, module, file), you can specify a
+keyword argument `:around-compile function'.  If left unspecified (and
+therefore unbound), the value will be inherited from the parent
+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'
+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
+function that will invoke `compile-file*' with various arguments; the
+around-compile hook may supply additional keyword arguments to pass to
+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.
+
+   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
+the hook with `nil' for all the modules and files that are compiled
+before the hook is defined.
+
+   Using this hook, you may achieve such effects as: locally renaming
+packages, binding *READTABLES* and other syntax-controlling variables,
+handling warnings and other conditions, proclaiming consistent
+optimization settings, saving code coverage information, maintaining
+meta-data about compilation timings, setting gensym counters and PRNG
+seeds and other sources of non-determinism, overriding the
+source-location and/or timestamping systems, checking that some
+compile-time side-effects were properly balanced, etc.
+
+   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
+===============================================
+
+Starting with ASDF 2.21, components accept a `:encoding' option so
+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
+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'.
+
+   In other words, there now are plenty of extension hooks, but by
+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'.
+
+   We invite you to embrace UTF-8 as the encoding for non-ASCII
+characters starting today, even without any explicit specification in
+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.
+
+   If you need non-standard character encodings for your source code,
+use the extension system `asdf-encodings', by specifying
+`:defsystem-depends-on (:asdf-encodings)' in your `defsystem'.  This
+extension system will register support for more encodings using the
+`*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
+============================
+
+These functions are exported by ASDF for your convenience.
+
+ -- Function: system-relative-pathname system name &key type
+     It's often handy to locate a file relative to some system.  The
+     `system-relative-pathname' function meets this need.
+
+     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
+     component pathname specifier by `coerce-pathname'. *Note Pathname
+     specifiers: The defsystem grammar.
+
+     It returns a pathname built from the location of the system's
+     source directory and the relative pathname. For example:
+
+          > (asdf:system-relative-pathname 'cl-ppcre "regex.data")
+          #P"/repository/other/cl-ppcre/regex.data"
+
+
+ -- Function: system-source-directory system-designator
+     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
+     `system-source-directory' to find such files.  Returns a pathname
+     object.  The SYSTEM-DESIGNATOR may be a string, symbol, or ASDF
+     system object.
+
+ -- Function: clear-system system-designator
+     It is sometimes useful to force recompilation of a previously
+     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.
+
+ -- Function: register-preloaded-system name &rest keys
+     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.
+
+ -- Function: run-shell-command control-string &rest args
+     This function is obsolete and present only for the sake of
+     backwards-compatibility: "If it's not backwards, it's not
+     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
+     documentation is only for the purpose of your migrating away from
+     it in a way that preserves semantics.
+
+     Instead we recommend the use `run-program', described in the next
+     section, and available as part of ASDF since ASDF 3.
+
+     `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
+     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).
+
+10.4 Some Utility Functions
+===========================
+
+The below functions are not exported by ASDF itself, but by UIOP,
+available since ASDF 3.  Some of them have precursors in ASDF 2, but we
+recommend you rely on ASDF 3 for active developments.  UIOP provides
+many, many more utility functions, and we recommend you read its README
+and sources for more information.
+
+ -- Function: parse-unix-namestring name &key type defaults dot-dot
+          ensure-directory &allow-other-keys
+     Coerce NAME into a PATHNAME using standard Unix syntax.
+
+     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.  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',
+     first downcase its name and treat it as a string.  When given a
+     `string', portably decompose it into a pathname as below.
+
+     `#\/' separates directory components.
+
+     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'.
+
+     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'.
+
+     `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.
+
+     For relative pathnames, these components (and hence the defaults)
+     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*'.
+
+     Arbitrary keys are accepted, and the parse result is passed to
+     `ensure-pathname' with those keys, removing TYPE, DEFAULTS and
+     DOT-DOT.  When you're manipulating pathnames that are supposed to
+     make sense portably even though the OS may not be Unixish, we
+     recommend you use `:want-relative t' to throw an error if the
+     pathname is absolute
+
+ -- Function: merge-pathnames* specified &optional defaults
+     This function is a replacement for `merge-pathnames' that uses the
+     host and device from the DEFAULTS rather than the SPECIFIED
+     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.
+
+
+ -- Function: subpathname pathname subpath &key type
+     This function takes a PATHNAME and a SUBPATH and a TYPE.  If
+     SUBPATH is already a `pathname' object (not namestring), and is an
+     absolute pathname at that, it is returned unchanged; otherwise,
+     SUBPATH is turned into a relative pathname with given TYPE as per
+     `parse-unix-namestring' with `:want-relative t :type 'TYPE, then
+     it is merged with the `pathname-directory-pathname' of PATHNAME,
+     as per `merge-pathnames*'.
+
+     We strongly encourage the use of this function for portably
+     resolving relative pathnames in your code base.
+
+ -- Function: subpathname* pathname subpath &key type
+     This function returns `nil' if the base PATHNAME is `nil',
+     otherwise acts like `subpathname'.
+
+ -- Function: run-program 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
+
+     `run-program' takes a COMMAND argument that is either a list of a
+     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
+     keyword arguments to configure its behavior.
+
+     `run-program' 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, and returned only one value, the one for the output
+     if any handler was specified, or else the exit code; please
+     upgrade ASDF, or at least UIOP, to rely on the new enhanced
+     behavior.)
+
+     OUTPUT is its most important argument; it specifies how the output
+     is captured and processed.  If it is `nil', then the output is
+     redirected to the null device, that will discard it.  If it is
+     `:interactive', then it is inherited from the current process
+     (beware: this may be different from your *STANDARD-OUTPUT*, and
+     under SLIME will be on your `*inferior-lisp*' buffer).  If it is
+     `t', output goes to your current *STANDARD-OUTPUT* stream.
+     Otherwise, OUTPUT should be a value that is a suitable first
+     argument to `slurp-input-stream' (see below), or a list of such a
+     value and keyword arguments.  In this case, `run-program' will
+     create a temporary stream for the program output; the program
+     output, in that stream, will be processed by a call to
+     `slurp-input-stream', using OUTPUT as the first argument (or if
+     it's a list the first element of OUTPUT and the rest as keywords).
+     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.
+
+     ERROR-OUTPUT is similar to OUTPUT, except that the resulting value
+     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.
+
+     INPUT is similar to OUTPUT, except that `vomit-output-stream' is
+     used, no value is returned, and `t' designates the
+     *STANDARD-INPUT*.
+
+     `element-type' and `external-format' are passed on to your Lisp
+     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
+     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.
+
+     `force-shell' 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 `/bin/sh' on Unix or `CMD.EXE' on Windows, except
+     on implementations that (erroneously, IMNSHO) insist on consulting
+     `$SHELL' like clisp.
+
+     `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.
+
+     `run-program' works on all platforms supported by ASDF, except
+     Genera.  See the source code for more documentation.
+
+
+ -- Function: slurp-input-stream processor input-stream &key
+     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'.
+
+
+
+File: asdf.info,  Node: Getting the latest version,  Next: FAQ,  Prev: Miscellaneous additional functionality,  Up: Top
+
+11 Getting the latest version
+*****************************
+
+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.
+
+   The `release' branch is what cautious people should be using; it has
+usually been tested more, and releases are cut at a point where there
+isn't any known unresolved issue.
+
+   You may get the ASDF source repository using git: `git clone
+git://common-lisp.net/projects/asdf/asdf.git'
+
+   You will find the above referenced tags in this repository.  You can
+also browse the repository on
+`http://common-lisp.net/gitweb?p=projects/asdf/asdf.git'.
+
+   Discussion of ASDF development is conducted on the mailing list
+`asdf-devel at common-lisp.net'.
+`http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel'
+
+
+File: asdf.info,  Node: FAQ,  Next: TODO list,  Prev: Getting the latest version,  Up: Top
+
+12 FAQ
+******
+
+12.1 "Where do I report a bug?"
+===============================
+
+ASDF bugs are tracked on launchpad: `https://launchpad.net/asdf'.
+
+   If you're unsure about whether something is a bug, or for general
+discussion, use the asdf-devel mailing list
+(http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel)
+
+12.2 "What has changed between ASDF 1 and ASDF 2?"
+==================================================
+
+12.2.1 What are ASDF 1 and ASDF 2?
+----------------------------------
+
+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.
+
+   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.
+
+   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.
+
+   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.
+
+12.2.2 ASDF can portably name files in subdirectories
+-----------------------------------------------------
+
+Common Lisp namestrings are not portable, except maybe for logical
+pathnamestrings, that themselves have various limitations and require a
+lot of setup that is itself ultimately non-portable.
+
+   In ASDF 1, the only portable ways to refer to pathnames inside
+systems and components were very awkward, using `#.(make-pathname ...)'
+and `#.(merge-pathnames ...)'.  Even the above were themselves were
+inadequate in the general case due to host and device issues, unless
+horribly complex patterns were used.  Plenty of simple cases that
+looked portable actually weren't, leading to much confusion and
+greavance.
+
+   ASDF 2 implements its own portable syntax for strings as pathname
+specifiers.  Naming files within a system definition becomes easy and
+portable again.  *Note asdf:system-relative-pathname: Miscellaneous
+additional functionality, `merge-pathnames*', `coerce-pathname'.
+
+   On the other hand, there are places where systems used to accept
+namestrings where you must now use an explicit pathname object:
+`(defsystem ... :pathname "LOGICAL-HOST:PATH;TO;SYSTEM;" ...)' must now
+be written with the `#p' syntax: `(defsystem ... :pathname
+#p"LOGICAL-HOST:PATH;TO;SYSTEM;" ...)'
+
+   *Note Pathname specifiers: The defsystem grammar.
+
+12.2.3 Output translations
+--------------------------
+
+A popular feature added to ASDF was output pathname translation:
+`asdf-binary-locations', `common-lisp-controller', `cl-launch' and
+other hacks were all implementing it in ways both mutually incompatible
+and difficult to configure.
+
+   Output pathname translation is essential to share 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.
+
+   In ASDF 2, a standard mechanism is provided for that,
+`asdf-output-translations', with sensible defaults, adequate
+configuration languages, a coherent set of configuration files and
+hooks, and support for non-Unix platforms.
+
+   *Note Controlling where ASDF saves compiled files::.
+
+12.2.4 Source Registry Configuration
+------------------------------------
+
+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.
+
+   This made for awkward configuration files and startup scripts that
+could not be shared between users, managed by administrators or
+packaged by distributions.
+
+   ASDF 2 provides a well-documented way to configure ASDF, with
+sensible defaults, adequate configuration languages, and a coherent set
+of configuration files and hooks.
+
+   We believe it's a vast improvement because it decouples application
+distribution from library distribution.  The application writer can
+avoid thinking where the libraries are, and the library distributor
+(dpkg, clbuild, advanced user, etc.)  can configure them once and for
+every application.  Yet settings can be easily overridden where needed,
+so whoever needs control has exactly as much as required.
+
+   At the same time, ASDF 2 remains compatible with the old magic you
+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.
+
+   *Note Controlling where ASDF searches for systems::.
+
+12.2.5 Usual operations are made easier to the user
+---------------------------------------------------
+
+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'.
+
+   In ASDF 2, you can use shortcuts for the usual operations:
+`(asdf:load-system :foo)', and similarly for `compile-system',
+`test-system'.
+
+12.2.6 Many bugs have been fixed
+--------------------------------
+
+The following issues and many others have been fixed:
+
+   * 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.
+
+   * Performance has been notably improved for large systems (say with
+     thousands of components) by using hash-tables instead of linear
+     search, and linear-time list accumulation instead of
+     quadratic-time recursive appends.
+
+   * Many features used to not be portable, especially where pathnames
+     were involved.  Windows support was notably quirky because of such
+     non-portability.
+
+   * The internal test suite used to massively fail on many
+     implementations.  While still incomplete, it now fully passes on
+     all implementations supported by the test suite, except for GCL
+     (due to GCL bugs).
+
+   * Support was lacking for some implementations.  ABCL and GCL were
+     notably wholly broken.  ECL extensions were not integrated with
+     ASDF release.
+
+   * The documentation was grossly out of date.
+
+
+12.2.7 ASDF itself is versioned
+-------------------------------
+
+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
+available and worked, or take great pains to have the correct version
+of ASDF installed.
+
+   With ASDF 2, we provide a new stable set of working features that
+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
+check the availability of a version no earlier than required.
+
+12.2.8 ASDF can be upgraded
+---------------------------
+
+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
+upgrade, though, most notably the fact that after you upgrade ASDF, you
+must also reload or upgrade all ASDF extensions.
+
+12.2.9 Decoupled release cycle
+------------------------------
+
+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.
+
+   With ASDF 2, upgrade is possible, easy and can be recommended.  This
+means that vendors can safely ship a recent version of ASDF, confident
+that if a user isn't fully satisfied, he can easily upgrade ASDF and
+deal with a supported recent version of it.  This means that release
+cycles will be causally decoupled, the practical consequence of which
+will mean faster convergence towards the latest version for everyone.
+
+12.2.10 Pitfalls of the transition to ASDF 2
+--------------------------------------------
+
+The main pitfalls in upgrading to ASDF 2 seem to be related to the
+output translation mechanism.
+
+   * 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.
+     *Note "How can I wholly disable the compiler output cache?": FAQ.
+
+   * Some systems in the large have been known not to play well with
+     output translations.  They were relatively easy to fix.  Once
+     again, it is also easy to disable output translations, or to
+     override its configuration.
+
+   * 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.
+     See `enable-asdf-binary-locations-compatibility' in *note Backward
+     Compatibility: Controlling where ASDF saves compiled files.  But
+     thou shalt not load ABL on top of ASDF 2.
+
+
+   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
+     some non-portable defsystems.  Notably, in the `:pathname' argument
+     to a `defsystem' and its components, a logical pathname (or
+     implementation-dependent hierarchical pathname) must now be
+     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).
+
+   * There is a slight performance bug, notably on SBCL, when initially
+     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
+     (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
+     configuration and not use any deep `:tree' entry but only
+     `:directory' entries or shallow `:tree' entries.  Or you can fix
+     your implementation to not be quite that slow when recursing
+     through directories.  _Update_: This performance bug fixed the
+     hard way in 2.010.
+
+   * On Windows, only LispWorks supports proper default configuration
+     pathnames based on the Windows registry.  Other implementations
+     make do with environment variables, that you may have to define
+     yourself if you're using an older version of Windows.  Windows
+     support is somewhat less tested than Unix support.  Please help
+     report and fix bugs.  _Update_: As of ASDF 2.21, all
+     implementations should now use the same proper default
+     configuration pathnames and they should actually work, though they
+     haven't all been tested.
+
+   * The mechanism by which one customizes a system so that Lisp files
+     may use a different extension from the default `.lisp' has changed.
+     Previously, the pathname for a component was lazily computed when
+     operating on a system, and you would `(defmethod source-file-type
+     ((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
+     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
+     *note How do I create a system definition where all the source
+     files have a .cl extension?: FAQ. below.
+
+
+12.3 Issues with installing the proper version of ASDF
+======================================================
+
+12.3.1 "My Common Lisp implementation comes with an outdated version of ASDF. What to do?"
+------------------------------------------------------------------------------------------
+
+We recommend you upgrade ASDF.  *Note Upgrading ASDF: Loading ASDF.
+
+   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.
+
+12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?"
+-------------------------------------------------------------------------------------
+
+Since ASDF 2, it should always be a good time to upgrade to a recent
+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.
+
+   As to how to include ASDF, we recommend the following:
+
+   * If ASDF isn't loaded yet, then `(require "asdf")' should load the
+     version of ASDF that is bundled with your system.  If possible so
+     should `(require "ASDF")'.  You may have it load some other
+     version configured by the user, if you allow such configuration.
+
+   * 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
+     appropriate code to this end.
+
+   * 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
+     your source distribution and precompile it in your binary
+     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.
+
+   * 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
+     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.
+
+   * 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.
+
+
+12.4 Issues with configuring ASDF
+=================================
+
+12.4.1 "How can I customize where fasl files are stored?"
+---------------------------------------------------------
+
+*Note Controlling where ASDF saves compiled files::.
+
+   Note that in the past there was an add-on to ASDF called
+`ASDF-binary-locations', developed by Gary King.  That add-on has been
+merged into ASDF proper, then superseded by the
+`asdf-output-translations' facility.
+
+   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
+source directory of some system, and use
+`asdf:apply-output-translations' to locate a file whose pathname has
+been translated by the facility.
+
+12.4.2 "How can I wholly disable the compiler output cache?"
+------------------------------------------------------------
+
+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/
+     echo ':disable-cache' > ~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf
+
+   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
+command (e.g. some call to `asdf:initialize-output-translations').
+
+   To disable the compiler output cache in Lisp processes run by your
+current shell, try (assuming `bash' or `zsh') (on Unix and cygwin only):
+
+     export ASDF_OUTPUT_TRANSLATIONS=/:
+
+   To disable the compiler output cache just in the current Lisp
+process, use (after loading ASDF but before using it):
+
+     (asdf:disable-output-translations)
+
+12.5 Issues with using and extending ASDF to define systems
+===========================================================
+
+12.5.1 "How can I cater for unit-testing in my system?"
+-------------------------------------------------------
+
+ASDF provides a predefined test operation, `test-op'.  *Note test-op:
+Predefined operations of ASDF.  The test operation, however, is largely
+left to the system definer to specify.  `test-op' has been a topic of
+considerable discussion on the asdf-devel mailing list
+(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?"
+-------------------------------------------------------------------
+
+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'.
+
+12.5.3 "How can I maintain non-Lisp (e.g. C) source files?"
+-----------------------------------------------------------
+
+See `cffi''s `cffi-grovel'.
+
+12.5.4 "I want to put my module's files at the top level.  How do I do this?"
+-----------------------------------------------------------------------------
+
+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
+adding a `:pathname ""' argument to the module description.  For
+example, here is how it could be done in the spatial-trees ASDF system
+definition for ASDF 2:
+
+     (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")))
+
+   All of the files in the `tree-impls' module are at the top level,
+instead of in a `tree-impls/' subdirectory.
+
+   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
+parsing a namestring are not portable.  A pathname can only be portably
+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?
+-------------------------------------------------------------------------------------------
+
+Starting with ASDF 2.014.14, you may just pass the builtin class
+`cl-source-file.cl' as the `:default-component-class' argument to
+`defsystem':
+
+     (defsystem my-cl-system
+       :default-component-class cl-source-file.cl
+       ...)
+
+   Another builtin class `cl-source-file.lsp' is offered for files
+ending in `.lsp'.
+
+   If you want to use a different extension for which ASDF doesn't
+provide builtin support, or want to support versions of ASDF earlier
+than 2.014.14 (but later than 2.000), you can define a class as follows:
+
+     ;; 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")))
+
+   Then you can use it as follows:
+     (defsystem my-cl-system
+       :default-component-class my-asdf-extension:cl-source-file.lis
+       ...)
+
+   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
+complications:
+
+     (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
+       ...)
+
+   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")
+
+
+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
+==============================================
+
+** packaging systems
+
+   *** 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.
+
+
+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.
+
+   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.
+
+   The `mk-defsystem' code for topologically sorting a module's
+dependency list was very useful.
+
+14.2 defsystem-4 proposal
+=========================
+
+Marco and Peter's proposal for defsystem 4 served as the driver for
+many of the features in here.  Notable differences are:
+
+   * We don't specify output files or output file extensions as part of
+     the system.
+
+     If you want to find out what files an operation would create, ask
+     the operation.
+
+   * We don't deal with CL packages
+
+     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)
+
+   * There is no proposal here that `defsystem' does version control.
+
+     A system has a given version which can be used to check
+     dependencies, but that's all.
+
+   The defsystem 4 proposal tends to look more at the external features,
+whereas this one centres on a protocol for system introspection.
+
+14.3 kmp's "The Description of Large Systems", MIT AI Memo 801
+==============================================================
+
+Available in updated-for-CL form on the web at
+`http://nhplace.com/kent/Papers/Large-Systems.html'
+
+   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 ]
+
+
+File: asdf.info,  Node: Concept Index,  Next: Function and Class Index,  Prev: Inspiration,  Up: Top
+
+Concept Index
+*************
+
+ [index ]
+* Menu:
+
+* :around-compile:                       Miscellaneous additional functionality.
+                                                              (line  12)
+* :asdf:                                 Introduction.        (line   6)
+* :asdf2:                                Introduction.        (line   6)
+* :asdf3:                                Introduction.        (line   6)
+* :compile-check:                        Miscellaneous additional functionality.
+                                                              (line  12)
+* :defsystem-depends-on:                 The defsystem grammar.
+                                                              (line 106)
+* :version <1>:                          The defsystem grammar.
+                                                              (line 214)
+* :version <2>:                          Common attributes of components.
+                                                              (line  22)
+* :version:                              The defsystem form.  (line  76)
+* :weakly-depends-on:                    The defsystem grammar.
+                                                              (line 114)
+* around-compile keyword:                Miscellaneous additional functionality.
+                                                              (line  12)
+* ASDF versions:                         Introduction.        (line   6)
+* ASDF-BINARY-LOCATIONS compatibility:   Controlling where ASDF saves compiled files.
+                                                              (line  81)
+* asdf-output-translations:              Controlling where ASDF saves compiled files.
+                                                              (line   6)
+* ASDF-related features:                 Introduction.        (line   6)
+* compile-check keyword:                 Miscellaneous additional functionality.
+                                                              (line  12)
+* component:                             Components.          (line   6)
+* component designator:                  Components.          (line   6)
+* link farm:                             Loading ASDF.        (line   6)
+* logical pathnames:                     The defsystem grammar.
+                                                              (line 233)
+* operation:                             Operations.          (line   6)
+* pathname specifiers:                   The defsystem grammar.
+                                                              (line 143)
+* serial dependencies:                   The defsystem grammar.
+                                                              (line 279)
+* system:                                Components.          (line   6)
+* system designator:                     Components.          (line   6)
+* system directory designator:           Loading ASDF.        (line   6)
+* Testing for ASDF:                      Introduction.        (line   6)
+* version specifiers:                    The defsystem grammar.
+                                                              (line 214)
+
+
+File: asdf.info,  Node: Function and Class Index,  Next: Variable Index,  Prev: Concept Index,  Up: Top
+
+Function and Class Index
+************************
+
+ [index ]
+* Menu:
+
+* 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.
+                                                              (line  12)
+* 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.
+                                                              (line  25)
+* load-source-op:                        Predefined operations of ASDF.
+                                                              (line  42)
+* load-system:                           Loading ASDF.        (line   6)
+* merge-pathnames*:                      Miscellaneous additional functionality.
+                                                              (line 329)
+* module:                                Pre-defined subclasses of component.
+                                                              (line  23)
+* 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)
+* source-file:                           Pre-defined subclasses of component.
+                                                              (line   7)
+* source-file-type:                      FAQ.                 (line 287)
+* subpathname:                           Miscellaneous additional functionality.
+                                                              (line 338)
+* subpathname*:                          Miscellaneous additional functionality.
+                                                              (line 350)
+* system:                                Pre-defined subclasses of component.
+                                                              (line  50)
+* SYSTEM-DEFINITION-ERROR:               Error handling.      (line   6)
+* 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)
+* version-satisfies:                     Common attributes of components.
+                                                              (line  22)
+
+
+File: asdf.info,  Node: Variable Index,  Prev: Function and Class Index,  Up: Top
+
+Variable Index
+**************
+
+ [index ]
+* Menu:
+
+* *central-registry*:                    Loading ASDF.        (line   6)
+* *compile-file-errors-behavior*:        Error handling.      (line  19)
+* *compile-file-warnings-behaviour*:     Error handling.      (line  19)
+* *default-source-registry-exclusions*:  Controlling where ASDF searches for systems.
+                                                              (line 319)
+* *features*:                            Introduction.        (line   6)
+* *system-definition-search-functions*:  Components.          (line   6)
+* ASDF_OUTPUT_TRANSLATIONS:              Controlling where ASDF saves compiled files.
+                                                              (line   6)
+
+
+
+Tag Table:
+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
+
+End Tag Table

=====================================
src/contrib/asdf/doc/asdf.pdf
=====================================
Binary files /dev/null and b/src/contrib/asdf/doc/asdf.pdf differ


View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/compare/419cdec64f8aebe4f9571cf87e359600d4e27ba8...48c324f4d74487e1b705e1cdbd64fea666348483
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cmucl-cvs/attachments/20150417/f82eca4e/attachment-0001.html>


More information about the cmucl-cvs mailing list