As of the writing of this manual,
the following implementations provide ASDF 2 this way:
-abcl allegro ccl clisp cmucl ecl lispworks sbcl xcl.
+abcl allegro ccl clisp cmucl ecl lispworks mkcl sbcl xcl.
The following implementation doesn't provide it yet but will in a future release:
scl.
The following implementations are obsolete, not actively maintained,
and most probably will never bundle it:
-cormancl gcl genera mcl.
+cormanlisp gcl genera mcl.
If the implementation you are using doesn't provide ASDF 2,
see @pxref{Loading ASDF,,Loading an otherwise installed ASDF} below.
@end example
On some implementations (namely recent versions of
-ABCL, Clozure CL, CLISP, CMUCL, ECL, SBCL and SCL),
+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:
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 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 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 thunk for calling
-the compile-file function with proper arguments.
+that will be called with a function that
+calls the @code{*compile-op-compile-file-function*} (usually @code{compile-file*})
+with proper arguments;
+the around-compile hook may supply additional arguments
+to pass to that @code{*compile-op-compile-file-function*}.
+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},
+to determine whether
+(NB: The ability to pass such extra flags is only available starting with asdf 2.22.1.)
Note that by using a string, you may reference
a function, symbol and/or package
etc.
Note that there is no around-load hook. This is on purpose.
-Some implementations such as ECL or GCL link object files,
+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.
@section Controlling source file character encoding
-Starting with ASDF 2.21, components accept a @code{:encoding} option.
+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} is the default, and calls
+@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,
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 becomes widespread, hopefully by the end of 2012.
+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),
@code{xcvb-driver:run-program/}
from the @code{xcvb-driver} system that is distributed with XCVB:
@url{http://common-lisp.net/project/xcvb}.
-It's only alternative that supports
+It's the only alternative that supports
as many implementations and operating systems as ASDF does,
and provides well-defined behavior outside Unix (i.e. on Windows).
(The only unsupported exception is Genera, since on it
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.
your previous A-B-L configuration.
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
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.
+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}: performance bug fixed the hard way in 2.010.
+@emph{Update}: This performance bug fixed the hard way in 2.010.
@item
On Windows, only LispWorks supports proper default configuration pathnames
@item
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.