Newer
Older
\input texinfo @c -*- texinfo -*-
@c %**start of header
@setfilename asdf.info
@c We use @&key, etc to escape & from TeX in lambda lists --
@c so we need to define them for info as well.
@macro &allow-other-keys
&allow-other-keys
@end macro
@macro &optional
&optional
@end macro
@macro &rest
&rest
@end macro
@macro &key
&key
@end macro
@macro &body
&body
@end macro
@c for install-info
@dircategory Software development
@direntry
* asdf: (asdf). Another System Definition Facility (for Common Lisp)
@end direntry
This manual describes ASDF, a system definition facility
for Common Lisp programs and libraries.
You can find the latest version of this manual at
@url{http://common-lisp.net/project/asdf/asdf.html}.
ASDF Copyright @copyright{} 2001-2011 Daniel Barlow and contributors.
This manual Copyright @copyright{} 2001-2011 Daniel Barlow and contributors.
This manual revised @copyright{} 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.
@end copying
@titlepage
@title ASDF: Another System Definition Facility
@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
@c Output the table of contents at the beginning.
@contents
@c -------------------
@ifnottex
@node Top, Introduction, (dir), (dir)
@top asdf: another system definition facility
* 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::
* Inspiration::
* Concept Index::
* Function and Class Index::
* Variable Index::
Robert P. Goldman
committed
@c @detailmenu
@c --- The Detailed Node Listing ---
Robert P. Goldman
committed
@c Defining systems with defsystem
Robert P. Goldman
committed
@c * The defsystem form::
@c * A more involved example::
@c * The defsystem grammar::
@c * Other code in .asd files::
Robert P. Goldman
committed
@c The object model of ASDF
Robert P. Goldman
committed
@c * Operations::
@c * Components::
Robert P. Goldman
committed
@c Operations
Robert P. Goldman
committed
@c * Predefined operations of ASDF::
@c * Creating new operations::
Robert P. Goldman
committed
@c Components
Robert P. Goldman
committed
@c * Common attributes of components::
@c * Pre-defined subclasses of component::
@c * Creating new component types::
Robert P. Goldman
committed
@c properties
Robert P. Goldman
committed
@c * Pre-defined subclasses of component::
@c * Creating new component types::
Robert P. Goldman
committed
@c @end detailmenu
@end menu
@end ifnottex
@c -------------------
@node Introduction, Loading ASDF, Top, Top
@comment node-name, next, previous, up
@chapter Introduction
@cindex ASDF-related features
@vindex *features*
@cindex Testing for ASDF
@cindex ASDF versions
@cindex :asdf
@cindex :asdf2
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.
to learn how to use ASDF to load a system.
to learn how to define a system of your own.
@xref{The object model of ASDF}, for a description of
We have released ASDF 2.000 on May 31st 2010.
It hopefully will have been it included
in all CL maintained implementations shortly afterwards.
@xref{FAQ,,``What has changed between ASDF 1 and ASDF 2?''}.
@node Loading ASDF, Configuring ASDF, Introduction, Top
@comment node-name, next, previous, up
@chapter Loading ASDF
@vindex *central-registry*
@findex load-system
@findex compile-system
@findex test-system
@cindex system directory designator
@findex operate
@findex oos
@c * Installing ASDF::
@c @end menu
@section Loading a pre-installed ASDF
Many Lisp implementations include a copy of ASDF.
You can usually load this copy using Common Lisp's @code{require} function:
@lisp
(require :asdf)
@end lisp
As of the writing of this manual,
the following implementations provide ASDF 2 this way:
abcl allegro ccl clisp cmucl ecl sbcl xcl.
The following implementations don't provide it yet but might in a future release:
lispworks scl.
The following implementations are obsolete and most probably will never bundle it:
cormancl gcl genera mcl.
If the implementation you are using doesn't provide ASDF 2,
see @pxref{Loading ASDF,,Loading an otherwise installed 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.
@section Checking whether ASDF is loaded
To check whether ASDF is properly loaded in your current Lisp image,
you can run this form:
@lisp
(asdf:asdf-version)
@end lisp
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:
@lisp
(or #+asdf2 (asdf:asdf-version) #+asdf :old)
@end lisp
If it returns a version number, that's the version of ASDF installed.
If it returns the keyword @code{:OLD},
then you're using an old version of ASDF (from before 1.635).
If it returns @code{NIL} then ASDF is not installed.
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.
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
@section Upgrading ASDF
If your implementation does provide ASDF 2 or later,
and you want to upgrade to a more recent version,
just install ASDF like any other package
(see @pxref{Loading ASDF,,Loading an otherwise installed ASDF} below),
configure ASDF as usual (see @pxref{Configuring ASDF} below),
and upgrade with:
@lisp
(require :asdf)
(asdf:load-system :asdf)
@end lisp
If on the other hand, your implementation only provides an old ASDF,
you will require a special configuration step and an old-style loading:
@lisp
(require :asdf)
(push #p"@var{/path/to/new/asdf/}" asdf:*central-registry*)
(asdf:oos 'asdf:load-op :asdf)
@end lisp
Don't forget the trailing @code{/} at the end of your pathname.
Also, note that older versions of ASDF won't redirect their output,
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, note that there are some limitations to upgrading ASDF:
@itemize
@item
Any ASDF extension is invalidated, and will need to be reloaded.
This applies to e.g. CFFI-Grovel, or to hacks used by ironclad, etc.
@item
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.
@end itemize
@section 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 @file{asdf.lisp}
somewhere and load it with:
@lisp
(load "/path/to/your/installed/asdf.lisp")
@end lisp
The single file @file{asdf.lisp} is all you normally need to use ASDF.
You can extract this file from latest release tarball on the
@url{http://common-lisp.net/project/asdf/,ASDF website}.
If you are daring and willing to report bugs, you can get
the latest and greatest version of ASDF from its git repository.
@xref{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.
@node Configuring ASDF, Using ASDF, Loading ASDF, Top
@comment node-name, next, previous, up
@chapter Configuring ASDF
@section Configuring ASDF to find your systems
So it may compile and load your systems, ASDF must be configured to find
the @file{.asd} files that contain system definitions.
Since ASDF 2, the preferred way to configure where ASDF finds your systems is
the @code{source-registry} facility,
fully described in its own chapter of this manual.
@xref{Controlling where ASDF searches for systems}.
The default location for a user to install Common Lisp software is under
@file{~/.local/share/common-lisp/source/}.
If you install software there, 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,
the authors of that tool should already have configured ASDF.
The simplest way to add a path to your search path,
say @file{/home/luser/.asd-link-farm/}
is to create the directory
@file{~/.config/common-lisp/source-registry.conf.d/}
and there create a file with any name of your choice but the type @file{conf},
for instance @file{42-asd-link-farm.conf}
containing the line:
@kbd{(:directory "/home/luser/.asd-link-farm/")}
If you want all the subdirectories under @file{/home/luser/lisp/}
to be recursively scanned for @file{.asd} files, instead use:
@kbd{(: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 @file{.conf} extension allows you to have disabled files
or editor backups (ending in @file{~}), 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 @file{.} 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:
@lisp
(asdf:clear-source-registry)
@end lisp
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.
@section Configuring ASDF to find your systems -- old style
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
The old way to configure ASDF to find your systems is by
@code{push}ing directory pathnames onto the variable
@code{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 @file{~/.sbclrc}.)
The @code{asdf:*central-registry*} is empty by default in ASDF 2,
but is still supported for compatibility with ASDF 1.
When used, it takes precedence over the above source-registry@footnote{
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*}.
@xref{Defining systems with defsystem}.}.
For instance, if you wanted ASDF to find the @file{.asd} file
@file{/home/me/src/foo/foo.asd} your initialization script
could after it loads ASDF with @code{(require :asdf)}
configure it with:
@lisp
(push "/home/me/src/foo/" asdf:*central-registry*)
@end lisp
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@footnote{
ASDF will indeed call @code{EVAL} on each entry.
It will also skip entries that evaluate to @code{NIL}.
Strings and pathname objects are self-evaluating,
in which case the @code{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 @code{asdf:*central-registry*} is thus a list of
``system directory designators''.
A @dfn{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''.
}
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 @file{.asd} files, and
a common idiom was to have to put
a bunch of @emph{symbolic links} to @file{.asd} files
in a common directory
and push @emph{that} directory (the ``link farm'')
to the
@code{asdf:*central-registry*}
instead of pushing each of the many involved directories
to the @code{asdf:*central-registry*}.
ASDF knows how to follow such @emph{symlinks}
to the actual file location when resolving the paths of system components
(on Windows, you can use Windows shortcuts instead of POSIX symlinks).
For example, if @code{#p"/home/me/cl/systems/"} (note the trailing slash)
is a member of @code{*central-registry*}, you could set up the
system @var{foo} for loading with asdf with the following
commands at the shell:
@example
$ cd /home/me/cl/systems/
$ ln -s ~/src/foo/foo.asd .
@end example
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.
@section Configuring where ASDF stores object files
@findex clear-output-locations
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 @code{asdf-output-translations} facility
was added to ASDF itself, that controls where object files will be stored.
Francois-Rene Rideau
committed
This facility is fully described in a chapter of this manual,
@ref{Controlling where ASDF saves compiled files}.
The simplest way to add a translation to your search path,
say from @file{/foo/bar/baz/quux/}
to @file{/where/i/want/my/fasls/}
is to create the directory
@file{~/.config/common-lisp/asdf-output-translations.conf.d/}
and there create a file with any name of your choice and the type @file{conf},
for instance @file{42-bazquux.conf}
containing the line:
@kbd{("/foo/bar/baz/quux/" "/where/i/want/my/fasls/")}
To disable output translations for source under a given directory,
say @file{/toto/tata/}
you can create a file @file{40-disable-toto.conf}
with the line:
@kbd{("/toto/tata/")}
To wholly disable output translations for all directories,
you can create a file @file{00-disable.conf}
with the line:
Francois-Rene Rideau
committed
@kbd{(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 @file{~/.cache/common-lisp/}.
@xref{Controlling where ASDF searches for systems}, for full details.
Francois-Rene Rideau
committed
The required @file{.conf} extension allows you to have disabled files
or editor backups (ending in @file{~}), 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 @file{.} 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.
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.
Francois-Rene Rideau
committed
cl-launch 3.000 and common-lisp-controller 7.2 have been updated
to just delegate this functionality to ASDF.
@node Using ASDF, Defining systems with defsystem, Configuring ASDF, Top
@comment node-name, next, previous, up
@chapter Using ASDF
@section Loading a system
The system @var{foo} is loaded (and compiled, if necessary)
by evaluating the following Lisp form:
(asdf:load-system :@var{foo})
On some implementations (namely recent versions of
ABCL, Clozure CL, CLISP, CMUCL, ECL, SBCL and SCL),
ASDF hooks into the @code{CL:REQUIRE} facility
and you can just use:
@example
(require :@var{foo})
@end example
In older versions of ASDF, you needed to use
@code{(asdf:oos 'asdf:load-op :@var{foo})}.
If your ASDF is too old to provide @code{asdf:load-system} though
we recommend that you upgrade to ASDF 2.
@xref{Loading ASDF,,Loading an otherwise installed 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 @code{:name} initarg
to @code{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 @code{:case :common},
which is reported not to work on some implementations
@section Other Operations
ASDF provides three commands for the most common system operations:
@code{load-system}, @code{compile-system} or @code{test-system}.
Because ASDF is an extensible system
for defining @emph{operations} on @emph{components},
it also provides a generic function @code{operate}
(which is usually abbreviated by @code{oos}).
You'll use @code{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 @code{*standard-output*},
and so rebinding that stream around calls to @code{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.
@xref{Configuring ASDF,,Configuring ASDF to find your systems}.
@section Summary
To use ASDF:
@itemize
Load ASDF itself into your Lisp image, either through
@code{(require :asdf)} or else through
@code{(load "/path/to/asdf.lisp")}.
Make sure ASDF can find system definitions
thanks to proper source-registry configuration.
Load a system with @code{(load-system :my-system)}
or use some other operation on some system of your choice.
@end itemize
@section 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.
@node Defining systems with defsystem, The object model of ASDF, Using ASDF, Top
@comment node-name, next, previous, up
@chapter 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::
@end menu
@node The defsystem form, A more involved example, Defining systems with defsystem, Defining systems with defsystem
@comment node-name, next, previous, up
@section The defsystem form
Systems can be constructed programmatically
by instantiating components using @code{make-instance}.
Most of the time, however, it is much more practical to use
a static @code{defsystem} form.
This section begins with an example of a system definition,
then gives the full grammar of @code{defsystem}.
Let's look at a simple system.
This is a complete file that would
usually be saved as @file{hello-lisp.asd}:
(in-package :asdf)
:description "hello-lisp: a sample Lisp system."
:version "0.2.1"
:author "Joe User <joe@@example.com>"
:licence "Public Domain"
:components ((:file "packages")
(:file "macros" :depends-on ("packages"))
(:file "hello" :depends-on ("macros"))))
@end lisp
Some notes about this example:
@itemize
The file starts with an @code{in-package} form
to use package @code{asdf}.
You could instead start your definition by using
a qualified name @code{asdf:defsystem}.
If in addition to simply using @code{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 @code{(in-package :asdf)} with:
@lisp
(defpackage :foo-system
(:use :cl :asdf))
(in-package :foo-system)
@end lisp
The @code{defsystem} form defines a system named @code{hello-lisp}
that contains three source files:
@file{packages}, @file{macros} and @file{hello}.
@item
The file @file{macros} depends on @file{packages}
(presumably because the package it's in is defined in @file{packages}),
and the file @file{hello} depends on @file{macros}
(and hence, transitively on @file{packages}).
This means that ASDF will compile and load @file{packages} and @file{macros}
before starting the compilation of file @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@footnote{
It is possible, though almost never necessary, to override this behaviour.}.
This is a good thing because the user can move the system sources
without having to edit the system definition.
@c FIXME: Should have cross-reference to "Version specifiers" in the
@c defsystem grammar, but the cross-referencing is so broken by
@c insufficient node breakdown that I have not put one in.
@item
Make sure you know how the @code{:version} numbers will be parsed! They
are parsed as period-separated lists of integers. I.e., in the example,
@code{0.2.1} is to be interpreted, roughly speaking, as @code{(0 2 1)}.
In particular, version @code{0.2.1} is interpreted the same as
@code{0.0002.1} and is strictly version-less-than version @code{0.20.1},
even though the two are the same when interpreted as decimal fractions.
@cindex version specifiers
@cindex :version
@end itemize
@node A more involved example, The defsystem grammar, The defsystem form, Defining systems with defsystem
@comment node-name, next, previous, up
@section A more involved example
Let's illustrate some more involved uses of @code{defsystem} via a
slightly convoluted example:
@lisp
(defsystem "foo"
:version "1.0.0"
Robert P. Goldman
committed
: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")))
Robert P. Goldman
committed
The @code{:module} component named @code{"mod"} is a collection of three files,
which will be located in a subdirectory of the main code directory named
@file{mod} (this location can be overridden; see the discussion of the
@code{:pathname} option in @ref{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))
@end lisp
has the effect of
@lisp
(defmethod perform :after ((op compile-op) (c (eql ...)))
(defmethod explain :after ((op compile-op) (c (eql ...)))
(explain-something c))
Robert P. Goldman
committed
where @code{...} is the component in question.
In this case @code{...} would expand to something like
Robert P. Goldman
committed
@lisp
(find-component (find-system "foo") "mod")
@end lisp
For more details on the syntax of such forms, see @ref{The defsystem
grammar}.
For more details on what these methods do, @pxref{Operations} in
@ref{The object model of ASDF}.
@c The following plunge into the weeds is not appropriate in this
@c location. [2010/10/03:rpg]
@c note that although this also supports @code{:before} methods,
@c they may not do what you want them to ---
@c a @code{:before} method on perform @code{((op compile-op) (c (eql ...)))}
@c will run after all the dependencies and sub-components have been processed,
@c but before the component in question has been compiled.
@node The defsystem grammar, Other code in .asd files, A more involved example, Defining systems with defsystem
@comment node-name, next, previous, up
@section The defsystem grammar
@c FIXME: @var typesetting not consistently used here. We should either expand
@c its use to everywhere, or we should kill it everywhere.
system-definition := ( defsystem system-designator @var{system-option}* )
system-option := :defsystem-depends-on system-list
| module-option
| option
module-option := :components component-list
| :serial [ t | nil ]
| :if-component-dep-fails component-dep-fail-option
Robert P. Goldman
committed
| :pathname pathname-specifier
| :default-component-class class-name
| :output-files method-form
| :operation-done-p method-form
| :depends-on ( @var{dependency-def}* )
| :in-order-to ( @var{dependency}+ )
system-list := ( @var{simple-component-name}* )
component-list := ( @var{component-def}* )
component-def := ( component-type simple-component-name @var{option}* )
component-type := :system | :module | :file | :static-file | other-component-type
other-component-type := symbol-by-name (@pxref{The defsystem grammar,,Component types})
dependency-def := simple-component-name
| ( :feature name )
| ( :version simple-component-name version-specifier)
dependency := (dependent-op @var{requirement}+)
requirement := (required-op @var{required-component}+)
| (feature feature-name)
dependent-op := operation-name
required-op := operation-name | feature
simple-component-name := string
| symbol
Robert P. Goldman
committed
pathname-specifier := pathname | string | symbol
method-form := (operation-name qual lambda-list @&rest body)
component-dep-fail-option := :fail | :try-next | :ignore
Robert P. Goldman
committed
@subsection Component names
Component names (@code{simple-component-name})
may be either strings or symbols.
Robert P. Goldman
committed
Francois-Rene Rideau
committed
@subsection 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 @code{my-component-type}, in
the current package @code{my-system-asd} can be specified as
@code{:my-component-type}, or @code{my-component-type}.
@subsection Defsystem depends on
The @code{:defsystem-depends-on} option to @code{defsystem} allows the
programmer to specify another ASDF-defined system or set of systems that
must be loaded @emph{before} the system definition is processed.
Typically this is used to load an ASDF extension that is used in the
system definition.
Robert P. Goldman
committed
@subsection Pathname specifiers
Robert P. Goldman
committed
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
A pathname specifier (@code{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 @code{/} characters will be interpreted as directory separators.
Usually, Unix-style relative pathnames are used
(i.e. not starting with @code{/}, as opposed to absolute pathnames);
they are relative to the path of the parent component.
Finally, depending on the @code{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 @code{component-type},
or else it will be extracted from the string itself (if applicable).
For instance, the @code{component-type} @code{:module}
wants a directory pathname, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar/"}.
On the other hand, the @code{component-type} @code{:file}
wants a file of type @code{lisp}, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar.lisp"},
and a string @code{"foo/bar.quux"}
will be interpreted as the pathname @file{#p"foo/bar.quux.lisp"}.
Finally, the @code{component-type} @code{:static-file}
wants a file without specifying a type, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar"},
and a string @code{"foo/bar.quux"}
will be interpreted as the pathname @file{#p"foo/bar.quux"}.
Robert P. Goldman
committed
ASDF does not interpret the string @code{".."} to designate the parent
directory. This string will be passed through to the underlying
operating system for interpretation. We @emph{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
@code{:up} or @code{: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 @code{:case :common}
as argument to @code{make-pathname},
which is reported not to work on some implementations.
Robert P. Goldman
committed
Pathname objects may be given to override the path for a component.
Such objects are typically specified using reader macros such as @code{#p}
or @code{#.(make-pathname ...)}.
Robert P. Goldman
committed
Note however, that @code{#p...} is a shorthand for @code{#.(parse-namestring ...)}
and that the behavior of @code{parse-namestring} is completely non-portable,
unless you are using Common Lisp @code{logical-pathname}s
(@pxref{The defsystem grammar,,Warning about logical pathnames}, below).
Pathnames made with @code{#.(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.
Robert P. Goldman
committed
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 ...)} syntax had to be used.
Robert P. Goldman
committed
Robert P. Goldman
committed
ASDF does not do any special interpretation of the pathname
influenced by the component type, unlike the procedure for
pathname-specifying strings.
Francois-Rene Rideau
committed
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.
Robert P. Goldman
committed
@subsection Version specifiers
@cindex version specifiers
@cindex :version
Version specifiers are parsed as period-separated lists of integers. I.e., in the example,
@code{0.2.1} is to be interpreted, roughly speaking, as @code{(0 2 1)}.
In particular, version @code{0.2.1} is interpreted the same as
@code{0.0002.1} and is strictly version-less-than version @code{0.20.1},
even though the two are the same when interpreted as decimal fractions.
System definers are encouraged to use version identifiers of the form
@var{x}.@var{y}.@var{z} for major version, minor version (compatible
API) and patch level.
@xref{Common attributes of components}.
Robert P. Goldman
committed
@subsection Warning about logical pathnames