Skip to content
Snippets Groups Projects
asdf.texinfo 76.9 KiB
Newer Older
This operation will load the source for the files in a module
even if the source files have been compiled.
Systems sometimes have knotty dependencies
which require that sources are loaded
before they can be compiled.
This is how you do that.
If you are creating a component type,
you need to implement this operation --- at least, where meaningful.
@deffn Operation @code{test-op}

This operation will perform some tests on the module.
The default method will do nothing.
The default dependency is to require
@code{load-op} to be performed on the module first.
The default @code{operation-done-p} is that the operation is @emph{never} done
---
we assume that if you invoke the @code{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.
Robert P. Goldman's avatar
Robert P. Goldman committed
@end deffn

@c @deffn Operation test-system-version &key minimum

@c Asks the system whether it satisfies a version requirement.

@c The default method accepts a string, which is expected to contain of a
@c number of integers separated by #\. characters.  The method is not
@c recursive.  The component satisfies the version dependency if it has
@c the same major number as required and each of its sub-versions is
@c greater than or equal to the sub-version number required.

@c @lisp
@c (defun version-satisfies (x y)
@c   (labels ((bigger (x y)
@c           (cond ((not y) t)
@c                 ((not x) nil)
@c                 ((> (car x) (car y)) t)
@c                 ((= (car x) (car y))
@c                  (bigger (cdr x) (cdr y))))))
@c     (and (= (car x) (car y))
@c       (or (not (cdr y)) (bigger (cdr x) (cdr y))))))
@c @end lisp

@c If that doesn't work for your system, you can override it.  I hope
@c you have as much fun writing the new method as @verb{|#lisp|} did
@c reimplementing this one.
@c @end deffn

@c @deffn Operation feature-dependent-op

@c An instance of @code{feature-dependent-op} will ignore any components
@c which have a @code{features} attribute, unless the feature combination
@c it designates is satisfied by @code{*features*}.  This operation is
@c not intended to be instantiated directly, but other operations may
@c inherit from it.

@c @end deffn
@node  Creating new operations,  , Predefined operations of ASDF, Operations
@comment  node-name,  next,  previous,  up
@subsection 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 @code{operation}.
ASDF's pre-defined operations are in no way ``privileged'',
but it is requested that developers never use the @code{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.

An operation must provide methods for the following generic functions
when invoked with an object of type @code{source-file}:
@emph{FIXME describe this better}

@itemize

@item @code{output-files}
@item @code{perform}
The @code{perform} method must call @code{output-files}
to find out where to put its files,
because the user is allowed to override.
@item @code{output-files}
for local policy @code{explain}
@item @code{operation-done-p},
if you don't like the default one
Operations that print output should send that output to the standard
CL stream @code{*standard-output*}, as the Lisp compiler and loader do.

@node Components,  , Operations, The object model of ASDF
@comment  node-name,  next,  previous,  up
@section Components
@cindex component
@cindex system
@cindex system designator
@vindex *system-definition-search-functions*

A @dfn{component} represents a source file or
(recursively) a collection of components.
A @dfn{system} is (roughly speaking) a top-level component
that can be found via @code{find-system}.
A @dfn{system designator} is a string or symbol
and behaves just like any other component name
(including with regard to the case conversion rules for component names).


@defun find-system system-designator &optional (error-p t)

Given a system designator, @code{find-system} finds and returns a system.
If no system is found, an error of type
@code{missing-component} is thrown,
or @code{nil} is returned if @code{error-p} is false.

To find and update systems, @code{find-system} funcalls each element
in the @code{*system-definition-search-functions*} list,
expecting a pathname to be returned.
The resulting pathname is loaded if either of the following conditions is true:
@item
there is no system of that name in memory
@item
the file's @code{last-modified} time exceeds the @code{last-modified} time
of the system in memory
When system definitions are loaded from @file{.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 @code{defpackage} and @code{in-package} forms
in his system definition files, however,
so that they can be loaded manually if need be.

The default value of @code{*system-definition-search-functions*}
is a list of two functions.
The first function looks in each of the directories given
by evaluating members of @code{*central-registry*}
for a file whose name is the name of the system and whose type is @file{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 @code{source-registry}.
Hence, it is strongly advised to define a system
@var{foo} in the corresponding file @var{foo.asd}.
@end defun


@menu
* Common attributes of components::
* Pre-defined subclasses of component::
* Creating new component types::
@end menu

@node  Common attributes of components, Pre-defined subclasses of component, Components, Components
@comment  node-name,  next,  previous,  up
@subsection Common attributes of components

All components, regardless of type, have the following attributes.
All attributes except @code{name} are optional.

@subsubsection Name

A component name is a string or a symbol.
If a symbol, its name is taken and lowercased.
Unless overridden by a @code{:pathname} attribute,
the name will be interpreted as a pathname specifier according
to a Unix-style syntax. @xref{The defsystem grammar,,Pathname specifiers}.

@subsubsection Version identifier

This optional attribute is used by the test-system-version operation.
@xref{Predefined operations of ASDF}.
For the default method of @code{test-system-version},
the version should be a string of integers separated by dots,
for example @samp{1.0.11}.

@subsubsection Required features

@emph{FIXME: This subsection seems to contradict the
@code{defsystem} grammar subsection,
which doesn't provide any obvious way to specify required features.
Furthermore, in 2009, discussions on the asdf-devel mailing list
suggested that the specification of required features may be broken,
and that no one may have been using them for a while.
Please contact the asdf-devel mailing list if you are interested
in getting this features feature fixed.}

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 features using
the same syntax as @code{#+} does, and it will (somehow) be ignored for
certain operations unless the feature conditional is a member of
@code{*features*}.


@subsubsection 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

@lisp
:in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))
              (load-op (load-op "foo")))
@end lisp

This means the following things:
@itemize
@item
before performing compile-op on this component, we must perform
load-op on @var{a} and @var{b}, and compile-op on @var{c},
@item
before performing @code{load-op}, we have to load @var{foo}
@end itemize

The syntax is approximately

@verbatim
(this-op {(other-op required-components)}+)

required-components := component-name
                     | (required-components required-components)

component-name := string
                | (:version string minimum-version-object)
@end verbatim

Side note:

This is on a par with what ACL defsystem does.
mk-defsystem is less general: it has an implied dependency

@verbatim
  for all x, (load x) depends on (compile x)
@end verbatim

and using a @code{:depends-on} argument to say that @var{b} depends on
@var{a} @emph{actually} means that

@verbatim
  (compile b) depends on (load a)
@end verbatim

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 @code{(component-depends-on operation component)},
which returns a list

@lisp
((load-op "a") (load-op "b") (compile-op "c") ...)
@end lisp

@code{component-depends-on} can be subclassed for more specific
component/operation types: these need to @code{(call-next-method)}
and append the answer to their dependency, unless
they have a good reason for completely overriding the default dependencies.
Robert P. Goldman's avatar
Robert P. Goldman committed
If it weren't for CLISP, we'd be using @code{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.
@c Doesn't CLISP now support LIST method combination?
This attribute is optional and if absent (which is the usual case),
the component name will be used.
@xref{The defsystem grammar,,Pathname specifiers}, for an explanation of how this attribute
Note that the @code{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, @xref{Defining systems with defsystem}.
The answer to the frequently asked question
``how do I create a system definition
where all the source files have a @file{.cl} extension''
is thus

@lisp
(defmethod source-file-type ((c cl-source-file) (s (eql (find-system 'my-sys))))
@end lisp

@subsubsection 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.

@code{(component-property component property-name)} and
associated @code{setf} method will allow
the programmatic update of this information.
Property names are compared as if by @code{EQL},
so use symbols or keywords or something.
* Pre-defined subclasses of component::
* Creating new component types::
@end menu

@node Pre-defined subclasses of component, Creating new component types, Common attributes of components, Components
@comment  node-name,  next,  previous,  up
@subsection Pre-defined subclasses of component

@deffn 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 @file{.h} file from @file{.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.
@emph{FIXME: describe these.}
@end deffn

@deffn Component module

A module is a collection of sub-components.

A module component has the following extra initargs:

@itemize
@item
@code{:components} the components contained in this module

@item
@code{:default-component-class}
All children components which don't specify their class explicitly
are inferred to be of this type.
@code{:if-component-dep-fails}
This attribute takes one of the values
@code{:fail}, @code{:try-next}, @code{:ignore},
its default value is @code{:fail}.
The other values can be used for implementing conditional compilation
based on implementation @code{*features*},
for the case where it is not necessary for all files in a module to be
@emph{FIXME: such conditional compilation has been reported
to be broken in 2009.}
@code{: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 @code{: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.

@code{module} may be subclassed to represent components such as
foreign-language linked libraries or archive files.
@end deffn

@deffn Component system

@code{system} is a subclass of @code{module}.

A system is a module with a few extra attributes for documentation
purposes; these are given elsewhere.
@xref{The defsystem grammar}.
Users can create new classes for their systems:
the default @code{defsystem} macro takes a @code{:classs} keyword argument.
@end deffn

@node  Creating new component types,  , Pre-defined subclasses of component, Components
@comment  node-name,  next,  previous,  up
@subsection 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.

@emph{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
@code{cl-source-file}:

@lisp
(defclass unportable-cl-source-file (cl-source-file)
    ())
@end lisp

A hypothetical function @code{system-dependent-dirname}
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}.

@lisp
(defmethod component-pathname ((component unportable-cl-source-file))
  (let ((pathname (call-next-method))
        (name (string-downcase (system-dependent-dirname))))
    (merge-pathnames
     (make-pathname :directory (list :relative name))
     pathname)))
@end lisp

The new component type is used in a @code{defsystem} form in this way:

@lisp
(defsystem :foo
    :components
    ((:file "packages")
     ...
     (:unportable-cl-source-file "threads"
      :depends-on ("packages" ...))
     ...
    )
@end lisp

@node Controlling where ASDF saves compiled files, Error handling, The object model of ASDF, Top
@comment  node-name,  next,  previous,  up
@chapter Controlling where ASDF saves compiled files
@cindex asdf-output-translations
@vindex ASDF_OUTPUT_TRANSLATIONS
Each Common Lisp implementation has its own format
for compiled files (fasls for short).
If you use multiple implementations
(or multiple versions of the same implementation),
you'll soon find your source directories
littered with various `DFSL`s, `FASL`s, `CFSL`s and so on.
Worse yet, some implementations use the same file extension
or change formats from version to version which means that
you'll have to recompile binaries as you switch from one
As of version 1.600, ASDF includes @code{asdf-output-translations}
to mitigate the problem.
@section Configurations
Configurations specify mappings from source locations to binary locations.
  @item
        An application may explicitly initialize the output-translations
     configuration using the Configuration API
     (@pxref{Controlling where ASDF saves compiled files,,Configuration API})
     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.

  @item
        The source registry will be configured from
     the environment variable @code{ASDF_OUTPUT_TRANSLATIONS} if it exists.

  @item
  The source registry will be configured from
     user configuration file
	@file{~/.config/common-lisp/asdf-output-translations.conf}
     if it exists.

  @item
  The source registry will be configured from
     user configuration directory
	@file{~/.config/common-lisp/asdf-output-translations.conf.d/}
     if it exists.

  @item
  The source registry will be configured from
     system configuration file
	@file{/etc/common-lisp/asdf-output-translations.conf}
     if it exists.

  @item
  The source registry will be configured from
     system configuration directory
	@file{/etc/common-lisp/asdf-output-translations.conf.d/}
     if it exists.
@end enumerate
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.

Additionally, some implementation-specific directories
may be automatically added to whatever mappings are specified
in configuration files, no matter if the last one inherits or not.


@section Backward Compatibility

@comment{FIXME -- I think we should provide an easy way to get behavior equivalent to A-B-L and I will propose a technique for doing this.}

We purposefully do NOT provide backward compatibility with earlier versions of
asdf-binary-locations (8 Sept 2009),
common-lisp-controller (7.00) or
cl-launch (2.35),
each of which had similar general capabilities.
Future versions of same packages (if any)
will hopefully use the new ASDF API as defined below.

These previous programs' API was not designed
for easy configuration by the end-user
in an easy way with configuration files,
and their previous API didn't fit the new paradigm.

But this incompatibility won't inconvenience many people.
Indeed, few people use and customize these packages;
these 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 want to use 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),
it may still work if you just make sure you do not configure the new
builtin ASDF-Output-Translations.
But if you configure both ASDF's new builtin and ASDF-Binary-Locations
(or an old common-lisp-controller or cl-launch),
you may experience "interesting" issues, so don't do it.

@section Configuration DSL

Here is the grammar of the SEXP DSL for asdf-output-translations configuration:

@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 :=
    ;; include a configuration file or directory
    (:include PATHNAME-DESIGNATOR) |

    ;; Your configuration expression MUST contain
    ;; exactly one of either of these:
    :inherit-configuration | ; splices contents of inherited configuration
    :ignore-inherited-configuration | ; drop contents of inherited configuration

    ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.35-x86-64/ 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)


DIRECTORY-DESIGNATOR :=
    ABSOLUTE-COMPONENT-DESIGNATOR |
    (ABSOLUTE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...)

ABSOLUTE-COMPONENT-DESIGNATOR :=
    STRING | ;; namestring (directory is assumed, better be absolute or bust, ``/**/*.*'' added)
    PATHNAME | ;; pathname (better be an absolute directory or bust)
    :HOME | ;; designates the user-homedir-pathname ~/
    :USER-CACHE | ;; designates the default location for the user cache
    :SYSTEM-CACHE | ;; designates the default location for the system cache
    :ROOT | ;; the root of the filesystem hierarchy
    :CURRENT-DIRECTORY ;; the current directory

RELATIVE-COMPONENT-DESIGNATOR :=
    STRING | ;; namestring, directory is assumed. If the last component, /**/*.* is added
    PATHNAME | ;; pathname unless last component, directory is assumed.
    :IMPLEMENTATION | ;; a directory based on implementation, e.g. sbcl-1.0.32.30-linux-x86-64
    :IMPLEMENTATION-TYPE | ;; a directory based on lisp-implementation-type only, e.g. sbcl
    :CURRENT-DIRECTORY | ;; all components of the current directory, without the :absolute
    :UID | ;; current UID -- not available on Windows
    :USER ;; current USER name -- NOT IMPLEMENTED(!)
@end verbatim

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 @file{/**/*.*}.
You can specify more fine-grained patterns by using a pathname object,
e.g. @code{#p"some/path/**/foo*/bar-*.fasl"}

You may use @code{#+features} to customize the configuration file.

The second designator of a mapping may be @code{NIL}, indicating that files are not mapped
to anything but themselves (same as if the second designator was the same as the first).

@code{:include} statements cause the search to recurse with the path specifications
from the file specified.

An @code{:inherit-configuration} statement cause the search to recurse with the path
specifications from the next configuration
(see section Configurations_ above).

@itemize
@item :enable-user-cache is the same as @code{(:root :user-cache)}.
@item :disable-cache is the same as @code{(:root :root)}.
@item :user-cache uses the contents of variable @code{asdf::*user-cache*}
which by default is the same as using
@code{(:home ".cache" "common-lisp" :implementation)}.
@item :system-cache uses the contents of variable @code{asdf::*system-cache*}
which by default is the same as using
@code{(:root "var" "cache" "common-lisp" :uid :implementation-type)}
@section Configuration Directories

Configuration directories consist in files each contains
a list of directives without any enclosing @code{(:asdf-output-translations ...)} form.
The files will be sorted by namestring as if by @code{#'string<} and
the lists of directives of these files with be concatenated in order.
An implicit @code{:inherit-configuration} will be included
at the end of the list.

This allows for packaging software that has file granularity
(e.g. Debian's @command{dpkg} or some future version of @command{clbuild})
to easily include configuration information about distributed software.

Directories may be included by specifying a directory pathname
or namestring in an @code{:include} directive, e.g.:
@verbatim
	(:include "/foo/bar/")
@end verbatim

@section Shell-friendly syntax for configuration

When considering environment variable @code{ASDF_OUTPUT_TRANSLATIONS}
ASDF will skip to next configuration if it's an empty string.
It will @code{READ} the string as an SEXP in the DSL
if it begins with a paren @code{(}
and it will be interpreted as a colon-separated list of directories.
Directories should come in pairs, each pair indicating a :map directive.

The magic empty entry indicates the splicing of inherited configuration
rather than one of entry in a mapping pair.


@section 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).

@section 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.


@section Output location API

The specified functions are exported from package ASDF.


@defun initialize-output-translations
   will read the configuration and initialize all internal variables.
@defun clear-output-translations
   undoes any output location configuration
   and clears any cache for the mapping algorithm.
   You might want to call that 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.
@defun ensure-output-translations
   checks whether output translations have been initialized.
   If not, initialize them.
   This function will be called before any attempt to operate on a system.
   If your application wants to override the provided defaults,
   it will have to use the below function process-output-translations.
@defun apply-output-translations PATHNAME
   Applies the configured output location translations to @var{PATHNAME}
   (calls ensure-output-translations for the translations).


@section Credits

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 @email{fare@@tunes.org}

@c @section Default locations
@c @findex output-files-for-system-and-operation

@c The default binary location for each Lisp implementation
@c is a subdirectory of each source directory.
@c To account for different Lisps, Operating Systems, Implementation versions,
@c and so on, ASDF borrows code from SLIME
@c to create reasonable custom directory names.
@c Here are some examples:

@c @itemize
@c @item
@c SBCL, version 1.0 on Mac OS X for intel: @code{sbcl-1.0-darwin-x86}

@c @item
@c Franz Allegro, version 8.0, ANSI Common Lisp: @code{allegro-8.0a-macosx-x86}

@c @item
@c Franz Allegro, version 8.1, Modern (case sensitive) Common Lisp: @code{allegro-8.1m-macosx-x86}
@c @end itemize

@c By default, all output file pathnames will be relocated
@c to some thus-named subdirectory of @file{~/.cache/common-lisp/}.

@c See the document @file{README.asdf-output-translations}
@c for a full specification on how to configure @code{asdf-output-translations}.
@node  Error handling, Miscellaneous additional functionality, Controlling where ASDF saves compiled files, Top
@comment  node-name,  next,  previous,  up
@chapter Error handling
@findex SYSTEM-DEFINITION-ERROR
@findex OPERATION-ERROR

If ASDF detects an incorrect system definition, it will signal a generalised instance of
@code{SYSTEM-DEFINITION-ERROR}.

Operations may go wrong (for example when source files contain errors).
These are signalled using generalised instances of
@code{OPERATION-ERROR}.

@section Compilation error and warning handling
@vindex *compile-file-warnings-behaviour*
@vindex *compile-file-errors-behavior*

ASDF checks for warnings and errors when a file is compiled.
The variables @var{*compile-file-warnings-behaviour*} and
@var{*compile-file-errors-behavior*}
control the handling of any such events.
The valid values for these variables are
@code{:error}, @code{:warn}, and @code{:ignore}.
@node  Miscellaneous additional functionality, Getting the latest version, Error handling, Top
@comment  node-name,  next,  previous,  up
@chapter Miscellaneous additional functionality
Robert P. Goldman's avatar
Robert P. Goldman committed
@emph{FIXME:  Add discussion of @code{run-shell-command}?  Others?}

ASDF includes several additional features that are generally
useful for system definition and development. These include:

@enumerate
@item
@code{system-relative-pathname}
It's often handy to locate a file relative to some system.
The @code{system-relative-pathname} function meets this need.
It takes two arguments: the name of a system and a relative pathname.
It returns a pathname built from the location of the system's source file
and the relative pathname. For example

@lisp
> (asdf:system-relative-pathname 'cl-ppcre "regex.data")
#P"/repository/other/cl-ppcre/regex.data"
@end lisp

@end enumerate


@node Getting the latest version, FAQ, Miscellaneous additional functionality, Top
@comment  node-name,  next,  previous,  up
@chapter Getting the latest version

Decide which version you want.
HEAD is the newest version and usually OK, whereas
RELEASE is for cautious people
(e.g. who already have systems using ASDF that they don't want broken),
a slightly older version about which none of the HEAD users have complained.
There is also a STABLE version, which is earlier than release.
You may get the ASDF source repository using git:
@kbd{git clone http://common-lisp.net/project/asdf/asdf.git}
You will find the above referenced tags in this repository.
Discussion of ASDF development is conducted on the mailing list
@kbd{asdf-devel@@common-lisp.net}.
@node FAQ, TODO list, Getting the latest version, Top
@comment  node-name,  next,  previous,  up
@chapter FAQ


@itemize
@item ``My Common Lisp implementation comes with an outdated version of ASDF. What to do?''

More up-to-date versions of ASDF are distributed with an @file{asdf.asd} file,
and @emph{should} load cleanly on top of older versions.
So you should be able to load this definition file
(or add its pathname to your @code{asdf:*central-registry*} variable),
and then do:
@example
(asdf:oos 'asdf:load-op :asdf)
@end example

If this does not work, it is a bug, and you should report it
(@pxref{FAQ, report-bugs, Where do I report a bug}).


@item ``How can I cater for unit-testing in my system?''

ASDF provides a predefined test operation, @code{test-op}.
@xref{Predefined operations of ASDF, test-op}.
The test operation, however, is largely left to the system definer to specify.
@code{test-op} has been
a topic of considerable discussion on the asdf-devel mailing list, and
on the launchpad bug-tracker.

Here are some guidelines:

@itemize
@item
For a given system, @var{foo}, you will want to define a corresponding
test system, such as @var{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.

@item
The @var{foo-test} system can be defined in an asd file of its own or
together with @var{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 @var{foo-test}.
Typically one would not want to do this except in early stages of
debugging.

@item
Record that testing is implemented by @var{foo-test}.  For example:
@example
(defsystem @var{foo}
   :in-order-to ((test-op (test-op @var{foo-test})))
   ....)

(defsystem @var{foo-test}
   :depends-on (@var{foo} @var{my-test-library} ...)
   ....)
@end example
@end itemize

This procedure will allow you to support users who do not wish to
install your test framework.

One oddity of ASDF is that @code{operate} (@pxref{Operations,operate})
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.

item ``How can I cater for documentation generation in my system?''

The ASDF developers are currently working to add a @code{doc-op} to the
set of predefined ASDF operations (@pxref{Predefined operations of
ASDF}).  See also @url{https://bugs.launchpad.net/asdf/+bug/479470}.

@item ``How can I customize where fasl files are stored?''

@xref{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.

Note that use of asdf-binary-locations can interfere with one aspect of
your systems --- if your system uses @code{*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.

@item ``How can I maintain non-Lisp (e.g. C) source files?''

@anchor{report-bugs}
@item  Where do I report a bug?

ASDF bugs are tracked on launchpad: @url{https://launchpad.net/asdf}.

Robert P. Goldman's avatar
Robert P. Goldman committed
@item ``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 @code{:pathname} argument
to the module description.
For example, here is how it is done
in the spatial-trees ASDF system definition:
Robert P. Goldman's avatar
Robert P. Goldman committed

@example
(asdf:defsystem :spatial-trees
  :components
  ((:module base
Robert P. Goldman's avatar
Robert P. Goldman committed
            :components
            ((:file "package")
             (:file "basedefs" :depends-on ("package"))
             (:file "rectangles" :depends-on ("package"))))
   (:module tree-impls
            :depends-on (base)
Robert P. Goldman's avatar
Robert P. Goldman committed
            :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)