diff --git a/src/contrib/asdf/asdf.lisp b/src/contrib/asdf/asdf.lisp
index 19067bec00a8def6e3dbf105756f871c4ffc7c62..f5f73eb7fa6a979c57f7fe21fe67af54ce6a9cd8 100644
--- a/src/contrib/asdf/asdf.lisp
+++ b/src/contrib/asdf/asdf.lisp
@@ -1,5 +1,5 @@
;;; -*- mode: Lisp; Base: 10 ; Syntax: ANSI-Common-Lisp ; buffer-read-only: t; -*-
-;;; This is ASDF 3.3.2: Another System Definition Facility.
+;;; This is ASDF 3.3.3: Another System Definition Facility.
;;;
;;; Feedback, bug reports, and patches are all welcome:
;;; please mail to Manual for Version 3.3.2
+ Manual for Version 3.3.3
This manual describes ASDF, a system definition facility
@@ -286,11 +290,11 @@ for Common Lisp programs and libraries.
You can find the latest version of this manual at
https://common-lisp.net/project/asdf/asdf.html.
ASDF Copyright © 2001-2016 Daniel Barlow and contributors.
+ ASDF Copyright © 2001-2019 Daniel Barlow and contributors.
This manual Copyright © 2001-2016 Daniel Barlow and contributors.
+ This manual Copyright © 2001-2019 Daniel Barlow and contributors.
This manual revised © 2009-2016 Robert P. Goldman and Francois-Rene Rideau.
+ This manual revised © 2009-2019 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
@@ -328,7 +332,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- ASDF is Another System Definition Facility:
+ ASDF, or Another System Definition Facility, is a build system:
a tool for specifying how systems of Common Lisp software
are made up of components (sub-systems and files),
and how to operate on these components in the right order
@@ -355,8 +359,8 @@ it plays a role like Note that the canonical name of a system is a string, conventionally lowercase.
-A system name can also be specified as a symbol (including a keyword),
-in which case its Note that the canonical name of a system is a string, in lowercase.
+System names can also be specified as symbols (including keyword
+symbols).
+If a symbol is given as argument, its package is ignored,
+its The lower-casing-symbols behaviour is unconventional,
+ Using lowercase as canonical is unconventional,
but was selected after some consideration.
-The type of systems we want to support
+The type of file systems we support
either have lowercase as customary case (Unix, Mac, Windows)
or silently convert lowercase to uppercase (lpns).
-
:pathname
)simple-component-name
):pathname
)ASDF: Another System Definition Facility
-make
or ant
, not like a package m
In particular, ASDF should not to be confused with Quicklisp or ASDF-Install,
that attempt to find and download ASDF systems for you.
Despite what the name might suggest,
-ASDF-Install was never a part of ASDF, it was a separate piece of software.
-ASDF-Install is also unmaintained and obsolete.
+ASDF-Install was never a part of ASDF; it was always a separate piece of software.
+ASDF-Install has also been unmaintained and obsolete for a very long time.
We recommend you use Quicklisp
(http://www.quicklisp.org/) instead,
a Common Lisp package manager which works well and is being actively maintained.
@@ -862,15 +866,17 @@ ASDF hooks into the cl:require
facility and you can just use:
(require :foo)
-symbol-name
is taken and lowercased.
+symbol-name
is taken, and converted to lowercase.
The name must be a suitable value for the :name
initarg
to make-pathname
in whatever filesystem the system is to be found.
Apply operate
with the operation from
-*load-system-operation*
-the system, and any provided keyword arguments.
-*load-system-operation*
by default is load-op
;
-it would be load-bundle-op
by default on ECL,
-if only an implementation bug were fixed.
-Calling load-system
is the regular, recommended way
-to load a system into the current image.
+
Apply operate
with the operation load-op
, the
+system, and any provided keyword arguments. Calling
+load-system
is the regular, recommended way to load a system
+into the current image.
load-system
;
but system authors can override this default in their system definition
they may specify an alternate operation as the intended use of their system,
with a :build-operation
option in the defsystem
form
-(see build-operation),
+(see Build-operation),
and an intended output pathname for that operation with
:build-pathname
.
This function is experimental and largely untested. Use at your own risk.
@@ -1078,7 +1079,7 @@ especially if you intend your software to be eventually included in Quicklisp.
:version
numbers will be parsed!
Only period-separated non-negative integers are accepted at present.
-See below Version specifiers in The defsystem grammar.
+See Version specifiers.
defsystem
declaration.
No in-package
form, no asdf:
package prefix, no nothing.
@@ -1152,7 +1153,7 @@ in the same directory, or in a different subdirectory;
see the discussion of the :pathname
option in The defsystem grammar).
:serial t
says that each sub-component of mod
depends on the previous components,
-so that cooker.lisp depends-on utils.lisp, which depends-on reader.lisp.
+so that cooker.lisp depends-on reader.lisp, which depends-on utils.lisp.
Also data.raw depends on all of them, but that doesn’t matter since it’s a static file;
on the other hand, if it appeared first, then all the Lisp files would be recompiled
when the data is modified, which is probably not what is desired in this case.
@@ -1270,11 +1271,19 @@ Presumably, the 4th form looks like (defparameter *foo-version* "5.6.
-system-definition := ( defsystem system-designator system-option* )
+system-definition := ( defsystem system-designator system-option*)
+
+system-designator := simple-component-name | complex-component-name
+
+simple-component-name := lower-case string | symbol
+ NOTE: Underscores are not permitted. See below.
+
+complex-component-name := string | symbol
+ See below.
system-option := :defsystem-depends-on system-list
| :weakly-depends-on system-list
- | :class class-name (see discussion below)
+ | :class class-name # see System class names
| :build-operation operation-name
| system-option
| module-option
@@ -1287,6 +1296,7 @@ system-option := :homepage string
| :long-name string
| :source-control source-control
| :version version-specifier
+ | :entry-point object # see Entry point
source-control := (keyword string)
@@ -1314,13 +1324,13 @@ component-def := ( component-type simple-component-name option* )
component-type := :module | :file | :static-file | other-component-type
other-component-type := symbol-by-name
- (see Component types)
+ # see Component types
# This is used in :depends-on, as opposed to ``dependency,''
# which is used in :in-order-to
dependency-def := simple-component-name
| ( :feature feature-expression dependency-def )
- # (see Feature dependencies)
+ # see Feature dependencies
| ( :version simple-component-name version-specifier )
| ( :require module-name )
@@ -1335,6 +1345,10 @@ simple-component-name := string
| symbol
pathname-specifier := pathname | string | symbol
+ NOTE: pathnames should be all lower case, and have no
+ underscores, although hyphens are permitted.
+
+
version-specifier := string
| (:read-file-form <pathname-specifier> <form-specifier>?)
@@ -1343,7 +1357,8 @@ line-specifier := :at integer # base zero
form-specifier := :at [ integer | ( integer+ )]
method-form := (operation-name qual lambda-list &rest body)
-qual := method qualifier?
+qual := method-qualifier?
+method-qualifier = :before | :after | :around
feature-expression := keyword
| (:and feature-expression*)
@@ -1351,16 +1366,57 @@ feature-expression := keyword
| (:not feature-expression)
+
+6.3.1 System designators
-
-6.3.1 Component names
+System designators are either simple component names, or
+complex (“slashy”) component names.
+
+
+6.3.2 Simple component names (simple-component-name
)
-Component names (simple-component-name
)
-may be either strings or symbols.
+
Simple component names may be written as either strings or symbols.
-
-6.3.2 Component types
+When using strings, use lower case exclusively.
+
+Symbols will be interpreted as convenient shorthand for the string
+that is their symbol-name
, converted to lower case. Put
+differently, a symbol may be a simple component name designator,
+but the simple component name itself is the string.
+
+Never use underscores in component names, whether written as
+strings or symbols.
+
+Never use slashes (“/”) in simple component names. A slash
+indicates a complex component name; see below. Using a slash
+improperly will cause ASDF to issue a warning.
+
+Violating these constraints by mixing case, or including underscores in
+component names, may lead to systems or components being impossible to
+find, because component names are interpreted as file names. These
+problems will definitely occur for users who have configured ASDF
+using logical pathnames.
+
+
+6.3.3 Complex component names
+A complex component name is a master name followed by a slash, followed
+by a subsidiary name. This allows programmers to put multiple system
+definitions in a single .asd
file, while still allowing ASDF to
+find these systems.
+
+The master name of a complex system must be the same as the
+name of the .asd
file.
+
+The file foo.asd
will contain the definition of the system
+"foo"
. However, it may also contain definitions of
+subsidiary systems, such as "foo/test"
, "foo/docs"
, and so
+forth. ASDF will “know” that if you ask it to load system
+"foo/test"
it should look for that system’s definition in foo.asd
.
+
+
+6.3.4 Component types
+
Component type names, even if expressed as keywords, will be looked up
by name in the current package and in the asdf package, if not found in
the current package. So a component type my-component-type
, in
@@ -1370,9 +1426,9 @@ the current package my-system-asd
can be specified as
system
and its subclasses are not
allowed as component types for such children components.
+
+6.3.5 System class names
-6.3.3 System class names
-
A system class name will be looked up
in the same way as a Component type (see above),
except that only system
and its subclasses are allowed.
@@ -1393,7 +1449,7 @@ extension loaded by :defsystem-depends-on
, causing a name
conflict in the current package.
-6.3.4 Defsystem depends on
+6.3.6 Defsystem depends on
The :defsystem-depends-on
option to defsystem
allows the
@@ -1402,10 +1458,10 @@ must be loaded before the system definition is processed.
Typically this is used to load an ASDF extension that is used in the
system definition.
-
-6.3.5 Build-operation
+
+6.3.7 Build-operation
-
+
The :build-operation
option to defsystem
allows the
programmer to specify an operation that will be applied, in place of
load-op
when make
(see make)
@@ -1416,7 +1472,7 @@ value should be the name of an operation. E.g., :build-operation doc-op
experimental and largely untested. Use at your own risk.
-6.3.6 Weakly depends on
+6.3.8 Weakly depends on
We do NOT recommend you use this feature.
@@ -1445,10 +1501,10 @@ this anomalous behaviour may be removed without warning.
-
-6.3.7 Pathname specifiers
+
+6.3.9 Pathname specifiers
-
+
A pathname specifier (pathname-specifier
)
may be a pathname, a string or a symbol.
When no pathname specifier is given for a component,
@@ -1488,13 +1544,17 @@ which when merged, goes back one level in the directory hierarchy.
and downcased in the process.
The downcasing of symbols is unconventional,
but was selected after some consideration.
-Observations suggest that the type of systems we want to support
-either have lowercase as customary case (Unix, Mac, windows)
+The file systems we 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 :case :common
as argument to make-pathname
,
which is reported not to work on some implementations.
+Please avoid using underscores in system names, or component (module or
+file) names, since underscores are not
+compatible with logical pathnames (see Using logical pathnames).
+
Pathname objects may be given to override the path for a component.
Such objects are typically specified using reader macros such as #p
or #.(make-pathname ...)
.
@@ -1503,7 +1563,7 @@ a shorthand for #.(parse-namestring ...)
and that the behaviour of parse-namestring
is completely non-portable,
unless you are using Common Lisp logical-pathname
s,
which themselves involve other non-portable behaviour
-(see Using logical pathnames, below).
+(see Using logical pathnames).
Pathnames made with #.(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
@@ -1525,11 +1585,11 @@ fulfills whatever constraints are required from that component type
on the other hand, you can circumvent the file type that would otherwise
be forced upon you if you were specifying a string.
-
-6.3.8 Version specifiers
+
+6.3.10 Version specifiers
-
+
Version specifiers are strings to be parsed as period-separated lists of integers.
I.e., in the example, "0.2.1"
is to be interpreted,
roughly speaking, as (0 2 1)
.
@@ -1543,9 +1603,8 @@ had the version strings been interpreted as decimal fractions.
the :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
-(:read-file-form <pathname-or-string> [:at <access-at-specifier]>)
,
-or (:read-file-line <pathname-or-string> [:at
-<access-at-specifier]?>)
.
+(:read-file-form <pathname-or-string> [:at <access-at-specifier>])
,
+or (:read-file-line <pathname-or-string> [:at <access-at-specifier>])
.
As the name suggests, the former 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), and the latter by reading a line.
@@ -1566,20 +1625,20 @@ where significant API incompatibilities are signaled by an increased major numbe
See Common attributes of components.
-6.3.9 Require
+6.3.11 Require
Use the implementation’s own require
to load the module-name.
-It is good taste to use :if-feature :implementation-name
-rather than #+implementation-name
+
It is good taste to use (:feature :implementation-name (:require module-name))
+rather than #+implementation-name (:require module-name)
to only depend on the specified module on the specific implementation that provides it.
-See if-feature-option.
+See Feature dependencies.
-
-6.3.10 Feature dependencies
+
+6.3.12 Feature dependencies
-
+
A feature dependency is of the form
(:feature feature-expression dependency)
If the feature-expression is satisfied by the running lisp at the
@@ -1594,13 +1653,13 @@ definition to be loaded. E.g., one cannot use (:feature :sbcl)
to require that a system only be used on SBCL.
Feature dependencies are not to be confused with the obsolete
-feature requirement (see feature requirement), or
+feature requirement (see feature requirement), or
with if-feature
.
-
-6.3.11 Using logical pathnames
+
+6.3.13 Using 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,
@@ -1654,7 +1713,7 @@ underscores, dots or CamelCase in pathnames.
-6.3.12 Serial dependencies
+6.3.14 Serial dependencies
If the :serial t
option is specified for a module,
@@ -1677,7 +1736,7 @@ This is done as if by :depends-on
.
-
6.3.13 Source location (:pathname
)
+6.3.15 Source location (:pathname
)
The :pathname
option is optional in all cases for systems
defined via defsystem
, and generally is unnecessary. In the
@@ -1722,10 +1781,10 @@ and *load-truename*
is currently unbound
from within an editor without clobbering its source location)
This option allows you to specify a feature expression to be evaluated
as if by #+
to conditionally include a component in your build.
If the expression is false, the component is dropped
@@ -1748,10 +1807,17 @@ been performed.
This option was added in ASDF 3. For more information, See Required features.
- -This requirement was removed in ASDF 3.1. Please do not use it. In
-most cases, :if-feature
(see if-feature-option) will provide
+
+
The :entry-point
option allows a developer to specify the entry point of an executable program created by program-op
.
+
When program-op
is invoked, the form passed to this option is converted to a function by uiop:ensure-function
and bound to uiop:*image-entry-point*
. Typically one will specify a string, e.g. "foo:main"
, so that the executable starts with the foo:main
function. Note that using the symbol foo:main
instead might not work because the foo
package doesn’t necessarily exist when ASDF reads the defsystem
form. For more information on program-op
, see Predefined operations of ASDF.
+
This requirement was removed in ASDF 3.1. Please do not use it. In
+most cases, :if-feature
(see if-feature option) will provide
an adequate substitute.
The feature
requirement used to ensure that a chain of component
@@ -1794,14 +1860,19 @@ of output from ASDF operations.
Starting with release 3.1.2,
ASDF supports a one-package-per-file style of programming,
-whereby each file is its own system,
+in which each file is its own system,
and dependencies are deduced from the defpackage
form
-(or its variant uiop:define-package
).
+or its variant, uiop:define-package
.
In this style, packages refer to a system with the same name (downcased); +
In this style of system definition, package names map to systems with
+the same name (in lower case letters),
and if a system is defined with :class package-inferred-system
,
then system names that start with that name
(using the slash /
separator)
@@ -1810,23 +1881,26 @@ For instance, if system my-lib
is defined in
/foo/bar/my-lib/my-lib.asd, then system my-lib/src/utility
will be found in file /foo/bar/my-lib/src/utility.lisp.
This style was made popular by faslpath
and quick-build
before,
-and at the cost of a stricter package discipline,
-seems to make for more maintainable code.
-It is used by ASDF itself (starting with ASDF 3), by lisp-interface-library
,
+
One package per file style was made popular by faslpath
and quick-build
,
+and at the cost of stricter package discipline,
+may yield more maintainable code.
+This style is used in ASDF itself (starting with ASDF 3), by lisp-interface-library
,
and a few other libraries.
To use this style, choose a toplevel system name, e.g. my-lib
,
-and create a file my-lib.asd
-with the :class :package-inferred-system
option in its defsystem
.
+and create a file my-lib.asd.
+Define my-lib
+using the :class :package-inferred-system
option in its defsystem
.
For instance:
#-asdf3.1 (error "my-lib requires ASDF 3.1") +;; This example is based on lil.asd of LISP-INTERFACE-LIBRARY. + +#-asdf3.1 (error "MY-LIB requires ASDF 3.1 or later.") (defsystem "my-lib" :class :package-inferred-system :depends-on ("my-lib/interface/all" - "my-lib/src/all" - "my-lib/extras/all") + "my-lib/src/all" + "my-lib/extras/all") :in-order-to ((test-op (load-op "my-lib/test/all"))) :perform (test-op (o c) (symbol-call :my-lib/test/all :test-suite))) @@ -1838,43 +1912,83 @@ For instance: (register-system-packages "closer-mop" - '(:c2mop :closer-common-lisp :c2cl :closer-common-lisp-user :c2cl-user)) + '(:c2mop + :closer-common-lisp + :c2cl + :closer-common-lisp-user + :c2cl-user))
In the code above, the first line checks that we are using ASDF 3.1,
-which provides package-inferred-system
.
-
The function register-system-packages
has to be called to register
-packages used or provided by your system and its components
-where the name of the system that provides the package
-is not the downcase of the package name.
-
Then, file interface/order.lisp under the lil
hierarchy,
-that defines abstract interfaces for order comparisons,
-starts with the following form,
-dependencies being trivially computed from the :use
and :mix
clauses:
+
In the code above, the first form checks that we are using ASDF 3.1 or
+later, which provides package-inferred-system
. This is probably
+no longer necessary, since none of the major lisp implementations
+provides an older version of ASDF.
+
The function register-system-packages
must be called to register
+packages used or provided by your system
+when the name of the system/file that provides the package
+is not the same as the package name (converted to lower case).
+
Each file under the my-lib
hierarchy will start with a
+package definition.
+
+
+The form uiop:define-package
is supported as well as
+defpackage
.
+ASDF will compute dependencies from the
+:use
, :mix
, and other importation clauses of this package definition. Take the file
+interface/order.lisp as an example:
(uiop:define-package :lil/interface/order +(uiop:define-package :my-lib/interface/order (:use :closer-common-lisp - :lil/interface/definition - :lil/interface/base - :lil/interface/eq :lil/interface/group) + :my-lib/interface/definition + :my-lib/interface/base) (:mix :fare-utils :uiop :alexandria) (:export ...))
ASDF can tell that this file depends on system closer-mop
(registered above),
-lil/interface/definition
, lil/interface/base
,
-lil/interface/eq
, and lil/interface/group
-(package and system names match, and they will be looked up hierarchically).
+
ASDF can tell that this file/system depends on system closer-mop
(registered above),
+my-lib/interface/definition
, and my-lib/interface/base
.
+
How can ASDF find the file interface/order.lisp from the
+toplevel system my-lib
, however? In the example above,
+interface/all.lisp (and other all.lisp) reexport
+all the symbols exported from the packages at the same or lower levels
+of the hierarchy. This can be easily done with
+uiop:define-package
, which has many options that prove useful in this
+context. For example:
+
(uiop:define-package :my-lib/interface/all + (:nicknames :my-lib-interface) + (:use :closer-common-lisp) + (:mix :fare-utils :uiop :alexandria) + (:use-reexport + :my-lib/interface/definition + :my-lib/interface/base + :my-lib/interface/order + :my-lib/interface/monad/continuation)) +
Thus the top level system need only depend on the my-lib/.../all
systems
+because ASDF detects
+interface/order.lisp and all other dependencies from all
+systems’ :use-reexport
clauses, which effectively
+allow for “inheritance” of symbols being exported.
ASDF also detects dependencies from :import-from
clauses.
-You may thus import a well-defined set of symbols from an existing package
-as loaded from suitably named system;
-or if you prefer to use any such symbol fully qualified by a package prefix,
+You may thus import a well-defined set of symbols from an existing
+package, and ASDF will know to load the system that provides that
+package. In the following example, ASDF will infer that the current
+system depends on foo/baz
from the first :import-from
.
+If you prefer to use any such symbol fully qualified by a package prefix,
you may declare a dependency on such a package and its corresponding system
-via an :import-from
clause with an empty list of symbols, as in:
+via an :import-from
clause with an empty list of symbols. For
+example, if we preferred to use the name ‘foo/quux:bletch‘, the second,
+empty, :import-from
form would cause ASDF to load
+foo/quux
.
(defpackage :foo/bar
@@ -1884,13 +1998,8 @@ via an :import-from
clause with an empty list of symbols, as in:
(:export ...))
The form uiop:define-package
is supported as well as defpackage
,
-and has many options that prove useful in this context,
-such as :use-reexport
and :mix-reexport
-that allow for “inheritance” of symbols being exported.
-
Note that starting with ASDF 3.1.5.6 only, ASDF will look for source files under
-the component-pathname
as specified via the :pathname
option,
+the component-pathname
(specified via the :pathname
option),
whereas earlier versions ignore this option and use the system-source-directory
where the .asd file resides.
Operations are invoked on systems via operate
.
operate
operation component &rest initargs &key force
force-not
verbose
&allow-other-keysoos
operation component &rest initargs &key &allow-other-keysforce
force-not
verbose
&allow-other-keysoperate
invokes operation on system.
oos
is a synonym for operate
(it stands for operate-on-system).
make-operation
operation-class &rest initargsThe initargs are passed to make-instance
call
when creating the operation object.
@@ -2054,7 +2163,7 @@ They are invoked via the operate
generic function.
compile-op
This operation compiles the specified component.
A cl-source-file
will be compile-file
’d.
@@ -2072,7 +2181,7 @@ Use load-op
to load a system.
load-op
This operation loads the compiled code for a specified component.
A cl-source-file
will have its compiled fasl load
ed,
@@ -2086,7 +2195,7 @@ as well as of its parent’s dependencies.
prepare-op
This operation ensures that the dependencies of a component
and its recursive parents are loaded (as per load-op
),
@@ -2095,7 +2204,8 @@ may be performed on a given component.
load-source-op
, prepare-source-op
load-source-op
will load the source for the files in a module
rather than the compiled fasl output.
@@ -2105,7 +2215,7 @@ that ensures the dependencies are themselves loaded via load-source-op
test-op
This operation will perform some tests on the module. The default method will do nothing. @@ -2158,7 +2268,18 @@ on a library. For example, one might have
compile-bundle-op
, monolithic-compile-bundle-op
, load-bundle-op
, monolithic-load-bundle-op
, deliver-asd-op
, monolithic-deliver-asd-op
, lib-op
, monolithic-lib-op
, dll-op
, monolithic-dll-op
, image-op
, program-op
These are “bundle” operations, that can create a single-file “bundle” for all the contents of each system in an application, @@ -2166,12 +2287,12 @@ or for the entire application.
compile-bundle-op
will create a single fasl file for each of the systems needed,
grouping all its many fasls in one,
-so you can deliver each system as a single fasl
+so you can deliver each system as a single fasl.
monolithic-compile-bundle-op
will create a single fasl file for the target system
and all its dependencies,
so you can deliver your entire application as a single fasl.
load-bundle-op
will load the output of compile-bundle-op
.
-Note that if it the output is not up-to-date,
+Note that if the output is not up-to-date,
compile-bundle-op
may load the intermediate fasls as a side-effect.
Bundling fasls together matters a lot on ECL,
where the dynamic linking involved in loading tens of individual fasls
@@ -2227,7 +2348,7 @@ for building a linkable .a file (Windows: .lib)
from all linkable object dependencies (FFI files, and on ECL, Lisp files too),
and its monolithic equivalent monolithic-lib-op
.
And there is also dll-op
-(respectively its monolithic equivalent monolithic-lib-op
)
+(respectively its monolithic equivalent monolithic-dll-op
)
for building a linkable .so file
(Windows: .dll, MacOS X: .dynlib)
to create a single dynamic library
@@ -2250,7 +2371,14 @@ Maybe you have suggestions on how to better configure it?
concatenate-source-op
, monolithic-concatenate-source-op
, load-concatenated-source-op
, compile-concatenated-source-op
, load-compiled-concatenated-source-op
, monolithic-load-concatenated-source-op
, monolithic-compile-concatenated-source-op
, monolithic-load-compiled-concatenated-source-op
These operations, as their respective names indicate,
will concatenate all the cl-source-file
source files in a system
@@ -2619,7 +2747,7 @@ performed by the exported function coerce-name
.
Unless overridden by a :pathname
attribute,
the name will be interpreted as a pathname specifier according
to a Unix-style syntax.
-See Pathname specifiers.
+See Pathname specifiers.
This optional attribute specifies a version for the current component. The version should typically be a string of integers separated by dots, -for example ‘1.0.11’. -For more information on version specifiers, see The defsystem grammar. +for example ‘1.0.11’. See Version specifiers.
A version may then be queried by the generic function version-satisfies
,
to see if :version
dependencies are satisfied,
@@ -2675,7 +2802,7 @@ when the implementation is SBCL, CMUCL or Scieneer CL on an x86 machine.
You cannot write it as :if-feature (and x86 (or sbcl cmu scl))
since the symbols would not be read as keywords.
See if-feature-option. +
See if-feature option.
This attribute is optional and if absent (which is the usual case), the component name will be used.
-See Pathname specifiers, +
See Pathname specifiers, for an explanation of how this attribute is interpreted.
Note that the defsystem
macro (used to create a “top-level” system)
@@ -2857,7 +2984,7 @@ are inferred to be of this type.
:if-component-dep-fails
This attribute was removed in ASDF 3. Do not use it.
-Use :if-feature
instead (see required-features, and see if-feature-option).
+Use :if-feature
instead (see required-features, and see if-feature option).
:serial
When this attribute is set,
each subcomponent of this component is assumed to depend on all subcomponents
@@ -2984,7 +3111,7 @@ Therefore "1.9.1"
, "1.9.2"
and "1.9"
do not.
For more information about how version-satisfies
parses and interprets
version strings and specifications,
-see The defsystem grammar (version specifiers) and
+see Version specifiers and
Common attributes of components.
Note that in versions of ASDF prior to 3.0.1,
@@ -3411,20 +3538,21 @@ if it begins with a paren (
,
otherwise it will be interpreted much like TEXINPUTS
,
as a list of paths, where
* paths are separated
- by a :
(colon) on Unix platforms (including cygwin),
- by a ;
(semicolon) on other platforms (mainly, Windows).
-
* each entry is a directory to add to the search path. -
-* if the entry ends with a double slash //
- then it instead indicates a tree in the subdirectories
- of which to recurse.
-
* if the entry is the empty string (which may only appear once), - then it indicates that the inherited configuration should be - spliced there. -
+:
(colon) on Unix platforms
+ (including cygwin), by a ;
(semicolon) on other platforms
+ (mainly, Windows).
+
+//
then it instead
+ indicates a tree in the subdirectories of which to recurse.
+
+If ASDF detects an incorrect system definition, it will signal a generalised instance of
-SYSTEM-DEFINITION-ERROR
.
+system-definition-error
.
Operations may go wrong (for example when source files contain errors).
These are signalled using generalised instances of
-OPERATION-ERROR
.
+operation-error
.
system-relative-pathname
function meets this need.
and a keyword argument type:
system is name of a system, whereas name and optionally type
specify a relative pathname, interpreted like a component pathname specifier
-by coerce-pathname
. See Pathname specifiers.
+by coerce-pathname
. See Pathname specifiers.
It returns a pathname built from the location of the system’s
source directory and the relative pathname. For example:
@@ -5011,7 +5139,7 @@ where you must now use an explicit pathname object:
must now be written with the #p
syntax:
(defsystem ... :pathname #p"LOGICAL-HOST:PATH;TO;SYSTEM;" ...)
See Pathname specifiers. +
See Pathname specifiers.
asdf-ecl
and its short-lived successor asdf-bundle
are no more,
having been replaced by code now built into ASDF 3.
@@ -5989,7 +6117,30 @@ see the TODO file in the source repository.
defsystem-depends-on
mechanism
+ (and more generally, the ability to call ASDF from within an .asd
file)
+ allows for multiple phases of execution resulting
+ in “dynamic” dependencies with a “suspending” scheduler.
+ The rebuilder essentially uses a “dirty bit”, except that the in-image model
+ and the multiple phase support mean that’s actually more than a bit:
+ instead three bits, the timestamp and a phase depth level.
+ The build is guaranteed “minimal” in number of steps computed.
+ It is local; it assumes but does not enforce determinism;
+ it does not assume early cutoff of the build when rebuild dependencies didn’t change.
+defsystem-3.x
.
Jump to: | B + +C + +D + +F + +I + +L + +M + +O + +P + +S + +T + + |
---|
Index Entry | Section | ||
---|---|---|---|
| |||
B | |||
binary-op (obsolete) : | What happened to the bundle operations | ||
| |||
C | |||
compile-bundle-op : | Predefined operations of ASDF | ||
compile-bundle-op : | What happened to the bundle operations | ||
compile-concatenated-source-op : | Predefined operations of ASDF | ||
compile-op : | Predefined operations of ASDF | ||
component : | The object model of ASDF | ||
concatenate-source-op : | Predefined operations of ASDF | ||
| |||
D | |||
deliver-asd-op : | Predefined operations of ASDF | ||
deliver-asd-op : | What happened to the bundle operations | ||
dll-op : | Predefined operations of ASDF | ||
| |||
F | |||
fasl-op (obsolete) : | What happened to the bundle operations | ||
| |||
I | |||
image-op : | Predefined operations of ASDF | ||
| |||
L | |||
lib-op : | Predefined operations of ASDF | ||
load-bundle-op : | Predefined operations of ASDF | ||
load-bundle-op : | What happened to the bundle operations | ||
load-compiled-concatenated-source-op : | Predefined operations of ASDF | ||
load-concatenated-source-op : | Predefined operations of ASDF | ||
load-fasl-op (obsolete) : | What happened to the bundle operations | ||
load-op : | Predefined operations of ASDF | ||
load-source-op : | Predefined operations of ASDF | ||
| |||
M | |||
module : | Pre-defined subclasses of component | ||
monolithic-binary-op (obsolete) : | What happened to the bundle operations | ||
monolithic-compile-bundle-op : | Predefined operations of ASDF | ||
monolithic-compile-bundle-op : | What happened to the bundle operations | ||
monolithic-compile-concatenated-source-op : | Predefined operations of ASDF | ||
monolithic-concatenate-source-op : | Predefined operations of ASDF | ||
monolithic-deliver-asd-op : | Predefined operations of ASDF | ||
monolithic-deliver-asd-op : | What happened to the bundle operations | ||
monolithic-dll-op : | Predefined operations of ASDF | ||
monolithic-fasl-op (obsolete) : | What happened to the bundle operations | ||
monolithic-lib-op : | Predefined operations of ASDF | ||
monolithic-load-bundle-op : | Predefined operations of ASDF | ||
monolithic-load-bundle-op : | What happened to the bundle operations | ||
monolithic-load-compiled-concatenated-source-op : | Predefined operations of ASDF | ||
monolithic-load-concatenated-source-op : | Predefined operations of ASDF | ||
monolithic-load-fasl-op (obsolete) : | What happened to the bundle operations | ||
| |||
O | |||
operation : | The object model of ASDF | ||
operation-error : | Error handling | ||
| |||
P | |||
prepare-op : | Predefined operations of ASDF | ||
prepare-source-op : | Predefined operations of ASDF | ||
program-op : | Predefined operations of ASDF | ||
| |||
S | |||
source-file : | Pre-defined subclasses of component | ||
system : | Pre-defined subclasses of component | ||
system-definition-error : | Error handling | ||
| |||
T | |||
test-op : | Predefined operations of ASDF | ||
|
Jump to: | B + +C + +D + +F + +I + +L + +M + +O + +P + +S + +T + + |
---|