Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
Hugo Ishimaru
asdf
Commits
58968bce
Commit
58968bce
authored
Nov 22, 2016
by
Robert Goldman
Browse files
Merge branch 'documentation-tweaks' into 'master'
Documentation tweaks See merge request !54
parents
73583e56
9b47bc18
Changes
2
Hide whitespace changes
Inline
Side-by-side
doc/asdf.texinfo
View file @
58968bce
...
...
@@ -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
string
s
or symbol
s 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
symbol
s
that
designate a subcomponent of a system.
@var
{
initargs
}
for
operation
s 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.
S
ome 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 s
ome 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
...
...
doc/index.html
View file @
58968bce
...
...
@@ -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
i
t
s ow
n 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
n
ow
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"
>
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment