/usr/share/doc/cl-asdf/asdf/FAQ.html

<html lang="en">
<head>
<title>FAQ - 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="start" href="index.html#Top">
<link rel="prev" href="Getting-the-latest-version.html#Getting-the-latest-version" title="Getting the latest version">
<link rel="next" href="TODO-list.html#TODO-list" title="TODO list">
<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-2011 Daniel Barlow and contributors.

This manual Copyright (C) 2001-2011 Daniel Barlow and contributors.

This manual revised (C) 2009-2011 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>
<div class="node">
<a name="FAQ"></a>
<p>
Next:&nbsp;<a rel="next" accesskey="n" href="TODO-list.html#TODO-list">TODO list</a>,
Previous:&nbsp;<a rel="previous" accesskey="p" href="Getting-the-latest-version.html#Getting-the-latest-version">Getting the latest version</a>,
Up:&nbsp;<a rel="up" accesskey="u" href="index.html#Top">Top</a>
<hr>
</div>

<!-- node-name,  next,  previous,  up -->
<h2 class="chapter">12 FAQ</h2>

<h3 class="section">12.1 &ldquo;Where do I report a bug?&rdquo;</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 &ldquo;What has changed between ASDF 1 and ASDF 2?&rdquo;</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>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.html#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.html#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.html#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.html#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 significantly,
with many bugs squashed. 
In particular, dependencies were not correctly propagated
across submodules within a system but now are. 
The :version and :feature features 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 in the 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.html#FAQ">&ldquo;How can I wholly disable the compiler output cache?&rdquo;</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.html#Controlling-where-ASDF-saves-compiled-files">Backward Compatibility</a>. 
But thou shall 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.

     <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>: 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.

     <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.html#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-66"></a>

   </ul>

<h3 class="section">12.3 Issues with installing the proper version of ASDF</h3>

<h4 class="subsection">12.3.1 &ldquo;My Common Lisp implementation comes with an outdated version of ASDF. What to do?&rdquo;</h4>

<p>We recommend you upgrade ASDF. 
See <a href="Loading-ASDF.html#Loading-ASDF">Upgrading ASDF</a>.

   <p>If this does not work, it is a bug, and you should report it. 
See <a href="FAQ.html#FAQ">report-bugs</a>. 
In the meantime, you can load <samp><span class="file">asdf.lisp</span></samp> directly. 
See <a href="Loading-ASDF.html#Loading-ASDF">Loading an otherwise installed ASDF</a>.

<h4 class="subsection">12.3.2 &ldquo;I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?&rdquo;</h4>

<p>Starting with current candidate releases of ASDF 2,
it should always be a good time to upgrade to a recent 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. 
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.

     <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>default-source-registry</code>,
and you are welcome to include <samp><span class="file">asdf.asd</span></samp> amongst them.

     <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 &ldquo;How can I customize where fasl files are stored?&rdquo;</h4>

<p>See <a href="Controlling-where-ASDF-saves-compiled-files.html#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
&mdash; 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 &ldquo;How can I wholly disable the compiler output cache?&rdquo;</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' &gt; ~/.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 &ldquo;How can I cater for unit-testing in my system?&rdquo;</h4>

<p>ASDF provides a predefined test operation, <code>test-op</code>. 
See <a href="Predefined-operations-of-ASDF.html#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.html#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 &ldquo;How can I cater for documentation generation in my system?&rdquo;</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.html#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 &ldquo;How can I maintain non-Lisp (e.g. C) source files?&rdquo;</h4>

<p>See <code>cffi</code>'s <code>cffi-grovel</code>.

   <p><a name="report_002dbugs"></a>

<h4 class="subsection">12.5.4 &ldquo;I want to put my module's files at the top level.  How do I do this?&rdquo;</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 2. 
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) (m module))
       (declare (ignorable f m))
       "lis")
</pre>
   <!-- FIXME: Add a FAQ about how to use a new system class... -->
   </body></html>
cl-asdf 2:2.20-1 / usr / share / doc / cl-asdf / asdf / FAQ.html
