@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
+@macro AallowOtherKeys
&allow-other-keys
@end macro
-@macro &optional
+@macro Aoptional
&optional
@end macro
-@macro &rest
+@macro Arest
&rest
@end macro
-@macro &key
+@macro Akey
&key
@end macro
-@macro &body
+@macro Abody
&body
@end macro
You can find the latest version of this manual at
@url{http://common-lisp.net/project/asdf/asdf.html}.
-ASDF Copyright @copyright{} 2001-2010 Daniel Barlow and contributors.
+ASDF Copyright @copyright{} 2001-2013 Daniel Barlow and contributors.
-This manual Copyright @copyright{} 2001-2010 Daniel Barlow and contributors.
+This manual Copyright @copyright{} 2001-2013 Daniel Barlow and contributors.
-This manual revised @copyright{} 2009-2010 Robert P. Goldman and Francois-Rene Rideau.
+This manual revised @copyright{} 2009-2013 Robert P. Goldman and Francois-Rene Rideau.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
@titlepage
-@title asdf: another system definition facility
+@title ASDF: Another System Definition Facility
@c The following two commands start the copyright page.
@page
@c * Operations::
@c * Components::
+@c * Functions::
@c Operations
@cindex ASDF versions
@cindex :asdf
@cindex :asdf2
+@cindex :asdf3
ASDF is Another System Definition Facility:
a tool for specifying how systems of Common Lisp software
the ASDF internals and how to extend ASDF.
@emph{Nota Bene}:
-We have released ASDF 2.000 on May 31st 2010.
-It hopefully will have been it included
-in all CL maintained implementations shortly afterwards.
+We have released ASDF 2.000 on May 31st 2010,
+and ASDF 3.0 on January 31st 2013.
+Releases of ASDF 2 and later have since then been included
+in all actively maintained CL implementations that used to bundle ASDF 1,
+plus some implementations that didn't use to,
+and has been made to work with all actively used CL implementations and a few more.
@xref{FAQ,,``What has changed between ASDF 1 and ASDF 2?''}.
+Furthermore, it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly.
+For this reason, we have stopped supporting ASDF 1 and ASDF 2.
+If you are using ASDF 1 or ASDF 2 and are experiencing any kind of issues or limitations,
+we recommend you upgrade to ASDF 3
+--- and we explain how to do that. @xref{Loading ASDF}.
+
+Also note that ASDF is not to be confused with ASDF-Install.
+ASDF-Install is not part of ASDF, but a separate piece of software.
+ASDF-Install is also unmaintained and obsolete.
+We recommend you use Quicklisp instead,
+which works great and is being actively maintained.
+If you want to download software from version control instead of tarballs,
+so you may more easily modify it, we recommend clbuild.
@node Loading ASDF, Configuring ASDF, Introduction, Top
@vindex *central-registry*
@cindex link farm
@findex load-system
+@findex require-system
@findex compile-system
@findex test-system
@cindex system directory designator
@section Loading a pre-installed ASDF
-Many Lisp implementations include a copy of ASDF.
+Most recent Lisp implementations include a copy of ASDF 2, and soon ASDF 3.
You can usually load this copy using Common Lisp's @code{require} function:
@lisp
-(require :asdf)
+(require "asdf")
@end lisp
-Consult your Lisp implementation's documentation for details.
+As of the writing of this manual,
+the following implementations provide ASDF 2 this way:
+abcl allegro ccl clisp cmucl ecl lispworks mkcl sbcl xcl.
+The following implementation doesn't provide it yet but will in an upcoming release:
+scl.
+The following implementations are obsolete, not actively maintained,
+and most probably will never bundle it:
+cormanlisp gcl genera mcl.
+
+If the implementation you are using doesn't provide ASDF 2 or ASDF 3,
+see @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.
-Hopefully, ASDF 2 will soon be bundled with every Common Lisp implementation,
-and you can load it that way.
+NB: all implementations except clisp also accept
+@code{(require "ASDF")}, @code{(require 'asdf)} and @code{(require :asdf)}.
+For portability's sake, you probably want to use @code{(require "asdf")}.
@section Checking whether ASDF is loaded
or none at all:
@lisp
-(or #+asdf2 (asdf:asdf-version) #+asdf :old)
+(when (find-package :asdf)
+ (let ((ver (symbol-value (or (find-symbol (string :*asdf-version*) :asdf)
+ (find-symbol (string :*asdf-revision*) :asdf)))))
+ (etypecase ver
+ (string ver)
+ (cons (with-output-to-string (s)
+ (loop for (n . m) on ver do (princ n s) (when m (princ "." s)))))
+ (null "1.0"))))
@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.
+Otherwise it should return a string.
+If it returns @code{"1.0"}, then it can actually be
+any version before 1.77 or so, or some buggy variant of 1.x.
-If you are running a version older than 2.000,
-we recommend that you load a newer ASDF using the method below.
+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.
@section Upgrading ASDF
+If your implementation provides ASDF 3 or later,
+you only need to @code{(require "asdf")}:
+ASDF will automatically look whether an updated version of itself is available
+amongst the regularly configured systems, before it compiles anything else.
+See @pxref{Configuring ASDF} below.
+
If your implementation does provide ASDF 2 or later,
+but not ASDF 3 or later,
and you want to upgrade to a more recent version,
-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:
+you need to install and configure your ASDF as above,
+and additionally, you need to explicitly tell ASDF to load itself,
+right after you require your implementation's old ASDF 2:
@lisp
-(require :asdf)
+(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:
+you will require a special configuration step and an old-style loading.
+Take special attention to not omit the trailing directory separator
+@code{/} at the end of your pathname:
@lisp
-(require :asdf)
+(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,
+Note that ASDF 1 won't redirect its output files,
or at least won't do it according to your usual ASDF 2 configuration.
You therefore need write access on the directory
where you install the new ASDF,
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:
+Finally, if you are using an unmaintained implementation
+that does not provide ASDF at all,
+see @pxref{Loading ASDF,,Loading an otherwise installed ASDF} below.
+
+Note that there are some limitations to upgrading ASDF:
@itemize
@item
-Any ASDF extension is invalidated, and will need to be reloaded.
+Previously loaded ASDF extension becomes invalid, and will need to be reloaded.
+This applies to e.g. CFFI-Grovel, or to hacks used by ironclad, etc.
+Since it isn't possible to automatically detect what extensions are present
+that need to be invalidated,
+ASDF will actually invalidate all previously loaded systems
+when it is loaded on top of a different ASDF version,
+starting with ASDF 2.014.8 (as far as releases go, 2.015);
+and it will automatically attempt this self-upgrade as its very first step
+starting with ASDF 3.
+
@item
-It is safer if you upgrade ASDF and its extensions as a special step
+For this an many other reasons,
+it important reason to load, configure and upgrade ASDF (if needed)
+as one of the very first things done by your build and startup scripts.
+Until all implementations provide ASDF 3 or later,
+it is safer if you upgrade ASDF and its extensions as a special step
at the very beginning of whatever script you are running,
-before you start using ASDF to load anything else.
+before you start using ASDF to load anything else;
+even afterwards, it is still a good idea, to avoid having to
+load and reload code twice as it gets invalidated.
+
+@item
+Until all implementations provide ASDF 3 or later,
+it is unsafe to upgrade ASDF as part of loading a system
+that depends on a more recent version of ASDF,
+since the new one might shadow the old one while the old one is running,
+and the running old one will be confused
+when extensions are loaded into the new one.
+In the meantime, we recommend that your systems should @emph{not} specify
+@code{:depends-on (:asdf)}, or @code{:depends-on ((:version :asdf "2.010"))},
+but instead that they check that a recent enough ASDF is installed,
+with such code as:
+@example
+(unless (or #+asdf2 (asdf:version-satisfies
+ (asdf:asdf-version) *required-asdf-version*))
+ (error "FOO requires ASDF ~A or later." *required-asdf-version*))
+@end example
+@item
+Until all implementations provide ASDF 3 or later,
+it is unsafe for a system to transitively depend on ASDF
+and not directly depend on ASDF;
+if any of the system you use either depends-on asdf,
+system-depends-on asdf, or transitively does,
+you should also do as well.
@end itemize
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 install software there (it can be a symlink),
+you don't need further configuration.
If you're installing software yourself at a location that isn't standard,
you have to tell ASDF where you installed it. See below.
-If you're using some tool to install software,
+If you're using some tool to install software (e.g. Quicklisp),
the authors of that tool should already have configured ASDF.
The simplest way to add a path to your search path,
say @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},
+and there create a file with any name of your choice,
+and with the type @file{conf},
for instance @file{42-asd-link-farm.conf}
containing the line:
if the configuration may change
between the machine where you save it at the time you save it
and the machine you resume it at the time you resume it.
+Actually, you should use @code{(asdf:clear-configuration)}
+before you dump your Lisp image, which includes the above.
-@section Configuring ASDF to find your systems -- old style
+@section Configuring ASDF to find your systems --- old style
The old way to configure ASDF to find your systems is by
@code{push}ing directory pathnames onto the variable
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,
+The @code{asdf:*central-registry*} is empty by default in ASDF 2 or ASDF 3,
but is still supported for compatibility with ASDF 1.
When used, it takes precedence over the above source-registry@footnote{
It is possible to further customize
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)}
+could after it loads ASDF with @code{(require "asdf")}
configure it with:
@lisp
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).
+(on Windows, you can use Windows shortcuts instead of POSIX symlinks;
+if you try aliases under MacOS, we are curious to hear about your experience).
For example, if @code{#p"/home/me/cl/systems/"} (note the trailing slash)
is a member of @code{*central-registry*}, you could set up the
@section Configuring where ASDF stores object files
-@findex clear-output-locations
+@findex clear-output-translations
ASDF lets you configure where object files will be stored.
Sensible defaults are provided and
if the configuration may change
between the machine where you save it at the time you save it
and the machine you resume it at the time you resume it.
+(Once again, you should use @code{(asdf:clear-configuration)}
+before you dump your Lisp image, which includes the above.)
Finally note that before ASDF 2,
other ASDF add-ons offered the same functionality,
@node Using ASDF, Defining systems with defsystem, Configuring ASDF, Top
@comment node-name, next, previous, up
+
+@section Resetting Configuration
+
+When you dump and restore an image, or when you tweak your configuration,
+you may want to reset the ASDF configuration.
+For that you may use the following function:
+
+@defun clear-configuration
+ undoes any ASDF configuration,
+ regarding source-registry or output-translations.
+@end defun
+
+If you use SBCL, CMUCL or SCL, you may use this snippet
+so that the ASDF configuration be cleared automatically as you dump an image:
+
+@example
+#+(or cmu sbcl scl)
+(pushnew 'clear-configuration
+ #+(or cmu scl) ext:*before-save-initializations*
+ #+sbcl sb-ext:*save-hooks*)
+@end example
+
+For compatibility with all Lisp implementations, however,
+you might want instead your build script to explicitly call
+@code{(asdf:clear-configuration)} at an appropriate moment before dumping.
+
+
@chapter Using ASDF
@section Loading a system
(asdf:load-system :@var{foo})
@end example
-On some implementations (namely ABCL, Clozure CL, CMUCL, ECL and SBCL),
+On some implementations (namely recent versions of
+ABCL, Allegro CL, Clozure CL, CMUCL, ECL, GNU CLISP,
+LispWorks, MKCL, SBCL and XCL),
ASDF hooks into the @code{CL:REQUIRE} facility
and you can just use:
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.
+we recommend that you upgrade to ASDF 3.
@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}.
+It also provides @code{require-system}, a version of @code{load-system}
+that skips trying to update systems that are already loaded.
Because ASDF is an extensible system
for defining @emph{operations} on @emph{components},
it must be able to find and load that system's definition.
@xref{Configuring ASDF,,Configuring ASDF to find your systems}.
+For the advanced users, note that
+@code{require-system} calls @code{load-system}
+with keyword arguments @code{:force-not (loaded-systems)}.
+@code{loaded-systems} returns a list of the names of loaded systems.
+@code{load-system} applies @code{operate} with the operation from
+@code{*load-system-operation*}, which by default is @code{load-op},
+the system, and any provided keyword arguments.
@section Summary
@itemize
@item
Load ASDF itself into your Lisp image, either through
-@code{(require :asdf)} or else through
+@code{(require "asdf")} or else through
@code{(load "/path/to/asdf.lisp")}.
@item
thanks to proper source-registry configuration.
@item
-Load a system with @code{(load-system :my-system)}
+Load a system with @code{(asdf:load-system :my-system)}
or use some other operation on some system of your choice.
@end itemize
(defsystem "hello-lisp"
:description "hello-lisp: a sample Lisp system."
- :version "0.2"
+ :version "0.2.1"
:author "Joe User <joe@@example.com>"
:licence "Public Domain"
:components ((:file "packages")
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.
+Instead of a string representing the version,
+the @code{:version} argument can be an expression that is resolved to
+such a string using the following trivial domain-specific language:
+in addition to being a literal string, it can be an expression of the form
+@code{(:read-file-form <pathname-or-string> :at <access-at-specifier>)},
+which will be resolved by reading a form in the specified pathname
+(read as a subpathname of the current system if relative or a unix-namestring).
+You may use a @code{uiop:access-at} specifier
+with the (optional) @code{:at} keyword,
+by default the specifier is @code{0}, meaning the first form is returned.
+
+@cindex :version
+
@end itemize
@node A more involved example, The defsystem grammar, The defsystem form, Defining systems with defsystem
@lisp
(defsystem "foo"
- :version "1.0"
- :components ((:module "foo" :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")))
+ :version "1.0.0"
+ :components ((:module "mod"
+ :components ((:file "bar")
+ (:file"baz")
+ (:file "quux"))
+ :perform (compile-op :after (op c)
+ (do-something c))
+ :explain (compile-op :after (op c)
+ (explain-something c)))
+ (:file "blah")))
@end lisp
-The method-form tokens need explaining: essentially, this part:
+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
@lisp
:perform (compile-op :after (op c)
(explain-something c))
@end lisp
-where @code{...} is the component in question;
-note that although this also supports @code{:before} methods,
-they may not do what you want them to ---
-a @code{:before} method on perform @code{((op compile-op) (c (eql ...)))}
-will run after all the dependencies and sub-components have been processed,
-but before the component in question has been compiled.
+where @code{...} is the component in question.
+In this case @code{...} would expand to something like
+
+@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.
+
+
@example
-system-definition := ( defsystem system-designator @var{option}* )
+system-definition := ( defsystem system-designator @var{system-option}* )
-option := :components component-list
+system-option := :defsystem-depends-on system-list
+ | :weakly-depends-on @var{system-list}
+ | :class class-name (see discussion below)
+ | module-option
+ | option
+
+module-option := :components component-list
+ | :serial [ t | nil ]
+
+option :=
| :pathname pathname-specifier
- | :default-component-class
+ | :default-component-class class-name
| :perform method-form
| :explain method-form
| :output-files method-form
| :operation-done-p method-form
+ | :if-feature feature-expression
| :depends-on ( @var{dependency-def}* )
- | :serial [ t | nil ]
| :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
+component-type := :module | :file | :static-file | other-component-type
other-component-type := symbol-by-name (@pxref{The defsystem grammar,,Component types})
pathname-specifier := pathname | string | symbol
-method-form := (operation-name qual lambda-list @&rest body)
+method-form := (operation-name qual lambda-list @Arest body)
qual := method qualifier
+
+component-dep-fail-option := :fail | :try-next | :ignore
+
+feature-expression := keyword | (:and @var{feature-expression}*)
+ | (:or @var{feature-expression}*) | (:not @var{feature-expression})
@end example
+
@subsection Component names
Component names (@code{simple-component-name})
the current package @code{my-system-asd} can be specified as
@code{:my-component-type}, or @code{my-component-type}.
+@code{system} and its subclasses are @emph{not}
+allowed as component types for such children components.
+
+@subsection System class names
+
+A system class name will be looked up
+in the same way as a Component type (see above),
+except that only @code{system} and its subclasses are allowed.
+Typically, one will not need to specify a system
+class name, unless using a non-standard system class defined in some
+ASDF extension, typically loaded through @code{DEFSYSTEM-DEPENDS-ON},
+see below. For such class names in the ASDF package, we recommend that
+the @code{:class} option be specified using a keyword symbol, such as
+
+@example
+:class :MY-NEW-SYSTEM-SUBCLASS
+@end example
+
+This practice will ensure that package name conflicts are avoided.
+Otherwise, the symbol @code{MY-NEW-SYSTEM-SUBCLASS} will be read into
+the current package @emph{before} it has been exported from the ASDF
+extension loaded by @code{:defsystem-depends-on}, causing a name
+conflict in the current package.
+
+@subsection Defsystem depends on
+@cindex :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.
+
+@subsection Weakly depends on
+@cindex :weakly-depends-on
+
+We do @emph{NOT} recommend you use this feature.
+If you are tempted to write a system @var{foo}
+that weakly-depends-on a system @var{bar},
+we recommend that you should instead
+write system @var{foo} in a parametric way,
+and offer some special variable and/or some hook to specialize its behavior;
+then you should write a system @var{foo+bar}
+that does the hooking of things together.
+
+The (deprecated) @code{:weakly-depends-on} option to @code{defsystem}
+allows the programmer to specify another ASDF-defined system or set of systems
+that ASDF should @emph{try} to load,
+but need not load in order to be successful.
+Typically this is used if there are a number of systems
+that, if present, could provide additional functionality,
+but which are not necessary for basic function.
+
+Currently, although it is specified to be an option only to @code{defsystem},
+this option is accepted at any component, but it probably
+only makes sense at the @code{defsystem} level.
+Programmers are cautioned not
+to use this component option except at the @code{defsystem} level, as
+this anomalous behavior may be removed without warning.
+
+Finally, you might look into the @code{asdf-system-connections} extension,
+that will let you define additional code to be loaded
+when two systems are simultaneously loaded.
+It may or may not be considered good style, but at least it can be used
+in a way that has deterministic behavior independent of load order,
+unlike @code{weakly-depends-on}.
+
+
@subsection Pathname specifiers
@cindex pathname specifiers
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).
+(@pxref{The defsystem grammar,,Using 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
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.
+An alternative to @code{#.} read-time evaluation is to use
+@code{(eval `(defsystem ... ,pathname ...))}.
-Note that when specifying pathname objects,
+Note that when specifying pathname objects,
ASDF does not do any special interpretation of the pathname
influenced by the component type, unlike the procedure for
pathname-specifying strings.
on the other hand, you can circumvent the file type that would otherwise
be forced upon you if you were specifying a string.
+@subsection Version specifiers
+@cindex version specifiers
+@cindex :version
-@subsection Warning about logical pathnames
-@cindex logical pathnames
+Version specifiers are strings to be 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"},
+though the latter is not canonical and may lead to a warning being issued.
+Also, @code{"1.3"} and @code{"1.4"} are both strictly @code{uiop:version<} to @code{"1.30"},
+quite unlike what would have happened
+had the version strings been interpreted as decimal fractions.
-We recommend that you not use logical pathnames
-in your asdf system definitions at this point,
-but logical pathnames @emph{are} supported.
+System definers are encouraged to use version identifiers of the form
+@var{x}.@var{y}.@var{z} for
+major version, minor version and patch level,
+where significant API incompatibilities are signaled by an increased major number.
+
+@xref{Common attributes of components}.
+
+
+@subsection Using logical pathnames
+@cindex logical pathnames
+
+We do not generally recommend the use of logical pathnames,
+especially not so to newcomers to Common Lisp.
+However, we do support the use of logical pathnames by old timers,
+when such is their preference.
To use logical pathnames,
you will have to provide a pathname object as a @code{:pathname} specifier
to components that use it, using such syntax as
@code{#p"LOGICAL-HOST:absolute;path;to;component.lisp"}.
-You only have to specify such logical pathname for your system or
-some top-level component. Sub-components' relative pathnames, specified
-using the string syntax
-for names, will be properly merged with the pathnames of their parents.
+You only have to specify such logical pathname
+for your system or some top-level component.
+Sub-components' relative pathnames,
+specified using the string syntax for names,
+will be properly merged with the pathnames of their parents.
The specification of a logical pathname host however is @emph{not}
otherwise directly supported in the ASDF syntax
for pathname specifiers as strings.
The @code{asdf-output-translation} layer will
-avoid trying to resolve and translate logical-pathnames.
-The advantage of this is that you can define yourself what translations you want to use
+avoid trying to resolve and translate logical pathnames.
+The advantage of this is that
+you can define yourself what translations you want to use
with the logical pathname facility.
-The disadvantage is that if you do not define such translations, any
-system that uses logical pathnames will be have differently under
+The disadvantage is that if you do not define such translations,
+any system that uses logical pathnames will behave differently under
asdf-output-translations than other systems you use.
If you wish to use logical pathnames you will have to configure the
ASDF currently provides no specific support
for defining logical pathname translations.
+Note that the reasons we do not recommend logical pathnames are that
+(1) there is no portable way to set up logical pathnames before they are used,
+(2) logical pathnames are limited to only portably use
+a single character case, digits and hyphens.
+While you can solve the first issue on your own,
+describing how to do it on each of fifteen implementations supported by ASDF
+is more than we can document.
+As for the second issue, mind that the limitation is notably enforced on SBCL,
+and that you therefore can't portably violate the limitations
+but must instead define some encoding of your own and add individual mappings
+to name physical pathnames that do not fit the restrictions.
+This can notably be a problem when your Lisp files are part of a larger project
+in which it is common to name files or directories in a way that
+includes the version numbers of supported protocols,
+or in which files are shared with software written
+in different programming languages where conventions include the use of
+underscores, dots or CamelCase in pathnames.
+
@subsection Serial dependencies
@cindex serial dependencies
If the @code{:serial t} option is specified for a module,
-ASDF will add dependencies for each each child component,
+ASDF will add dependencies for each child component,
on all the children textually preceding it.
This is done as if by @code{:depends-on}.
@code{find-system}
will load a system from disk
and have its pathname default to the right place.
+
@item
This pathname information will not be overwritten with
@code{*default-pathname-defaults*}
@item
changed, if explicitly supplied or obtained from @code{*load-truename*}
(so that an updated source location is reflected in the system definition)
+
@item
changed if it had previously been set from @code{*default-pathname-defaults*}
+
@item
left as before, if it had previously been set from @code{*load-truename*}
and @code{*load-truename*} is currently unbound
from within an editor without clobbering its source location)
@end itemize
+@subsection if-feature option
+This option allows you to specify a feature expression to be evaluated
+as if by @code{#+} to conditionally include a component in your build.
+If the expression is false, the component is dropped
+as well as any dependency pointing to it.
+As compared to using @code{#+} which is expanded at read-time,
+this allows you to have an object in your component hierarchy
+that can be used for manipulations beside building your project.
+This option was added in ASDF 3.
+
+@subsection if-component-dep-fails option
+This option was removed in ASDF 3.
+Its semantics was limited in purpose and dubious to explain,
+and its implementation was breaking a hole into the ASDF object model.
+Please use the @code{if-feature} option instead.
+
@node Other code in .asd files, , The defsystem grammar, Defining systems with defsystem
@section Other code in .asd files
Files containing @code{defsystem} forms
are regular Lisp files that are executed by @code{load}.
-Consequently, you can put whatever Lisp code you like into these files
-(e.g., code that examines the compile-time environment
-and adds appropriate features to @code{*features*}).
-However, some conventions should be followed,
+Consequently, you can put whatever Lisp code you like into these files.
+However, it is recommended to keep such forms to a minimal,
+and to instead define @code{defsystem} extensions
+that you use with @code{:defsystem-depends-on}.
+
+If however, you might insist on including code in the @code{.asd} file itself,
+e.g., to examine and adjust the compile-time environment,
+possibly adding appropriate features to @code{*features*}.
+If so, here are some conventions we recommend you follow,
so that users can control certain details of execution
of the Lisp in @file{.asd} files:
ASDF is designed in an object-oriented way from the ground up.
Both a system's structure and the operations that can be performed on systems
-follow a protocol.
-ASDF is extensible to new operations and to new component types.
-This allows the addition of behaviours:
-for example, a new component could be added for Java JAR archives,
-and methods specialised on @code{compile-op} added for it
-that would accomplish the relevant actions.
-
-This chapter deals with @emph{components}, the building blocks of a system,
-and @emph{operations}, the actions that can be performed on a system.
-
+follow a extensible protocol.
+This allows the addition of behaviours:
+for example, @code{cffi} adds support of special FFI description files
+to interface with C libraries and of wrapper files to embed C code in Lisp;
+@code{abcl-jar} supports creating Java JAR archives in ABCL;
+and @code{poiu} supports for compiling code in parallel using background processes.
+
+This chapter deals with @code{component}s and @code{operation}s.
+
+A @code{component} represents an individual source file or a group of source files,
+and the things that get transformed into.
+A @code{system} is a component at the top level of the component hierarchy.
+A @code{source-file} is a component representing a single source-file
+and the successive output files into which it is transformed.
+A @code{module} is an intermediate component itself grouping several other components,
+themselves source-files or further modules.
+
+An @code{Operation} represents a transformation that can be performed on a component,
+turning them from source files to intermediate results to final outputs.
+
+A pair of an @code{operation} and a @code{component} is called an @code{action}.
+An @code{action} represents a particular build step to be @code{perform}ed,
+after all its dependencies have been fulfilled.
+In the ASDF model, actions depend on other actions.
+The term @emph{action} itself was used by Kent Pitman in his old article,
+but was only used by ASDF hackers starting with the ASDF 2;
+but the concept is ubiquitous since the very beginning of ASDF 1,
+though previously implicit.
+
+Then, there are many @emph{functions} available
+to users, extenders and implementers of ASDF
+to use, define or implement the activities
+that are part of building your software.
+Though they manipulate @code{action}s,
+most of these functions do not take as an argument
+a reified pair (a CONS cell) of an operation and a component;
+instead, they usually take two separate arguments,
+which allows to take advantage of the power CLOS-style multiple dispatch
+for fun and profit.
+
+There are many @emph{hooks} in which to add functionality,
+by customizing the behavior of existing @emph{functions}.
+
+Last but not least is the notion of @emph{dependency} between two actions.
+The structure of dependencies between actions is
+a directed @emph{dependency graph}.
+ASDF is invoked by being told to @emph{operate}
+with some @emph{operation} on some toplevel @emph{system};
+it will then @emph{traverse} the graph and build a @emph{plan}
+that follows its structure.
+To be successfully buildable, this graph of actions but be acyclic.
+If, as a user, extender or implementer of ASDF, you fail
+to keep the dependency graph without cycles,
+ASDF will fail loudly as it eventually finds one.
+To clearly distinguish the direction of dependencies,
+ASDF 3 uses the words @emph{requiring} and @emph{required}
+as applied to an action depending on the other:
+the requiring action @code{depends-on} the completion of all required actions
+before it may itself be @code{perform}ed.
+
+Using the @code{defsystem} syntax, users may easily express
+direct dependencies along the graph of the object hierarchy:
+between a component and its parent, its children, and its siblings.
+By defining custom CLOS methods, you can express more elaborate dependencies as you wish.
+Most common operations, such as @code{load-op}, @code{compile-op} or @code{load-source-op}
+are automatically propagate ``downward'' the component hierarchy and are ``covariant'' with it:
+to act the operation on the parent module, you must first act it on all the children components,
+with the action on the parent being parent of the action on each child.
+Other operations, such as @code{prepare-op} and @code{prepare-source-op}
+(introduced in ASDF 3) are automatically propagated ``upward'' the component hierarchy
+and are ``contravariant'' with it:
+to perform the operation of preparing for compilation of a child component,
+you must perform the operation of preparing for compilation of its parent component, and so on,
+ensuring that all the parent's dependencies are (compiled and) loaded
+before the child component may be compiled and loaded.
+Yet other operations, such as @code{test-op} or @code{load-fasl-op}
+remain at the system level, and are not propagated along the hierarchy,
+but instead do something global on the system.
@menu
* Operations::
* Components::
+* Functions::
@end menu
@node Operations, Components, The object model of ASDF, The object model of ASDF
Operations can be invoked directly, or examined
to see what their effects would be without performing them.
-@emph{FIXME: document how!}
There are a bunch of methods specialised on operation and component type
that actually do the grunt work.
Operations are invoked on systems via @code{operate}.
@anchor{operate}
-@deffn {Generic function} @code{operate} @var{operation} @var{system} @&rest @var{initargs}
-@deffnx {Generic function} @code{oos} @var{operation} @var{system} @&rest @var{initargs}
+@deffn {Generic function} @code{operate} @var{operation} @var{system} @Arest @var{initargs} @Akey @code{force} @code{force-not} @code{verbose} @AallowOtherKeys
+@deffnx {Generic function} @code{oos} @var{operation} @var{system} @Arest @var{initargs} @Akey @AallowOtherKeys
@code{operate} invokes @var{operation} on @var{system}.
@code{oos} is a synonym for @code{operate}.
the new operations will be created
with the same @var{initargs} as the original one.
+If @var{force} is @code{:all}, then all systems
+are forced to be recompiled even if not modified since last compilation.
+If @var{force} is @code{t}, then only the system being loaded
+is forced to be recompiled even if not modified since last compilation,
+but other systems are not affected.
+If @var{force} is a list, then it specifies a list of systems that
+are forced to be recompiled even if not modified since last compilation.
+If @var{force-not} is @code{:all}, then all systems
+are forced not to be recompiled even if modified since last compilation.
+If @var{force-not} is @code{t}, then only the system being loaded
+is forced not to be recompiled even if modified since last compilation,
+but other systems are not affected.
+If @var{force-not} is a list, then it specifies a list of systems that
+are forced not to be recompiled even if modified since last compilation.
+@var{force} takes precedences over @var{force-not};
+both of them apply to systems that are dependencies and were already compiled.
+
+To see what @code{operate} would do, you can use:
+@example
+(asdf::traverse (make-instance operation-class initargs ...) (find-system system-name))
+@end example
+
@end deffn
@menu
(asdf:operate 'asdf:@var{operation-name} :@var{system-name} @{@var{operation-options ...}@})
@end lisp
-@deffn Operation @code{compile-op} @&key @code{proclamations}
+@deffn Operation @code{compile-op} @Akey @code{proclamations}
This operation compiles the specified component.
If proclamations are supplied, they will be proclaimed.
use @code{load-op} to load a system.
@end deffn
-@deffn Operation @code{load-op} @&key @code{proclamations}
+@deffn Operation @code{load-op} @Akey @code{proclamations}
This operation loads a system.
For parity, your own methods on new component types should probably do so too.
@end deffn
+@deffn Operation @code{parent-load-op} @Akey @code{proclamations}
+
+This operation ensures that the dependencies
+of a module, and its parent, and so on, are loaded (as per @code{load-op})
+before the components within that module may be operated upon.
+
+By default, all operations depend on this @code{parent-operation}
+for actions on components to depend on this ``parent operation'' being acted on the parent.
+
+The default methods for @code{load-op} compile files before loading them.
+For parity, your own methods on new component types should probably do so too.
+@end deffn
+
@deffn Operation @code{load-source-op}
This operation will load the source for the files in a module
should signal its results to the user
in a way that is compatible with all of the various test libraries
and test techniques in use in the community.
+
+People typically define @code{test-op} methods like thus:
+@example
+(defmethod perform ((o asdf:test-op) (s (eql (asdf:find-system @var{:mysystem}))))
+ (asdf:load-system @var{:mysystem})
+ (eval (read-from-string "(some expression that runs the tests)"))
+ t)
+@end example
@end deffn
-@c @deffn Operation test-system-version @&key minimum
+@deffn Operation @code{load-fasl-op}
-@c Asks the system whether it satisfies a version requirement.
+This operation will load and create if need be
+a single fasl file for all the files in each loaded system.
+(Its compilation-only equivalent is @code{asdf::fasl-op}.)
-@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.
+Once you have created such a fasl,
+you can use @code{precompiled-system} to deliver it in a way
+that is compatible with clients having asdf dependencies
+on your system whether it is distributed as source of as a single binary.
-@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
+On your build platform, you run something like that:
+@example
+@code{(asdf:operate 'load-fasl-op @var{:mysystem})}
+@end example
-@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
+And on your delivery platform, a form like this is evaluated
+in a prologue or at some point before you save your image:
+@example
+(defsystem :mysystem :class :precompiled-system
+ :fasl (some expression that will evaluate to a pathname))
+@end example
-@c @deffn Operation feature-dependent-op
+Of course, @emph{before} you define such systems,
+you should not forget to @code{(asdf:clear-configuration)}.
-@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.
+@code{load-fasl-op} is available on all actively supported Lisp implementations,
+and on those implementations only, and only since ASDF 3.
+This functionality was previously available for select implementations,
+as part of a separate system @code{asdf-bundle},
+itself descended from @code{asdf-ecl}.
+@end deffn
-@c @end deffn
@node Creating new operations, , Predefined operations of ASDF, Operations
@comment node-name, next, previous, up
@itemize
+@item @code{input-files}
+ASDF has a pretty clever default @code{input-files} mechanism.
+You only need create a method if there are multiple ultimate input files,
+and/or the bottom one doesn't depend
+on the @code{component-pathname} of the component.
+
@item @code{output-files}
The @code{output-files} method determines where the method will put its files.
It returns two values, a list of pathnames, and a boolean.
If the boolean is @code{NIL} then enclosing @code{:around} methods
may translate these pathnames, e.g. to ensure object files
are somehow stored in some implementation-dependent cache.
+
@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
+
+@item @code{operation-done-p}
+You only need to define a method on that function
+if you can detect conditions that invalidate previous runs of the operation,
+even though no filesystem timestamp has changed,
+in which case you return @code{nil} (the default is @code{t}).
+
+For instance, the method for @code{test-op} always returns @code{nil},
+so that tests are always run afresh.
+Of course, the @code{test-op} for your system could depend
+on a deterministically repeatable @code{test-report-op},
+and just read the results from the report files.
+
+@item @code{component-depends-on}
+When you add new operations, you probably need to explain
+how they relate to loading, compiling, testing, etc.,
+in terms of dependencies between actions.
+
+That's where you typically define methods on @code{component-depends-on}.
+Your method will take as arguments
+some properly specialized operation
+and a component denoting a current action,
+and return a list of entries,
+denoting the children actions that the current action depends on.
+The format of entries is described below.
+
+It is @emph{strongly} advised that
+you should always append the results of @code{(call-next-method)}
+to the results of your method,
+or ``interesting'' failures will likely occur,
+unless you're a true specialist of ASDF internals.
+
+Each entry returned by @code{component-depends-on} is itself a list.
+
+The first element of an entry is the name of an operation:
+a symbol that you can use with @code{make-instance}
+(ASDF will instead use with @code{asdf::make-sub-operation}),
+to create a related operation for use in a build plan.
+For instance, @code{load-op} and @code{compile-op}
+are common such names, denoting the respective operations.
+
+The rest of an entry is a list of identifiers
+each denote a component such that
+the pair of the previous operation and this component
+is a children action of current action.
+
+Identifiers follow the @code{defsystem} grammar
+previously documented.
+The main format for identifiers is a string or symbol
+(that will be downcase as per @code{coerce-name}),
+and looked up against the sibling list of the parent module's children components,
+as per @code{find-component}.
+As a special case, @code{nil} denotes the parent itself.
+Other syntaxes are allowed, for instance to specify a component with a version.
@end itemize
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
+@node Components, Functions, Operations, The object model of ASDF
@comment node-name, next, previous, up
@section Components
@cindex component
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:
+expecting a pathname to be returned, or a system object,
+from which a pathname may be extracted, and that will be registered.
+The resulting pathname (if any) is loaded
+if one of the following conditions is true:
@itemize
@item
there is no system of that name in memory
@item
+the pathname is different from that which was previously loaded
+@item
the file's @code{last-modified} time exceeds the @code{last-modified} time
of the system in memory
@end itemize
@xref{The defsystem grammar,,Pathname specifiers}.
@subsubsection Version identifier
+@findex version-satisfies
+@cindex :version
-This optional attribute is used by the @code{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,
+This optional attribute specifies a version for the current component.
+The version should typically be a string of integers separated by dots,
for example @samp{1.0.11}.
+For more information on version specifiers, see @ref{The defsystem grammar}.
-@emph{Nota Bene}:
-This operation, planned for ASDF 1,
-is still not implement yet as of ASDF 2.
-Don't hold your breath.
+A version may then be queried by the generic function @code{version-satisfies},
+to see if @code{:version} dependencies are satisfied,
+and when specifying dependencies, a constraint of minimal version to satisfy
+can be specified using e.g. @code{(:version "mydepname" "1.0.11")}.
+Note that in the wild, we typically see version numbering
+only on components of type @code{system}.
+Presumably it is much less useful within a given system,
+wherein the library author is responsible to keep the various files in synch.
@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
-@url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,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
-@url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}
-if you are interested in getting this features feature fixed.}
-
-Traditionally defsystem users have used reader conditionals
+Traditionally defsystem users have used @code{#+} reader conditionals
to include or exclude specific per-implementation files.
This means that any single implementation cannot read the entire system,
which becomes a problem if it doesn't wish to compile it,
but instead for example to create an archive file containing all the sources,
as it will omit to process the system-dependent sources for other systems.
-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*}.
-
+Each component in an asdf system may therefore specify using @code{:if-feature}
+a feature expression using the same syntax as @code{#+} does,
+such that any reference to the component will be ignored
+during compilation, loading and/or linking if the expression evaluates to false.
+Since the expression is read by the normal reader,
+you must explicitly prefix your symbols with @code{:} so they be read as keywords;
+this is as contrasted with the @code{#+} syntax
+that implicitly reads symbols in the keyword package by default.
+
+For instance, @code{:if-feature (:and :x86 (:or :sbcl :cmu :scl))} specifies that
+the given component is only to be compiled and loaded
+when the implementation is SBCL, CMUCL or Scieneer CL on an x86 machine.
+You can not write it as @code{:if-feature (and x86 (or sbcl cmu scl))}
+since the symbols would presumably fail to be read as keywords.
@subsubsection Dependencies
The syntax is approximately
@verbatim
-(this-op {(other-op required-components)}+)
+(this-op @{(other-op required-components)@}+)
-required-components := component-name
+simple-component-name := string
+ | symbol
+
+required-components := simple-component-name
| (required-components required-components)
-component-name := string
- | (:version string minimum-version-object)
+component-name := simple-component-name
+ | (:version simple-component-name minimum-version-object)
@end verbatim
Side note:
mk-defsystem is less general: it has an implied dependency
@verbatim
- for all x, (load x) depends on (compile x)
+ for all source file x, (load x) depends on (compile x)
@end verbatim
and using a @code{:depends-on} argument to say that @var{b} depends on
I'm sure they'd welcome your fixes.
@c Doesn't CLISP now support LIST method combination?
+A minimal version can be specified for a component you depend on
+(typically another system), by specifying @code{(:version "other-system" "1.2.3")}
+instead of simply @code{"other-system"} as the dependency.
+See the discussion of the semantics of @code{:version}
+in the defsystem grammar.
+
+@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.
+
+
@subsubsection pathname
This attribute is optional and if absent (which is the usual case),
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))))
- "cl")
-@end lisp
@subsubsection properties
@item
@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
-compiled.
-@emph{FIXME: such conditional compilation has been reported
-to be broken in 2009.}
+This attribute was removed in ASDF 3. Do not use it.
+Use @code{:if-feature} instead.
@item
@code{:serial} When this attribute is set,
())
@end lisp
-A hypothetical function @code{system-dependent-dirname}
+Function @code{asdf:implementation-type} (exported since 2.014.14)
gives us the name of the subdirectory.
All that's left is to define how to calculate the pathname
of an @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)))
+ (merge-pathnames*
+ (coerce-pathname (format nil "~(~A~)/" (asdf:implementation-type)))
+ (call-next-method)))
@end lisp
The new component type is used in a @code{defsystem} form in this way:
)
@end lisp
+@node Functions, , Components, The object model of ASDF
+@comment node-name, next, previous, up
+@section Functions
+@findex version-satisfies
+
+@deffn version-satisfies @var{version} @var{version-spec}
+Does @var{version} satisfy the @var{version-spec}. A generic function.
+ASDF provides built-in methods for @var{version} being a @code{component} or @code{string}.
+@var{version-spec} should be a string.
+If it's a component, its version is extracted as a string before further processing.
+
+A version string satisfies the version-spec if after parsing,
+the former is no older than the latter.
+Therefore @code{"1.9.1"}, @code{"1.9.2"} and @code{"1.10"} all satisfy @code{"1.9.1"},
+but @code{"1.8.4"} or @code{"1.9"} do not.
+For more information about how @code{version-satisfies} parses and interprets
+version strings and specifications,
+@pxref{The defsystem grammar} (version specifiers) and
+@ref{Common attributes of components}.
+
+Note that in versions of ASDF prior to 3.0.1,
+including the entire ASDF 1 and ASDF 2 series,
+@code{version-satisfies} would also require that the version and the version-spec
+have the same major version number (the first integer in the list);
+if the major version differed, the version would be considered as not matching the spec.
+But that feature was not documented, therefore presumably not relied upon,
+whereas it was a nuisance to several users.
+Starting with ASDF 3.0.1,
+@code{version-satisfies} does not treat the major version number specially,
+and returns T simply if the first argument designates a version that isn't older
+than the one specified as a second argument.
+If needs be, the @code{(:version ...)} syntax for specifying dependencies
+could be in the future extended to specify an exclusive upper bound for compatible versions
+as well as an inclusive lower bound.
+@end deffn
+
@node Controlling where ASDF searches for systems, Controlling where ASDF saves compiled files, The object model of ASDF, Top
@comment node-name, next, previous, up
@chapter Controlling where ASDF searches for systems
(at the time that the configuration is initialized) as well as
@code{:directory} entries for @file{$XDG_DATA_DIRS/common-lisp/systems/} and
@code{:tree} entries for @file{$XDG_DATA_DIRS/common-lisp/source/}.
+For instance, SBCL will include directories for its contribs
+when it can find them; it will look for them where SBCL was installed,
+or at the location specified by the @code{SBCL_HOME} environment variable.
@end enumerate
-Each of these configuration is specified as a SEXP
-in a trival domain-specific language (defined below).
+Each of these configurations is specified as an s-expression
+in a trivial domain-specific language (defined below).
Additionally, a more shell-friendly syntax is available
for the environment variable (defined yet below).
may be automatically prepended to whatever directories are specified
in configuration files, no matter if the last one inherits or not.
+
+@section Truenames and other dangers
+
+One great innovation of the original ASDF was its ability to leverage
+@code{CL:TRUENAME} to locate where your source code was and where to build it,
+allowing for symlink farms as a simple but effective configuration mechanism
+that is easy to control programmatically.
+ASDF 3 still supports this configuration style, and it is enabled by default;
+however we recommend you instead use
+our source-registry configuration mechanism described below,
+because it is easier to setup in a portable way across users and implementations.
+
+Addtionally, some people dislike truename,
+either because it is very slow on their system, or
+because they are using content-addressed storage where the truename of a file
+is related to a digest of its individual contents,
+and not to other files in the same intended project.
+For these people, ASDF 3 allows to eschew the @code{TRUENAME} mechanism,
+by setting the variable @var{asdf:*resolve-symlinks*} to @code{NIL}.
+
+PS: Yes, if you haven't read Vernor Vinge's short but great classic
+``True Names... and Other Dangers'' then you're in for a treat.
+
+
@section XDG base directory
Note that we purport to respect the XDG base directory specification
instead of the XDG base directory specification,
we try to use folder configuration from the registry regarding
@code{Common AppData} and similar directories.
-However, support querying the Windows registry is limited as of ASDF 2,
-and on many implementations, we may fall back to always using the defaults
-without consulting the registry.
-Patches welcome.
+Since support for querying the Windows registry
+is not possible to do in reasonable amounts of portable Common Lisp code,
+ASDF 3 relies on the environment variables that Windows usually exports.
@section Backward Compatibility
-For backward compatibility as well as for a practical backdoor for hackers,
+For backward compatibility as well as to provide a practical backdoor for hackers,
ASDF will first search for @code{.asd} files in the directories specified in
@code{asdf:*central-registry*}
before it searches in the source registry above.
-@xref{Configuring ASDF,,Configuring ASDF to find your systems -- old style}.
+@xref{Configuring ASDF,,Configuring ASDF to find your systems --- old style}.
By default, @code{asdf:*central-registry*} will be empty.
@section Configuration DSL
-Here is the grammar of the SEXP DSL for source-registry configuration:
+Here is the grammar of the s-expression (SEXP) DSL for source-registry
+configuration:
+
+@c FIXME: This is too wide for happy compilation into pdf.
@example
-;; A configuration is single SEXP starting with keyword :source-registry
+;; A configuration is a single SEXP starting with keyword :source-registry
;; followed by a list of directives.
CONFIGURATION := (:source-registry DIRECTIVE ...)
:inherit-configuration | ; splices inherited configuration (often specified last)
:ignore-inherited-configuration | ; drop inherited configuration (specified anywhere)
+ ;; forward compatibility directive (since ASDF 2.011.4), useful when
+ ;; you want to use new configuration features but have to bootstrap a
+ ;; the newer required ASDF from an older release that doesn't sport said features:
+ :ignore-invalid-entries | ; drops subsequent invalid entries instead of erroring out
+
;; add a single directory to be scanned (no recursion)
(:directory DIRECTORY-PATHNAME-DESIGNATOR) |
(:tree DIRECTORY-PATHNAME-DESIGNATOR) |
;; override the defaults for exclusion patterns
- (:exclude PATTERN ...) |
+ (:exclude EXCLUSION-PATTERN ...) |
;; augment the defaults for exclusion patterns
- (:also-exclude PATTERN ...) |
+ (:also-exclude EXCLUSION-PATTERN ...) |
+ ;; Note that the scope of a an exclude pattern specification is
+ ;; the rest of the current configuration expression or file.
;; splice the parsed contents of another config file
(:include REGULAR-FILE-PATHNAME-DESIGNATOR) |
;; This directive specifies that some default must be spliced.
:default-registry
-PATTERN := a string without wildcards, that will be matched exactly
+REGULAR-FILE-PATHNAME-DESIGNATOR := PATHNAME-DESIGNATOR ;; interpreted as a file
+DIRECTORY-PATHNAME-DESIGNATOR := PATHNAME-DESIGNATOR ;; interpreted as a directory name
+
+PATHNAME-DESIGNATOR :=
+ NIL | ;; Special: skip this entry.
+ ABSOLUTE-COMPONENT-DESIGNATOR ;; see pathname DSL
+
+EXCLUSION-PATTERN := a string without wildcards, that will be matched exactly
against the name of a any subdirectory in the directory component
of a path. e.g. @code{"_darcs"} will match @file{#p"/foo/bar/_darcs/src/bar.asd"}
@end example
+Pathnames are designated using another DSL,
+shared with the output-translations configuration DSL below.
+The DSL is resolved by the function @code{asdf::resolve-location},
+to be documented and exported at some point in the future.
+
+@example
+ABSOLUTE-COMPONENT-DESIGNATOR :=
+ (ABSOLUTE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
+ STRING | ;; namestring (better be absolute or bust, directory assumed where applicable).
+ ;; In output-translations, directory is assumed and **/*.*.* added if it's last.
+ ;; On MCL, a MacOSX-style POSIX namestring (for MacOS9 style, use #p"...");
+ ;; Note that none of the above applies to strings used in *central-registry*,
+ ;; which doesn't use this DSL: they are processed as normal namestrings.
+ ;; however, you can compute what you put in the *central-registry*
+ ;; based on the results of say (asdf::resolve-location "/Users/fare/cl/cl-foo/")
+ PATHNAME | ;; pathname (better be an absolute path, or bust)
+ ;; In output-translations, unless followed by relative components,
+ ;; it better have appropriate wildcards, as in **/*.*.*
+ :HOME | ;; designates the user-homedir-pathname ~/
+ :USER-CACHE | ;; designates the default location for the user cache
+ :HERE | ;; designates the location of the configuration file
+ ;; (or *default-pathname-defaults*, if invoked interactively)
+ :ROOT ;; magic, for output-translations source only: paths that are relative
+ ;; to the root of the source host and device
+ ;; Not valid anymore: :SYSTEM-CACHE (was a security hazard)
+
+RELATIVE-COMPONENT-DESIGNATOR :=
+ (RELATIVE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
+ STRING | ;; relative directory pathname as interpreted by coerce-pathname.
+ ;; In output translations, if last component, **/*.*.* is added
+ PATHNAME | ;; pathname; unless last component, directory is assumed.
+ :IMPLEMENTATION | ;; directory based on implementation, e.g. sbcl-1.0.45-linux-x64
+ :IMPLEMENTATION-TYPE | ;; a directory based on lisp-implementation-type only, e.g. sbcl
+ :DEFAULT-DIRECTORY | ;; a relativized version of the default directory
+ :*/ | ;; any direct subdirectory (since ASDF 2.011.4)
+ :**/ | ;; any recursively inferior subdirectory (since ASDF 2.011.4)
+ :*.*.* | ;; any file (since ASDF 2.011.4)
+ ;; Not supported (anymore): :UID and :USERNAME
+@end example
+
For instance, as a simple case, my @file{~/.config/common-lisp/source-registry.conf},
-which is the default place ASDF looks for this configuration,
-once contained:
+which is the default place ASDF looks for this configuration, once contained:
@example
(:source-registry
- (:tree "/home/fare/cl/")
+ (:tree (:home "cl")) ;; will expand to e.g. "/home/joeluser/cl/"
:inherit-configuration)
@end example
-
@section Configuration Directories
-Configuration directories consist in files each contains
+Configuration directories consist in files each containing
a list of directives without any enclosing @code{(:source-registry ...)} 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.
(:tree "/home/fare/cl/")
@end example
+@subsection The :here directive
+
+The @code{:here} directive is an absolute pathname designator that
+refers to the directory containing the configuration file currently
+being processed.
+
+The @code{:here} directive is intended to simplify the delivery of
+complex CL systems, and for easy configuration of projects shared through
+revision control systems, in accordance with our design principle that
+each participant should be able to provide all and only the information
+available to him or her.
+
+Consider a person X who has set up the source code repository for a
+complex project with a master directory @file{dir/}. Ordinarily, one
+might simply have the user add a directive that would look something
+like this:
+@example
+ (:tree "path/to/dir")
+@end example
+But what if X knows that there are very large subtrees
+under dir that are filled with, e.g., Java source code, image files for
+icons, etc.? All of the asdf system definitions are contained in the
+subdirectories @file{dir/src/lisp/} and @file{dir/extlib/lisp/}, and
+these are the only directories that should be searched.
+
+In this case, X can put into @file{dir/} a file @file{asdf.conf} that
+contains the following:
+@example
+(:source-registry
+ (:tree (:here "src/lisp/"))
+ (:tree (:here "extlib/lisp"))
+ (:directory (:here "outlier/")))
+@end example
+
+Then when someone else (call her Y) checks out a copy of this
+repository, she need only add
+@example
+(:include "/path/to/my/checkout/directory/asdf.conf")
+@end example
+to one of her previously-existing asdf source location configuration
+files, or invoke @code{initialize-source-registry} with a configuration
+form containing that s-expression. ASDF will find the .conf file that X
+has provided, and then set up source locations within the working
+directory according to X's (relative) instructions.
@section Shell-friendly syntax for configuration
@section Search Algorithm
+@vindex *default-source-registry-exclusions*
In case that isn't clear, the semantics of the configuration is that
when searching for a system of a given name,
Thus for ASDF the corresponding functions are in package ASDF,
and for XCVB the corresponding functions are in package XCVB.
-@defun initialize-source-registry @&optional PARAMETER
+@defun initialize-source-registry @Aoptional PARAMETER
will read the configuration and initialize all internal variables.
You may extend or override configuration
from the environment and configuration files
@defun clear-source-registry
undoes any source registry configuration
and clears any cache for the search algorithm.
- You might want to call that before you
- dump an image that would be resumed with a different configuration,
+ You might want to call this function
+ (or better, @code{clear-configuration})
+ before you dump an image that would be resumed
+ with a different configuration,
and return an empty configuration.
Note that this does not include clearing information about
systems defined in the current image, only about
where to look for systems not yet defined.
@end defun
-@defun ensure-source-registry @&optional PARAMETER
+@defun ensure-source-registry @Aoptional PARAMETER
checks whether a source registry has been initialized.
If not, initialize it with the given @var{PARAMETER}.
@end defun
+Every time you use ASDF's @code{find-system}, or
+anything that uses it (such as @code{operate}, @code{load-system}, etc.),
+@code{ensure-source-registry} is called with parameter NIL,
+which the first time around causes your configuration to be read.
+If you change a configuration file,
+you need to explicitly @code{initialize-source-registry} again,
+or maybe simply to @code{clear-source-registry} (or @code{clear-configuration})
+which will cause the initialization to happen next time around.
-@section Future
-If this mechanism is successful, in the future, we may declare
-@code{asdf:*central-registry*} obsolete and eventually remove it.
-Any hook into implementation-specific search mechanisms will by then
-have been integrated in the @code{:default-configuration} which everyone
-should either explicitly use or implicit inherit. Some shell syntax
-for it should probably be added somehow.
+@section Status
-But we're not there yet. For now, let's see how practical this new
-source-registry is.
+This mechanism is vastly successful, and we have declared
+that @code{asdf:*central-registry*} is not recommended anymore,
+though we will continue to support it.
+All hooks into implementation-specific search mechanisms
+have been integrated in the @code{wrapping-source-registry}
+that everyone uses implicitly.
@section Rejected ideas
which means that you'll have to recompile binaries
as you switch from one implementation to the next.
-ASDF 2 includes the @code{asdf-output-translations} facility
+Since ASDF 2, ASDF includes the @code{asdf-output-translations} facility
to mitigate the problem.
@section Configurations
@section Backward Compatibility
+@cindex ASDF-BINARY-LOCATIONS compatibility
-@c FIXME -- I think we should provide an easy way
-@c to get behavior equivalent to A-B-L and
-@c I will propose a technique for doing this.
We purposefully do NOT provide backward compatibility with earlier versions of
@code{ASDF-Binary-Locations} (8 Sept 2009),
Nevertheless, if you are a fan of @code{ASDF-Binary-Locations},
we provide a limited emulation mode:
-@defun asdf:enable-asdf-binary-locations-compatibility @&key centralize-lisp-binaries default-toplevel-directory include-per-user-information map-all-source-files source-to-target-mappings
+@defun enable-asdf-binary-locations-compatibility @Akey centralize-lisp-binaries default-toplevel-directory include-per-user-information map-all-source-files source-to-target-mappings
This function will initialize the new @code{asdf-output-translations} facility in a way
that emulates the behavior of the old @code{ASDF-Binary-Locations} facility.
Where you would previously set global variables
:inherit-configuration | ; splices inherited configuration (often specified last)
:ignore-inherited-configuration | ; drop inherited configuration (specified anywhere)
+ ;; forward compatibility directive (since ASDF 2.011.4), useful when
+ ;; you want to use new configuration features but have to bootstrap a
+ ;; the newer required ASDF from an older release that doesn't sport said features:
+ :ignore-invalid-entries | ; drops subsequent invalid entries instead of erroring out
+
;; include a configuration file or directory
(:include PATHNAME-DESIGNATOR) |
- ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.35-x86-64/ or something.
+ ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/ or something.
:enable-user-cache |
;; Disable global cache. Map / to /
:disable-cache |
(DIRECTORY-DESIGNATOR (:function TRANSLATION-FUNCTION))
DIRECTORY-DESIGNATOR :=
+ NIL | ;; As source: skip this entry. As destination: same as source
T | ;; as source matches anything, as destination leaves pathname unmapped.
- ABSOLUTE-COMPONENT-DESIGNATOR |
- (ABSOLUTE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...)
-
-ABSOLUTE-COMPONENT-DESIGNATOR :=
- NULL | ;; As source: skip this entry. As destination: same as source
- :ROOT | ;; magic: paths that are relative to the root of the source host and device
- 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
- :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(!)
+ ABSOLUTE-COMPONENT-DESIGNATOR ;; same as in the source-registry language
TRANSLATION-FUNCTION :=
SYMBOL | ;; symbol of a function that takes two arguments,
before it is translated.
When the second designator is @code{t}, the mapping is the identity.
-When the second designator starts with @code{root},
+When the second designator starts with @code{:root},
the mapping preserves the host and device of the original pathname.
+Notably, this allows you to map files
+to a subdirectory of the whichever directory the file is in.
+Though the syntax is not quite as easy to use as we'd like,
+you can have an (source destination) mapping entry such as follows
+in your configuration file,
+or you may use @code{enable-asdf-binary-locations-compatibility}
+with @code{:centralize-lisp-binaries nil}
+which will do the same thing internally for you:
+@verbatim
+ #.(let ((wild-subdir (make-pathname :directory '(:relative :wild-inferiors)))
+ (wild-file (make-pathname :name :wild :version :wild :type :wild)))
+ `((:root ,wild-subdir ,wild-file) ;; Or using the implicit wildcard, just :root
+ (:root ,wild-subdir :implementation ,wild-file)))
+@end verbatim
+Starting with ASDF 2.011.4, you can use the simpler:
+ @code{`(:root (:root :**/ :implementation :*.*.*))}
+
+
@code{:include} statements cause the search to recurse with the path specifications
from the file specified.
The specified functions are exported from package ASDF.
-@defun initialize-output-translations @&optional PARAMETER
+@defun initialize-output-translations @Aoptional PARAMETER
will read the configuration and initialize all internal variables.
You may extend or override configuration
from the environment and configuration files
@defun clear-output-translations
undoes any output translation 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,
+ You might want to call this function
+ (or better, @code{clear-configuration})
+ before you dump an image that would be resumed
+ with a different configuration,
and return an empty configuration.
Note that this does not include clearing information about
systems defined in the current image, only about
where to look for systems not yet defined.
@end defun
-@defun ensure-output-translations @&optional PARAMETER
+@defun ensure-output-translations @Aoptional PARAMETER
checks whether output translations have been initialized.
If not, initialize them with the given @var{PARAMETER}.
This function will be called before any attempt to operate on a system.
(calls @code{ensure-output-translations} for the translations).
@end defun
+Every time you use ASDF's @code{output-files}, or
+anything that uses it (that may compile, such as @code{operate}, @code{perform}, etc.),
+@code{ensure-output-translations} is called with parameter NIL,
+which the first time around causes your configuration to be read.
+If you change a configuration file,
+you need to explicitly @code{initialize-output-translations} again,
+or maybe @code{clear-output-translations} (or @code{clear-configuration}),
+which will cause the initialization to happen next time around.
+
@section Credits for output translations
@c @itemize
@c @item
-@c SBCL, version 1.0 on Mac OS X for intel: @code{sbcl-1.0-darwin-x86}
+@c SBCL, version 1.0.45 on Mac OS X for Intel: @code{sbcl-1.0.45-darwin-x86}
@c @item
@c Franz Allegro, version 8.0, ANSI Common Lisp: @code{allegro-8.0a-macosx-x86}
@comment node-name, next, previous, up
@chapter Miscellaneous additional functionality
-@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:
+useful for system definition and development.
+
+@section Controlling file compilation
+
+When declaring a component (system, module, file),
+you can specify a keyword argument @code{:around-compile function}.
+If left unspecified (and therefore unbound),
+the value will be inherited from the parent component if any,
+or with a default of @code{nil}
+if no value is specified in any transitive parent.
+
+The argument must be a either @code{nil}, a fbound symbol,
+a lambda-expression (e.g. @code{(lambda (thunk) ...(funcall thunk ...) ...)})
+a function object (e.g. using @code{#.#'} but that's discouraged
+because it prevents the introspection done by e.g. asdf-dependency-grovel),
+or a string that when @code{read} yields a symbol or a lambda-expression.
+@code{nil} means the normal compile-file function will be called.
+A non-nil value designates a function of one argument
+that will be called with a function that will
+invoke @code{compile-file*} with various arguments;
+the around-compile hook may supply additional keyword arguments
+to pass to that call to @code{compile-file*}.
+
+One notable argument that is heeded by @code{compile-file*} is
+@code{:compile-check},
+a function called when the compilation was otherwise a success,
+with the same arguments as @code{compile-file};
+the function shall return true if the compilation
+and its resulting compiled file respected all system-specific invariants,
+and false (@code{nil}) if it broke any of those invariants;
+it may issue warnings or errors before it returns @code{nil}.
+(NB: The ability to pass such extra flags
+is only available starting with ASDF 2.22.3.)
+This feature is notably exercised by asdf-finalizers.
+
+By using a string, you may reference
+a function, symbol and/or package
+that will only be created later during the build, but
+isn't yet present at the time the defsystem form is evaluated.
+However, if your entire system is using such a hook, you may have to
+explicitly override the hook with @code{nil} for all the modules and files
+that are compiled before the hook is defined.
+
+Using this hook, you may achieve such effects as:
+locally renaming packages,
+binding @var{*readtables*} and other syntax-controlling variables,
+handling warnings and other conditions,
+proclaiming consistent optimization settings,
+saving code coverage information,
+maintaining meta-data about compilation timings,
+setting gensym counters and PRNG seeds and other sources of non-determinism,
+overriding the source-location and/or timestamping systems,
+checking that some compile-time side-effects were properly balanced,
+etc.
+
+Note that there is no around-load hook. This is on purpose.
+Some implementations such as ECL, GCL or MKCL link object files,
+which allows for no such hook.
+Other implementations allow for concatenating FASL files,
+which doesn't allow for such a hook either.
+We aim to discourage something that's not portable,
+and has some dubious impact on performance and semantics
+even when it is possible.
+Things you might want to do with an around-load hook
+are better done around-compile,
+though it may at times require some creativity
+(see e.g. the @code{package-renaming} system).
+
+
+@section Controlling source file character encoding
+
+Starting with ASDF 2.21, components accept a @code{:encoding} option
+so authors may specify which character encoding should be used
+to read and evaluate their source code.
+When left unspecified, the encoding is inherited
+from the parent module or system;
+if no encoding is specified at any point,
+the default @code{:autodetect} is assumed.
+By default, only @code{:default}, @code{:utf-8}
+and @code{:autodetect} are accepted.
+@code{:autodetect}, the default, calls
+@code{*encoding-detection-hook*} which by default always returns
+@code{*default-encoding*} which itself defaults to @code{:default}.
+
+In other words, there now are plenty of extension hooks, but
+by default ASDF follows the backwards compatible behavior
+of using whichever @code{:default} encoding your implementation uses,
+which itself may or may not vary based on environment variables
+and other locale settings.
+In practice this means that only source code that only uses ASCII
+is guaranteed to be read the same on all implementations
+independently from any user setting.
+
+Additionally, for backward-compatibility with older versions of ASDF
+and/or with implementations that do not support unicode and its many encodings,
+you may want to use
+the reader conditionals @code{#+asdf-unicode #+asdf-unicode}
+to protect any @code{:encoding @emph{encoding}} statement
+as @code{:asdf-unicode} will be present in @code{*features*}
+only if you're using a recent ASDF
+on an implementation that supports unicode.
+We recommend that you avoid using unprotected @code{:encoding} specifications
+until after ASDF 2.21 or later becomes widespread, hopefully by the end of 2012.
+
+While it offers plenty of hooks for extension,
+and one such extension is being developed (see below),
+ASDF itself only recognizes one encoding beside @code{:default},
+and that is @code{:utf-8}, which is the @emph{de facto} standard,
+already used by the vast majority of libraries that use more than ASCII.
+On implementations that do not support unicode,
+the feature @code{:asdf-unicode} is absent, and
+the @code{:default} external-format is used
+to read even source files declared as @code{:utf-8}.
+On these implementations, non-ASCII characters
+intended to be read as one CL character
+may thus end up being read as multiple CL characters.
+In most cases, this shouldn't affect the software's semantics:
+comments will be skipped just the same, strings with be read and printed
+with slightly different lengths, symbol names will be accordingly longer,
+but none of it should matter.
+But a few systems that actually depend on unicode characters
+may fail to work properly, or may work in a subtly different way.
+See for instance @code{lambda-reader}.
+
+We invite you to embrace UTF-8
+as the encoding for non-ASCII characters starting today,
+even without any explicit specification in your @code{.asd} files.
+Indeed, on some implementations and configurations,
+UTF-8 is already the @code{:default},
+and loading your code may cause errors if it is encoded in anything but UTF-8.
+Therefore, even with the legacy behavior,
+non-UTF-8 is guaranteed to break for some users,
+whereas UTF-8 is pretty much guaranteed not to break anywhere
+(provided you do @emph{not} use a BOM),
+although it might be read incorrectly on some implementations.
+In the future, we intend to make @code{:utf-8}
+the default value of @code{*default-encoding*},
+to be enforced everywhere, so at least the code is guaranteed
+to be read correctly everywhere it can be.
+
+If you need non-standard character encodings for your source code,
+use the extension system @code{asdf-encodings}, by specifying
+@code{:defsystem-depends-on (:asdf-encodings)} in your @code{defsystem}.
+This extension system will register support for more encodings using the
+@code{*encoding-external-format-hook*} facility,
+so you can explicitly specify @code{:encoding :latin1}
+in your @code{.asd} file.
+Using the @code{*encoding-detection-hook*} it will also
+eventually implement some autodetection of a file's encoding
+from an emacs-style @code{-*- mode: lisp ; coding: latin1 -*-} declaration,
+or otherwise based on an analysis of octet patterns in the file.
+At this point, asdf-encoding only supports the encodings
+that are supported as part of your implementation.
+Since the list varies depending on implementations,
+we once again recommend you use @code{:utf-8} everywhere,
+which is the most portable (next is @code{:latin1}).
+
+If you're not using a version of Quicklisp that has it,
+you may get the source for @code{asdf-encodings} using git:
+@kbd{git clone git://common-lisp.net/projects/asdf/asdf-encodings.git}
+or
+@kbd{git clone ssh://common-lisp.net/project/asdf/git/asdf-encodings.git}.
+You can also browse the repository on
+@url{http://common-lisp.net/gitweb?p=projects/asdf/asdf-encodings.git}.
+
+In the future, we intend to change the default @code{*default-encoding*}
+to @code{:utf-8}, which is already the de facto standard
+for most libraries that use non-ASCII characters:
+utf-8 works everywhere and was backhandedly enforced by
+a lot of people using SBCL and utf-8 and sending reports to authors
+so they make their packages compatible.
+A survey showed only about a handful few libraries
+are incompatible with non-UTF-8, and then, only in comments,
+and we believe that authors will adopt UTF-8 when prompted.
+See the April 2012 discussion on the asdf-devel mailing-list.
+For backwards compatibility with users who insist on a non-UTF-8 encoding,
+but cannot immediately transition to using @code{asdf-encodings}
+(maybe because it isn't ready), it will still be possible to use
+the @code{:encoding :default} option in your @code{defsystem} form
+to restore the behavior of ASDF 2.20 and earlier.
+This shouldn't be required in libraries,
+because user pressure as mentioned above will already have pushed
+library authors towards using UTF-8;
+but authors of end-user programs might care.
+
+When you use @code{asdf-encodings}, any further loaded @code{.asd} file
+will use the autodetection algorithm to determine its encoding;
+yet if you depend on this detection happening,
+you may want to explicitly load @code{asdf-encodings} early in your build,
+for by the time you can use @code{:defsystem-depends-on},
+it is already too late to load it.
+In practice, this means that the @code{*default-encoding*}
+is usually used for @code{.asd} files.
+Currently, this defaults to @code{:default} for backwards compatibility,
+and that means that you shouldn't rely on non-ASCII characters in a .asd file.
+Since component (path)names are the only real data in these files,
+and non-ASCII characters are not very portable for file names,
+this isn't too much of an issue.
+We still encourage you to use either plain ASCII or UTF-8
+in @code{.asd} files,
+as we intend to make @code{:utf-8} the default encoding in the future.
+This might matter, for instance, in meta-data about author's names.
+
+
+@section Miscellaneous Functions
+
+Most of these functions are not exported by ASDF anymore,
+but only used for private purposes of ASDF.
+Please use ASDF-UTILS for the same functions exported from a stable library.
+
+@defun coerce-pathname name @Akey type defaults
+
+This function (available starting with ASDF 2.012.11)
+takes an argument, and portably interprets it as a pathname.
+If the argument @var{name} is a pathname or @code{nil}, it is passed through;
+if it's a symbol, it's interpreted as a string by downcasing it;
+if it's a string, it is first separated using @code{/} into substrings;
+the leading substrings denote subdirectories of a relative pathname.
+If @var{type} is @code{:directory} or the string ends with @code{/},
+the last substring is also a subdirectory;
+if @var{type} is a string, it is used as the type of the pathname, and
+the last substring is the name component of the pathname;
+if @var{type} is @code{nil}, the last substring specifies both name and type components
+of the pathname, with the last @code{.} separating them, or only the name component
+if there's no last @code{.} or if there is only one dot and it's the first character.
+The host, device and version components come from @var{defaults}, which defaults to
+@var{*default-pathname-defaults*}; but that shouldn't matter if you use @code{merge-pathnames*}.
+
+@end defun
+
+@defun merge-pathnames* @Akey specified defaults
-@defun system-relative-pathname system name @&key type
+This function is a replacement for @code{merge-pathnames} that uses the host and device
+from the @var{defaults} rather than the @var{specified} pathname when the latter
+is a relative pathname. This allows ASDF and its users to create and use relative pathnames
+without having to know beforehand what are the host and device
+of the absolute pathnames they are relative to.
+
+@end defun
+
+@defun system-relative-pathname system name @Akey type
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
+
+It takes two mandatory arguments @var{system} and @var{name}
+and a keyword argument @var{type}:
+@var{system} is name of a system, whereas @var{name} and optionally @var{type}
+specify a relative pathname, interpreted like a component pathname specifier
+by @code{coerce-pathname}. @xref{The defsystem grammar,,Pathname specifiers}.
+
+It returns a pathname built from the location of the system's
+source directory and the relative pathname. For example:
@lisp
-> (asdf:system-relative-pathname 'cl-ppcre #p"regex.data")
+> (asdf:system-relative-pathname 'cl-ppcre "regex.data")
#P"/repository/other/cl-ppcre/regex.data"
@end lisp
-Instead of a pathname, you can provide a symbol or a string,
-and optionally a keyword argument @code{type}.
-The arguments will then be interpreted in the same way
-as pathname specifiers for components.
-@xref{The defsystem grammar,,Pathname specifiers}.
@end defun
@defun system-source-directory system-designator
-ASDF does not provide a turnkey solution for locating data (or other
-miscellaneous) files that are distributed together with the source code
-of a system. Programmers can use @code{system-source-directory} to find
-such files. Returns a pathname object. The @var{system-designator} may
-be a string, symbol, or ASDF system object.
+ASDF does not provide a turnkey solution for locating
+data (or other miscellaneous) files
+that are distributed together with the source code of a system.
+Programmers can use @code{system-source-directory} to find such files.
+Returns a pathname object.
+The @var{system-designator} may be a string, symbol, or ASDF system object.
+@end defun
+
+@defun clear-system system-designator
+
+It is sometimes useful to force recompilation of a previously loaded system.
+In these cases, it may be useful to @code{(asdf:clear-system :foo)}
+to remove the system from the table of currently loaded systems;
+the next time the system @code{foo} or one that depends on it is re-loaded,
+@code{foo} will then be loaded again.
+Alternatively, you could touch @code{foo.asd} or
+remove the corresponding fasls from the output file cache.
+(It was once conceived that one should provide
+a list of systems the recompilation of which to force
+as the @code{:force} keyword argument to @code{load-system};
+but this has never worked, and though the feature was fixed in ASDF 2.000,
+it remains @code{cerror}'ed out as nobody ever used it.)
+
+Note that this does not and cannot by itself undo the previous loading
+of the system. Common Lisp has no provision for such an operation,
+and its reliance on irreversible side-effects to global datastructures
+makes such a thing impossible in the general case.
+If the software being re-loaded is not conceived with hot upgrade in mind,
+this re-loading may cause many errors, warnings or subtle silent problems,
+as packages, generic function signatures, structures, types, macros, constants, etc.
+are being redefined incompatibly.
+It is up to the user to make sure that reloading is possible and has the desired effect.
+In some cases, extreme measures such as recursively deleting packages,
+unregistering symbols, defining methods on @code{update-instance-for-redefined-class}
+and much more are necessary for reloading to happen smoothly.
+ASDF itself goes through notable pains to make such a hot upgrade possible
+with respect to its own code, and what it does is ridiculously complex;
+look at the beginning of @file{asdf.lisp} to see what it does.
+@end defun
+
+@defun run-program
+
+run-program takes a @var{COMMAND} argument that is either
+a list of a program path and its arguments,
+or a string to be executed by a shell.
+It spawns the command, waits for it to return,
+verifies that it exited cleanly (unless told not too below),
+and optionally captures and processes its output.
+It accepts many keyword arguments to configure its behavior.
+
+@code{output} is its most important argument;
+it specifies how the output is captured and processed.
+If it is @code{nil}, then the output is not captured.
+If it is @code{:interactive}, then
+input and output are inherited from the current process,
+which the subprocess can control until it exits.
+Otherwise, the output is captured and redirected to a stream,
+and processed by @code{slurp-input-stream} with the object as first argument.
+See below.
+
+@code{element-type} and @code{external-format} are passed on
+to your Lisp implementation, when available, for creation of the output stream.
+
+@code{force-shell} forces evaluation of the command through a shell,
+even if it was passed as a list rather than a string.
+
+@code{ignore-error-status} causes @code{run-program}
+to not raise an error if the spawned program exits in error.
+Following POSIX convention, an error is anything but
+a normal exit with status code zero.
+
+run-program works on all platforms supported by ASDF, except Genera.
+
+@end defun
+
+@defun slurp-input-stream
+
+It's a generic function of two arguments, a target object and an input stream,
+and accepting keyword arguments.
+Predefined methods based on the target object are as follow:
+
+If the object is a function, the function is called with the stream as argument.
+
+If the object is a cons, its first element is applied to its rest appended by
+a list of the input stream.
+
+If the object is an output stream, the contents of the input stream are copied to it.
+If the linewise argument is provided, copying happens line by line,
+and an optional prefix is printed before each line.
+Otherwise, copying happen based on a buffer of size buffer-size,
+using the element-type.
+
+If the object is 'string or :string, the content is captured into a string
+of the given element-type.
+
+If the object is :lines, the content is captured as a list of strings,
+one per line, without line ending. If the count argument is provided,
+it is a maximum count of lines to be read.
+
+If the object is :line, the content is capture as with :lines above,
+and then its sub-object is extracted with the path argument,
+which defaults to 0, extracting the first line.
+A number will extract the corresponding line.
+See the documentation for asdf-driver:sub-object.
+
+If the object is :forms, the content is captured as a list of S-expressions,
+as read by the Lisp reader.
+If the count argument is provided,
+it is a maximum count of lines to be read.
+We recommend you control the syntax with such macro as
+asdf-driver:with-safe-io-syntax.
+
+If the object is :form, the content is capture as with :forms above,
+and then its sub-object is extracted with the path argument,
+which defaults to 0, extracting the first form.
+A number will extract the corresponding form.
+See the documentation for asdf-driver:sub-object.
+We recommend you control the syntax with such macro as
+asdf-driver:with-safe-io-syntax.
+
+@end defun
+
+@defun run-shell-command
+
+This function is obsolete and present only for the sake of backwards-compatibility:
+``If it's not backwards, it's not compatible''. We strongly discourage its use.
+Its current behavior is only well-defined on Unix platforms
+(which include MacOS X and cygwin). On Windows, anything goes.
+The following documentation is only for the purpose of your migrating away from it
+in a way that preserves semantics.
+
+Instead we recommend the use @code{run-program} above
+available as part of ASDF since ASDF 3.
+
+@code{run-shell-command} takes as arguments a @code{format} control-string
+and arguments to be passed to @code{format} after this control-string
+to produce a string.
+This string is a command that will be evaluated with a POSIX shell if possible;
+yet, on Windows, some implementations will use CMD.EXE,
+while others (like SBCL) will make an attempt at invoking a POSIX shell
+(and fail if it is not present).
@end defun
@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.
+The @code{master} branch is where development happens;
+its @code{HEAD} is usually OK, including the latest fixes and portability tweaks,
+but an occasional regression may happen despite our (limited) test suite.
+
+The @code{release} branch is what cautious people should be using;
+it has usually been tested more, and releases are cut at a point
+where there isn't any known unresolved issue.
You may get the ASDF source repository using git:
@kbd{git clone git://common-lisp.net/projects/asdf/asdf.git}
ASDF bugs are tracked on launchpad: @url{https://launchpad.net/asdf}.
-If you're unsure about whether something is a bug, of for general discussion,
+If you're unsure about whether something is a bug, or for general discussion,
use the @url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}
to see if the new API is present.
@emph{All} versions of ASDF should have the @code{:asdf} feature.
+Additionally, all versions of ASDF 2
+define a function @code{(asdf:asdf-version)} you may use to query the version;
+and the source code of recent versions of ASDF 2 features the version number
+prominently on the second line of its source code.
+
If you are experiencing problems or limitations of any sort with ASDF 1,
we recommend that you should upgrade to ASDF 2,
or whatever is the latest release.
ASDF 2 implements its own portable syntax for strings as pathname specifiers.
Naming files within a system definition becomes easy and portable again.
@xref{Miscellaneous additional functionality,asdf:system-relative-pathname},
-@code{asdf-utilities:merge-pathnames*},
-@code{asdf::merge-component-name-type}.
+@code{merge-pathnames*},
+@code{coerce-pathname}.
On the other hand, there are places where systems used to accept namestrings
where you must now use an explicit pathname object:
@itemize
@item
-The infamous TRAVERSE function has been revamped significantly,
-with many bugs squashed.
+The infamous TRAVERSE function has been revamped completely
+between ASDF 1 and ASDF 2, with many bugs squashed.
In particular, dependencies were not correctly propagated
-across submodules within a system but now are.
-The :version and :feature features and
+across modules but now are.
+It has been completely rewritten many times over
+between ASDF 2.000 and ASDF 3,
+with fundamental issues in the original model being fixed.
+Timestamps were not propagated at all, and now are.
+The internal model of how actions depend on each other
+is now both consistent and complete.
+The :version and
the :force (system1 .. systemN) feature have been fixed.
@item
@item
Support was lacking for some implementations.
ABCL and GCL were notably wholly broken.
-ECL extensions were not integrated in the ASDF release.
+ECL extensions were not integrated with ASDF release.
@item
The documentation was grossly out of date.
With ASDF 2, we provide a new stable set of working features
that everyone can rely on from now on.
Use @code{#+asdf2} to detect presence of ASDF 2,
-@code{(asdf:version-satisfies (asdf:asdf-version) "2.000")}
+@code{(asdf:version-satisfies (asdf:asdf-version) "2.345.67")}
to check the availability of a version no earlier than required.
When an old version of ASDF was loaded,
it was very hard to upgrade ASDF in your current image
without breaking everything.
-Instead you have to exit the Lisp process and
+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,
towards the latest version for everyone.
-@subsection Pitfalls of ASDF 2
+@subsection Pitfalls of the transition to ASDF 2
The main pitfalls in upgrading to ASDF 2 seem to be related
to the output translation mechanism.
@xref{FAQ,,``How can I wholly disable the compiler output cache?''}.
@item
-Some systems in the large have been known not to play well with output translations.
+Some systems in the large have been known
+not to play well with output translations.
They were relatively easy to fix.
Once again, it is also easy to disable output translations,
or to override its configuration.
The new ASDF output translations are incompatible with ASDF-Binary-Locations.
They replace A-B-L, and there is compatibility mode to emulate
your previous A-B-L configuration.
-See @code{asdf:enable-asdf-binary-locations-compatibility} in
+See @code{enable-asdf-binary-locations-compatibility} in
@pxref{Controlling where ASDF saves compiled files,,Backward Compatibility}.
-But thou shall not load ABL on top of ASDF 2.
+But thou shalt not load ABL on top of ASDF 2.
+
+@end itemize
+
+Other issues include the following:
+
+@itemize
@item
-ASDF pathname designators are now specified in places where they were unspecified,
+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} argument to a @code{defsystem} and its components,
+Notably, in the @code{:pathname} argument
+to a @code{defsystem} and its components,
a logical pathname (or implementation-dependent hierarchical pathname)
must now be specified with @code{#p} syntax
where the namestring might have previously sufficed;
moreover when evaluation is desired @code{#.} must be used,
-where it wasn't necessary in the toplevel @code{:pathname} argument.
-
-@end itemize
-
-Other issues include the following:
-
-@itemize
+where it wasn't necessary in the toplevel @code{:pathname} argument
+(but necessary in other @code{:pathname} arguments).
@item
There is a slight performance bug, notably on SBCL,
or shallow @code{:tree} entries.
Or you can fix your implementation to not be quite that slow
when recursing through directories.
+@emph{Update}: This performance bug fixed the hard way in 2.010.
@item
On Windows, only LispWorks supports proper default configuration pathnames
based on the Windows registry.
-Other implementations make do.
-Windows support is largely untested, so please help report and fix bugs.
+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.
+@emph{Update}: As of ASDF 2.21, all implementations
+should now use the same proper default configuration pathnames
+and they should actually work, though they haven't all been tested.
+
+@item
+The mechanism by which one customizes a system so that Lisp files
+may use a different extension from the default @file{.lisp} 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")}.
+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")))}
+and use @code{:default-component-class cl-source-file.lis}
+as argument to @code{defsystem},
+as detailed in a @pxref{FAQ,How do I create a system definition where all the source files have a .cl extension?} below.
+
+@findex source-file-type
+
@end itemize
@subsection ``I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?''
-Starting with current candidate releases of ASDF 2,
+Since ASDF 2,
it should always be a good time to upgrade to a recent version of ASDF.
You may consult with the maintainer for which specific version they recommend,
-but the latest RELEASE should be correct.
-We trust you to thoroughly test it with your implementation before you release it.
+but the latest @code{release} should be correct.
+We trust you to thoroughly test it with your implementation
+before you release it.
If there are any issues with the current release,
it's a bug that you should report upstream and that we will fix ASAP.
@itemize
@item
-If ASDF isn't installed yet, then @code{(require :asdf)}
+If ASDF isn't loaded yet, then @code{(require "asdf")}
should load the version of ASDF that is bundled with your system.
+If possible so should @code{(require "ASDF")}.
You may have it load some other version configured by the user,
if you allow such configuration.
@item
If your system provides a mechanism to hook into @code{CL:REQUIRE},
then it would be nice to add ASDF to this hook the same way that
-ABCL, CCL, CMUCL, ECL and SBCL do it.
+ABCL, CCL, CLISP, CMUCL, ECL, SBCL and SCL do it.
+Please send us appropriate code to this end.
@item
You may, like SBCL, have ASDF be implicitly used to require systems
and precompile it in your binary distribution,
but @file{asdf.asd} if included at all,
should be secluded from the magic systems,
-in a separate file hierarchy,
-or you may otherwise rename the system and its file to e.g.
+in a separate file hierarchy.
+Alternatively, you may provide the system
+after renaming it and its @file{.asd} file to e.g.
@code{asdf-ecl} and @file{asdf-ecl.asd}, or
@code{sb-asdf} and @file{sb-asdf.asd}.
Indeed, if you made @file{asdf.asd} a magic system,
@item
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},
+then you may add them to the @code{wrapping-source-registry},
and you are welcome to include @file{asdf.asd} amongst them.
+Non-magic systems should be at the back of the @code{wrapping-source-registry}
+while magic systems are at the front.
@item
Please send us upstream any patches you make to ASDF itself,
or as a name component plus optional dot-separated type component
(if the component class doesn't specifies a pathname type).
+@subsection How do I create a system definition where all the source files have a .cl extension?
+
+Starting with ASDF 2.014.14, you may just pass
+the builtin class @code{cl-source-file.cl} as
+the @code{:default-component-class} argument to @code{defsystem}:
+
+@lisp
+(defsystem my-cl-system
+ :default-component-class cl-source-file.cl
+ ...)
+@end lisp
+
+Another builtin class @code{cl-source-file.lsp} is offered
+for files ending in @file{.lsp}.
+
+If you want to use a different extension
+for which ASDF doesn't provide builtin support,
+or want to support versions of ASDF
+earlier than 2.014.14 (but later than 2.000),
+you can define a class as follows:
+
+@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")))
+@end lisp
+
+Then you can use it as follows:
+@lisp
+(defsystem my-cl-system
+ :default-component-class my-asdf-extension:cl-source-file.lis
+ ...)
+@end lisp
+
+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}.
+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:
+
+@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
+ ...)
+@end lisp
+
+It is possible to achieve the same effect
+in a way that supports both ASDF 1 and ASDF 2,
+but really, friends don't let friends use ASDF 1.
+Please upgrade to ASDF 3.
+In short, though: do same as above, but
+@emph{before} you use the class in a @code{defsystem},
+you also define the following method:
+
+@lisp
+(defmethod source-file-type ((f cl-source-file.lis) (s system))
+ (declare (ignorable f s))
+ "lis")
+@end lisp
+
+@comment FIXME: Add a FAQ about how to use a new system class...
+
@node TODO list, Inspiration, FAQ, Top
@comment node-name, next, previous, up
Reinstate @code{parse-option} or something akin.
-** document all the error classes
-
-** what to do with compile-file failure
-
-Should check the primary return value from compile-file and see if
-that gets us any closer to a sensible error handling strategy
-
-** foreign files
-
-lift unix-dso stuff from db-sockets
-
** Diagnostics
A ``dry run'' of an operation can be made with the following form:
@lisp
-(traverse (make-instance '<operation-name>)
- (find-system <system-name>)
- 'explain)
+(let ((asdf::*verbose-out* *standard-output*))
+ (loop :for (op . comp) :in
+ (asdf::traverse (make-instance '<operation-name> :force t)
+ (asdf:find-system <system-name>))
+ :do (asdf:explain op comp)))
@end lisp
This uses unexported symbols.
** reuse the same scratch package whenever a system is reloaded from disk
-** proclamations probably aren't
-
-** when a system is reloaded with fewer components than it previously had, odd things happen
-
-We should do something inventive when processing a @code{defsystem} form,
-like take the list of kids and @code{setf} the slot to @code{nil},
-then transfer children from old to new list as they're found.
+Have a package ASDF-USER instead of all these temporary packages?
-** (stuff that might happen later)
-
-*** Propagation of the @code{:force} option.
-
-``I notice that
-
- @code{(asdf:compile-system :araneida :force t)}
-
-also forces compilation of every other system the @code{:araneida} system depends on.
-This is rarely useful to me;
-usually, when I want to force recompilation of something more than a single source file,
-I want to recompile only one system.
-So it would be more useful to have @code{make-sub-operation}
-refuse to propagate @code{:force t} to other systems, and
-propagate only something like @code{:force :recursively}.
-
-Ideally what we actually want is some kind of criterion that says
-to which systems (and which operations) a @code{:force} switch will propagate.
-
-The problem is perhaps that ``force'' is a pretty meaningless concept.
-How obvious is it that @code{load :force t} should force @emph{compilation}?
-But we don't really have the right dependency setup
-for the user to compile @code{:force t} and expect it to work
-(files will not be loaded after compilation, so the compile
-environment for subsequent files will be emptier than it needs to be)
+** proclamations probably aren't
-What does the user actually want to do when he forces?
-Usually, for me, update for use with a new version of the Lisp compiler.
-Perhaps for recovery when he suspects that something has gone wrong.
-Or else when he's changed compilation options or configuration
-in some way that's not reflected in the dependency graph.
+** A revert function
Other possible interface: have a ``revert'' function akin to @code{make clean}.
The defsystem 4 proposal tends to look more at the external features,
whereas this one centres on a protocol for system introspection.
-@section kmp's ``The Description of Large Systems'', MIT AI Memu 801
+@section kmp's ``The Description of Large Systems'', MIT AI Memo 801
Available in updated-for-CL form on the web at
@url{http://nhplace.com/kent/Papers/Large-Systems.html}
projects / sbcl.git / blobdiff