Commit 9b47bc18 authored by Francois-Rene Rideau's avatar Francois-Rene Rideau Committed by Elias Pipping

Documentation tweaks

parent 73583e56
......@@ -2124,20 +2124,21 @@ Operations are invoked on systems via @code{operate}.
@code{operate} invokes @var{operation} on @var{system}.
@code{oos} is a synonym for @code{operate} (it stands for operate-on-system).
along with the supplied @var{initargs},
to @code{make-operation} (which will call @code{make-instance})
@var{operation} is an operation designator:
it can be an operation object itself, or, typically,
a symbol that is passed to @code{make-operation} (which will call @code{make-instance}),
to create the operation object.
@var{component} is a component designator,
usually a string or symbol that designates a system,
sometimes a list of strings or symbols that designate a subcomponent of a system.
@var{operation} is a symbol that is passed,
@var{component} is a component designator:
it can be a component object itself, or, typically,
a string or symbol (to be @code{string-downcase}d) that names a system,
more rarely a list of strings or symbols that designate a subcomponent of a system.
@var{initargs} for operations are now deprecated, and will be removed.
The ability to pass @var{initargs} to @code{make-operation} is now deprecated, and will be removed.
For more details, @pxref{make-operation}.
Note that dependencies may cause the operation
to invoke other operations on the system or its components:
the new operations will be created
with the same @var{initargs} as the original one.
the new operations may or may not be created
with the same @var{initargs} as the original one (for the moment).
If @var{force} is @code{:all}, then all systems
are forced to be recompiled even if not modified since last compilation.
......@@ -5620,14 +5621,14 @@ and lose configuration as they do.
@code{asdf-ecl} and its short-lived successor @code{asdf-bundle} are no more,
having been replaced by code now built into ASDF 3.
Moreover, the name of the bundle operations has changed since ASDF 3.1.3.
And yet, the feature is not enabled to be used by @code{load-system} by default on ECL as originally intended,
because of a bug in ECL itself found during testing.
Some of the bundle operations were renamed after ASDF 3.1.3, and the old
names have been removed. Old bundle operations, and their modern
equivalents are:
Starting with ASDF 3.2.0, @code{load-system}
will once again use @code{load-bundle-op} instead of @code{load-op} on ECL,
as originally intended by @code{asdf-ecl} authors, but disabled for a long time
due to bugs in both ECL and ASDF.
Note that some of the bundle operations were renamed after ASDF 3.1.3,
and the old names have been removed.
Old bundle operations, and their modern equivalents are:
@itemize
@item
......
......@@ -200,10 +200,10 @@
<h3>Supported Implementations</h3>
<p>
ASDF 3 now supports all CL implementations
that seem to have any current user base, and then some. The one
exception is ECL on Windows, which appears to have bugs that preclude
full functioning of ASDF and UIOP. ASDF will run on Windows ECL, but
we cannot provide support for this platform.
that seem to have any current user base, and then some.
But ASDF does not magically turn broken implementations into working ones,
and some ASDF or UIOP features may not work
on less-maintained implementations that do not support them (see below).
</p><p>
Most implementations provide ASDF as a module,
and you can simply <tt>(require "asdf")</tt>.
......@@ -218,15 +218,37 @@
but some hacking is probably required to make the latest ASDF work well
with the latest release of these implementations:
<ul><li>
CLISP is generally well-tested with ASDF, though it has a few minor bugs.
The implementation has received only minimal maintenance since 2010,
and the last official release ships with an antique version of ASDF;
however ASDF has been recently updated in its source control system,
and there is hope of a new release some day soon.
If needs be, you can replace CLISP's provided ASDF with a newer one,
or use an upgrade on top of that.
</li><li>
CormanLisp was recently open-sourced.
Its bundled ASDF has not yet been updated from 1.x;
ASDF 3.1 should work fine with it, but several features were disabled
because CormanLisp was insufficiently compliant with the CLHS,
and requires some work in this regard.
Ask the new CormanLisp maintainers for updates.
</li><li>
ECL is generally well-tested with ASDF, but
its bytecode compiler doesn't support the bundle operations, and
support for Windows seems to be less stable.
For instance, as of November 2016,
<code>cl:require</code> and <code>ext:system</code> (and thus <code>uiop:run-program</code>)
seem not to be working correctly on Windows.
</li><li>
GCL is somewhat maintained but its maintainer doesn't seem to care about ASDF,
and hasn't replied for years to requests for bug fixes and
and hasn't replied for years to requests for bug fixes or
for providing ASDF via <tt>(require "asdf")</tt>
</li><li>
CormanLisp was recently open-sourced;
its bundled ASDF has not yet been updated from 1.x;
ASDF 3.1 should work fine with it, but a few features were disabled
because CormanLisp is insufficiently compliant with the CLHS,
and requires some work in this regard.
Genera was never open-source and never bundled ASDF,
but should otherwise just work with a recent ASDF 3.1,
if you somehow have a license and a working version.
There are rumors of people doing active development with it
and having minor patches to improve ASDF on it.
</li><li>
MCL similarly was open-sourced, but never bundled ASDF;
ASDF 3.1 should work just fine with it,
......@@ -234,17 +256,18 @@
so a lot of work is required to make something out of it
— at which point, you might just use CCL.
</li><li>
XCL is now an abandoned experiment. It provides some old ASDF 2;
but you can replace it with ASDF 3.1, which works well with it,
inasmuch as anything works at all with XCL.
Mocl has its own heavily modified variant of ASDF2, and
is the only implementation not currently supported by ASDF3.
To make it work with ASDF 3 would require ASDF to be taught about
natively supporting cross-compilation.
</li><li>
Genera and SCL were never open-source and never bundled ASDF,
but should otherwise just work with a recent ASDF 3.1,
SCL was seemingly abandoned and never open-sourced.
It never bundled ASDF, but should otherwise just work with a recent ASDF 3.1,
if you somehow have a license and a working version.
</li><li>
Mocl has its own heavily modified variant of ASDF2, and
to make it work with unmodified ASDF 3.x would require
ASDF to be taught about natively supporting cross-compilation.
XCL is now an abandoned experiment. It provides some old ASDF 2;
but you can replace it with ASDF 3.1, which works well with it,
inasmuch as anything works at all with XCL.
</li></ul>
</p>
<table border="1">
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment