Newer
Older
This operation will load the source for the files in a module
even if the source files have been compiled.
Systems sometimes have knotty dependencies
which require that sources are loaded
before they can be compiled.
This is how you do that.
If you are creating a component type,
you need to implement this operation --- at least, where meaningful.
@deffn Operation @code{test-op}
This operation will perform some tests on the module.
The default method will do nothing.
The default dependency is to require
@code{load-op} to be performed on the module first.
The default @code{operation-done-p} is that the operation is @emph{never} done
---
we assume that if you invoke the @code{test-op},
you want to test the system, even if you have already done so.
The results of this operation are not defined by ASDF.
It has proven difficult to define how the test operation
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.
@c @deffn Operation test-system-version &key minimum
@c Asks the system whether it satisfies a version requirement.
@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.
@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 (or (not (cdr y)) (bigger (cdr x) (cdr y))))))
@c @end lisp
@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
@c @deffn Operation feature-dependent-op
@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.
@c @end deffn
@node Creating new operations, , Predefined operations of ASDF, Operations
@comment node-name, next, previous, up
@subsection Creating new operations
ASDF was designed to be extensible in an object-oriented fashion.
To teach ASDF new tricks, a programmer can implement the behaviour he wants
by creating a subclass of @code{operation}.
ASDF's pre-defined operations are in no way ``privileged'',
but it is requested that developers never use the @code{asdf} package
for operations they develop themselves.
The rationale for this rule is that we don't want to establish a
``global asdf operation name registry'',
but also want to avoid name clashes.
An operation must provide methods for the following generic functions
when invoked with an object of type @code{source-file}:
@emph{FIXME describe this better}
@itemize
@item @code{output-files}
@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
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
@comment node-name, next, previous, up
@section Components
@cindex component
@cindex system
@cindex system designator
@vindex *system-definition-search-functions*
A @dfn{component} represents a source file or
(recursively) a collection of components.
A @dfn{system} is (roughly speaking) a top-level component
that can be found via @code{find-system}.
A @dfn{system designator} is a string or symbol
and behaves just like any other component name
(including with regard to the case conversion rules for component names).
@defun find-system system-designator &optional (error-p t)
Given a system designator, @code{find-system} finds and returns a system.
If no system is found, an error of type
@code{missing-component} is thrown,
or @code{nil} is returned if @code{error-p} is false.
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:
@item
there is no system of that name in memory
@item
the file's @code{last-modified} time exceeds the @code{last-modified} time
of the system in memory
When system definitions are loaded from @file{.asd} files,
a new scratch package is created for them to load into,
so that different systems do not overwrite each others operations.
The user may also wish to (and is recommended to)
include @code{defpackage} and @code{in-package} forms
in his system definition files, however,
so that they can be loaded manually if need be.
The default value of @code{*system-definition-search-functions*}
is a list of two functions.
The first function looks in each of the directories given
by evaluating members of @code{*central-registry*}
for a file whose name is the name of the system and whose type is @file{asd}.
The first such file is returned,
whether or not it turns out to actually define the appropriate system.
The second function does something similar,
for the directories specified in the @code{source-registry}.
Hence, it is strongly advised to define a system
@var{foo} in the corresponding file @var{foo.asd}.
@end defun
@menu
* Common attributes of components::
* Pre-defined subclasses of component::
* Creating new component types::
@end menu
@node Common attributes of components, Pre-defined subclasses of component, Components, Components
@comment node-name, next, previous, up
@subsection Common attributes of components
All components, regardless of type, have the following attributes.
All attributes except @code{name} are optional.
@subsubsection Name
A component name is a string or a symbol.
If a symbol, its name is taken and lowercased.
Unless overridden by a @code{:pathname} attribute,
the name will be interpreted as a pathname specifier according
to a Unix-style syntax. @xref{The defsystem grammar,,Pathname specifiers}.
@subsubsection Version identifier
This optional attribute is used by the 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,
for example @samp{1.0.11}.
@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 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 asdf-devel mailing list if you are interested
in getting this features feature fixed.}
Traditionally defsystem users have used 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*}.
@subsubsection Dependencies
This attribute specifies dependencies of the component on its siblings.
It is optional but often necessary.
There is an excitingly complicated relationship between the initarg
and the method that you use to ask about dependencies
Dependencies are between (operation component) pairs.
In your initargs for the component, you can say
@lisp
:in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))
(load-op (load-op "foo")))
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
@end lisp
This means the following things:
@itemize
@item
before performing compile-op on this component, we must perform
load-op on @var{a} and @var{b}, and compile-op on @var{c},
@item
before performing @code{load-op}, we have to load @var{foo}
@end itemize
The syntax is approximately
@verbatim
(this-op {(other-op required-components)}+)
required-components := component-name
| (required-components required-components)
component-name := string
| (:version string minimum-version-object)
@end verbatim
Side note:
This is on a par with what ACL defsystem does.
mk-defsystem is less general: it has an implied dependency
@verbatim
for all x, (load x) depends on (compile x)
@end verbatim
and using a @code{:depends-on} argument to say that @var{b} depends on
@var{a} @emph{actually} means that
@verbatim
@end verbatim
This is insufficient for e.g. the McCLIM system, which requires that
all the files are loaded before any of them can be compiled ]
End side note
In ASDF, the dependency information for a given component and operation
can be queried using @code{(component-depends-on operation component)},
which returns a list
@lisp
((load-op "a") (load-op "b") (compile-op "c") ...)
@end lisp
@code{component-depends-on} can be subclassed for more specific
component/operation types: these need to @code{(call-next-method)}
and append the answer to their dependency, unless
they have a good reason for completely overriding the default dependencies.
combination to do this transparently.
But, we need to support CLISP.
If you have the time for some CLISP hacking,
I'm sure they'd welcome your fixes.
@c Doesn't CLISP now support LIST method combination?
@subsubsection pathname
This attribute is optional and if absent (which is the usual case),
the component name will be used.
@xref{The defsystem grammar,,Pathname specifiers}, for an explanation of how this attribute
is interpreted.
Note that the @code{defsystem} macro (used to create a ``top-level'' system)
does additional processing to set the filesystem location of
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))))
@end lisp
@subsubsection properties
This attribute is optional.
Packaging systems often require information about files or systems
in addition to that specified by ASDF's pre-defined component attributes.
Programs that create vendor packages out of ASDF systems therefore
have to create ``placeholder'' information to satisfy these systems.
Sometimes the creator of an ASDF system may know the additional
information and wish to provide it directly.
@code{(component-property component property-name)} and
associated @code{setf} method will allow
the programmatic update of this information.
Property names are compared as if by @code{EQL},
so use symbols or keywords or something.
* Pre-defined subclasses of component::
* Creating new component types::
@end menu
@node Pre-defined subclasses of component, Creating new component types, Common attributes of components, Components
@comment node-name, next, previous, up
@subsection Pre-defined subclasses of component
@deffn Component source-file
A source file is any file that the system does not know how to
generate from other components of the system.
Note that this is not necessarily the same thing as
``a file containing data that is typically fed to a compiler''.
If a file is generated by some pre-processor stage
(e.g. a @file{.h} file from @file{.h.in} by autoconf)
then it is not, by this definition, a source file.
Conversely, we might have a graphic file
that cannot be automatically regenerated,
or a proprietary shared library that we received as a binary:
these do count as source files for our purposes.
Subclasses of source-file exist for various languages.
@emph{FIXME: describe these.}
@end deffn
@deffn Component module
A module is a collection of sub-components.
A module component has the following extra initargs:
@itemize
@item
@code{:components} the components contained in this module
@item
@code{:default-component-class}
All children components which don't specify their class explicitly
are inferred to be of this type.
@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
@emph{FIXME: such conditional compilation has been reported
to be broken in 2009.}
@code{:serial} When this attribute is set,
each subcomponent of this component is assumed to depend on all subcomponents
before it in the list given to @code{:components}, i.e.
all of them are loaded before a compile or load operation is performed on it.
The default operation knows how to traverse a module, so
most operations will not need to provide methods specialised on modules.
@code{module} may be subclassed to represent components such as
foreign-language linked libraries or archive files.
@end deffn
@deffn Component system
@code{system} is a subclass of @code{module}.
A system is a module with a few extra attributes for documentation
purposes; these are given elsewhere.
@xref{The defsystem grammar}.
Users can create new classes for their systems:
the default @code{defsystem} macro takes a @code{:classs} keyword argument.
@end deffn
@node Creating new component types, , Pre-defined subclasses of component, Components
@comment node-name, next, previous, up
@subsection Creating new component types
New component types are defined by subclassing one of the existing
component classes and specializing methods on the new component class.
@emph{FIXME: this should perhaps be explained more throughly,
not only by example ...}
As an example, suppose we have some implementation-dependent
functionality that we want to isolate
in one subdirectory per Lisp implementation our system supports.
We create a subclass of
@code{cl-source-file}:
@lisp
(defclass unportable-cl-source-file (cl-source-file)
())
@end lisp
A hypothetical function @code{system-dependent-dirname}
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}.
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
@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)))
@end lisp
The new component type is used in a @code{defsystem} form in this way:
@lisp
(defsystem :foo
:components
((:file "packages")
...
(:unportable-cl-source-file "threads"
:depends-on ("packages" ...))
...
)
@end lisp
@node Controlling where ASDF saves compiled files, Error handling, The object model of ASDF, Top
Robert P. Goldman
committed
@comment node-name, next, previous, up
@chapter Controlling where ASDF saves compiled files
@cindex asdf-output-translations
Robert P. Goldman
committed
Each Common Lisp implementation has its own format
for compiled files (fasls for short).
If you use multiple implementations
(or multiple versions of the same implementation),
you'll soon find your source directories
Robert P. Goldman
committed
littered with various `DFSL`s, `FASL`s, `CFSL`s and so on.
Worse yet, some implementations use the same file extension
or change formats from version to version which means that
you'll have to recompile binaries as you switch from one
Robert P. Goldman
committed
implementation to the next.
Robert P. Goldman
committed
As of version 1.600, ASDF includes @code{asdf-output-translations}
to mitigate the problem.
Robert P. Goldman
committed
@section Default locations
@findex output-files-for-system-and-operation
The default binary location for each Lisp implementation
is a subdirectory of each source directory.
To account for different Lisps, Operating Systems, Implementation versions,
and so on, ASDF borrows code from SLIME
to create reasonable custom directory names.
Here are some examples:
Robert P. Goldman
committed
@itemize
@item
SBCL, version 1.0 on Mac OS X for intel: @code{sbcl-1.0-darwin-x86}
Robert P. Goldman
committed
@item
Franz Allegro, version 8.0, ANSI Common Lisp: @code{allegro-8.0a-macosx-x86}
Robert P. Goldman
committed
@item
Franz Allegro, version 8.1, Modern (case sensitive) Common Lisp: @code{allegro-8.1m-macosx-x86}
Robert P. Goldman
committed
@end itemize
Robert P. Goldman
committed
By default, all output file pathnames will be relocated
to some thus-named subdirectory of @file{~/.cache/common-lisp/}.
See the document @file{README.asdf-output-translations}
for a full specification on how to configure @code{asdf-output-translations}.
Robert P. Goldman
committed
@node Error handling, Compilation error and warning handling, Controlling where ASDF saves compiled files, Top
@comment node-name, next, previous, up
@chapter Error handling
@findex SYSTEM-DEFINITION-ERROR
@findex OPERATION-ERROR
It is an error to define a system incorrectly:
an implementation may detect this and signal a generalised instance of
@code{SYSTEM-DEFINITION-ERROR}.
Operations may go wrong (for example when source files contain errors).
These are signalled using generalised instances of
@code{OPERATION-ERROR}.
@node Compilation error and warning handling, Miscellaneous additional functionality, Error handling, Top
@comment node-name, next, previous, up
@chapter Compilation error and warning handling
@vindex *compile-file-warnings-behaviour*
@vindex *compile-file-errors-behavior*
ASDF checks for warnings and errors when a file is compiled.
The variables @var{*compile-file-warnings-behaviour*} and
@var{*compile-file-errors-behavior*}
control the handling of any such events.
The valid values for these variables are
@code{:error}, @code{:warn}, and @code{:ignore}.
@node Miscellaneous additional functionality, Getting the latest version, Compilation error and warning handling, Top
@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:
@enumerate
@item
@code{system-relative-pathname}
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
@lisp
> (asdf:system-relative-pathname 'cl-ppcre "regex.data")
#P"/repository/other/cl-ppcre/regex.data"
@end lisp
@end enumerate
@node Getting the latest version, FAQ, Miscellaneous additional functionality, Top
@comment node-name, next, previous, up
@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.
You may get the ASDF source repository using git:
@kbd{git clone http://common-lisp.net/project/asdf/asdf.git}
You will find the above referenced tags in this repository.
Discussion of ASDF development is conducted on the mailing list
@kbd{asdf-devel@@common-lisp.net}.
@node FAQ, TODO list, Getting the latest version, Top
@comment node-name, next, previous, up
@chapter FAQ
@itemize
@item ``My Common Lisp implementation comes with an outdated version of ASDF. What to do?''
More up-to-date versions of ASDF are distributed with an @file{asdf.asd} file,
and @emph{should} load cleanly on top of older versions.
So you should be able to load this definition file
(or add its pathname to your @code{asdf:*central-registry*} variable),
and then do:
@example
(asdf:oos 'asdf:load-op :asdf)
@end example
If this does not work, it is a bug, and you should report it
(@pxref{FAQ, report-bugs, Where do I report a bug}).
@item ``How can I cater for unit-testing in my system?''
ASDF provides a predefined test operation, @code{test-op}.
@xref{Predefined operations of ASDF, test-op}.
The test operation, however, is largely left to the system definer to specify.
@code{test-op} has been
a topic of considerable discussion on the asdf-devel mailing list, and
on the launchpad bug-tracker.
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
Here are some guidelines:
@itemize
@item
For a given system, @var{foo}, you will want to define a corresponding
test system, such as @var{foo-test}. The reason that you will want this
separate system is that ASDF does not out of the box supply components
that are conditionally loaded. So if you want to have source files
(with the test definitions) that will not be loaded except when testing,
they should be put elsewhere.
@item
The @var{foo-test} system can be defined in an asd file of its own or
together with @var{foo}. An aesthetic preference against cluttering up
the filesystem with extra asd files should be balanced against the
question of whether one might want to directly load @var{foo-test}.
Typically one would not want to do this except in early stages of
debugging.
@item
Record that testing is implemented by @var{foo-test}. For example:
@example
(defsystem @var{foo}
:in-order-to ((test-op (test-op @var{foo-test})))
....)
(defsystem @var{foo-test}
:depends-on (@var{foo} @var{my-test-library} ...)
....)
@end example
@end itemize
This procedure will allow you to support users who do not wish to
install your test framework.
One oddity of ASDF is that @code{operate} (@pxref{Operations,operate})
does not return a value. So in current versions of ASDF there is no
reliable programmatic means of determining whether or not a set of tests
has passed, or which tests have failed. The user must simply read the
console output. This limitation has been the subject of much
discussion.
item ``How can I cater for documentation generation in my system?''
The ASDF developers are currently working to add a @code{doc-op} to the
set of predefined ASDF operations (@pxref{Predefined operations of
ASDF}). See also @url{https://bugs.launchpad.net/asdf/+bug/479470}.
@item ``How can I customize where fasl files are stored?''
@xref{Controlling where ASDF saves compiled files}.
Note that in the past there was an add-on to ASDF called
ASDF-binary-locations, developed by Gary King. That add-on has been
merged into ASDF proper.
Note that use of asdf-binary-locations can interfere with one aspect of
your systems --- if your system uses @code{*load-truename*} to find
files (e.g., if you have some data files stored with your program), then
the relocation that this ASDF customization performs is likely to
interfere.
@item ``How can I maintain non-Lisp (e.g. C) source files?''
@item Where do I report a bug?
ASDF bugs are tracked on launchpad: @url{https://launchpad.net/asdf}.
@item ``I want to put my module's files at the top level. How do I do this?''
By default, the files contained in an asdf module go
in a subdirectory with the same name as the module.
However, this can be overridden by adding a @code{:pathname} argument
to the module description.
For example, here is how it is done
in the spatial-trees ASDF system definition:
@example
(asdf:defsystem :spatial-trees
:components
((:module base
:pathname ""
:components
((:file "package")
(:file "basedefs" :depends-on ("package"))
(:file "rectangles" :depends-on ("package"))))
(:module tree-impls
:depends-on (base)
:pathname ""
:components
((:file "r-trees")
(:file "greene-trees" :depends-on ("r-trees"))
(:file "rstar-trees" :depends-on ("r-trees"))
(:file "rplus-trees" :depends-on ("r-trees"))
(:file "x-trees" :depends-on ("r-trees" "rstar-trees"))))
(:module viz
:depends-on (base)
:pathname ""
((:static-file "spatial-tree-viz.lisp")))
:pathname ""
((:static-file "spatial-tree-test.lisp")))
(:static-file "LICENCE")
(:static-file "TODO")))
@end example
Francois-Rene Rideau
committed
All of the files in the @code{tree-impls} module are at the top level,
instead of in a @code{tree-impls/} subdirectory.
Note that the argument to @code{:pathname} can be either a pathname object or a string.
A pathname object can be constructed with the @code{#p"foo/bar/"} syntax,
Francois-Rene Rideau
committed
but this is discouraged because the results of parsing a namestring are not portable.
A pathname can only be portably constructed with such syntax as
@code{#.(make-pathname :directory '(:relative "foo" "bar"))},
and similarly the current directory can only be portably specified as
Francois-Rene Rideau
committed
@code{#.(make-pathname :directory '(:relative))}.
However, as of ASDF 1.624, you can portably use a string to denote a pathname.
The string will be parsed as a @code{/}-separated path from the current directory,
such that the empty string @code{""} denotes the current directory, and
@code{"foo/bar"} (no trailing @code{/} required in the case of modules)
portably denotes the same subdirectory as above.
Francois-Rene Rideau
committed
When files are specified, the last @code{/}-separated component is interpreted
either as the name component of a pathname
(if the component class specifies a pathname type),
or as a name component plus optional dot-separated type component
(if the component class doesn't specifies a pathname type).
@end itemize
@node TODO list, missing bits in implementation, FAQ, Top
comment node-name, next, previous, up
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
@chapter TODO list
* Outstanding spec questions, things to add
** packaging systems
*** manual page component?
** style guide for .asd files
You should either use keywords or be careful with the package that you
evaluate defsystem forms in. Otherwise (defsystem partition ...)
being read in the cl-user package will intern a cl-user:partition
symbol, which will then collide with the partition:partition symbol.
Actually there's a hairier packages problem to think about too.
in-order-to is not a keyword: if you read defsystem forms in a package
that doesn't use ASDF, odd things might happen
** extending defsystem with new options
You might not want to write a whole parser, but just to add options to
the existing syntax. Reinstate 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)
@end lisp
This uses unexported symbols. What would be a nice interface for this
functionality?
@node missing bits in implementation, Inspiration, TODO list, Top
@comment node-name, next, previous, up
@chapter missing bits in implementation
** all of the above
** reuse the same scratch package whenever a system is reloaded from disk
** rules for system pathname defaulting are not yet implemented properly
** 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 defsystem form,
like take the list of kids and setf the slot to nil, then transfer
children from old to new list as they're found
** traverse may become a normal function
If you're defining methods on traverse, speak up.
** a lot of load-op methods can be rewritten to use input-files
so should be.
** (stuff that might happen later)
*** david lichteblau's patch for symlink resolution?
*** Propagation of the :force option. ``I notice that
(oos 'compile-op :araneida :force t)
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
also forces compilation of every other system the :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
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)
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.
Other possible interface: have a 'revert' function akin to 'make clean'
@lisp
(asdf:revert 'asdf:compile-op 'araneida)
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
@end lisp
would delete any files produced by 'compile-op 'araneida. Of course, it
wouldn't be able to do much about stuff in the image itself.
How would this work?
traverse
There's a difference between a module's dependencies (peers) and its
components (children). Perhaps there's a similar difference in
operations? For example, @code{(load "use") depends-on (load "macros")} is a
peer, whereas @code{(load "use") depends-on (compile "use")} is more of a
`subservient' relationship.
@node Inspiration, Concept Index, missing bits in implementation, Top
@comment node-name, next, previous, up
@chapter Inspiration
@section mk-defsystem (defsystem-3.x)
We aim to solve basically the same problems as mk-defsystem does.
However, our architecture for extensibility better exploits CL
language features (and is documented), and we intend to be portable
rather than just widely-ported. No slight on the mk-defsystem authors
and maintainers is intended here; that implementation has the
unenviable task of supporting pre-ANSI implementations, which is
The surface defsystem syntax of asdf is more-or-less compatible with
mk-defsystem, except that we do not support the @code{source-foo} and
@code{binary-foo} prefixes for separating source and binary files, and
we advise the removal of all options to specify pathnames.
The mk-defsystem code for topologically sorting a module's dependency
list was very useful.
@section defsystem-4 proposal
Marco and Peter's proposal for defsystem 4 served as the driver for
many of the features in here. Notable differences are:
@itemize
@item
We don't specify output files or output file extensions as part of the
If you want to find out what files an operation would create, ask the
operation.
@item
We don't deal with CL packages
If you want to compile in a particular package, use an in-package form
in that file (ilisp / SLIME will like you more if you do this anyway)
@item
There is no proposal here that defsystem does version control.
A system has a given version which can be used to check dependencies,
but that's all.
@end itemize
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
Available in updated-for-CL form on the web at
@url{http://nhplace.com/kent/Papers/Large-Systems.html}
In our implementation we borrow kmp's overall PROCESS-OPTIONS and
concept to deal with creating component trees from defsystem surface
syntax. [ this is not true right now, though it used to be and
probably will be again soon ]
@c -------------------
@node Concept Index, Function and Class Index, Inspiration, Top
@unnumbered Concept Index
@printindex cp
@node Function and Class Index, Variable Index, Concept Index, Top
@unnumbered Function and Class Index
@printindex fn
@node Variable Index, , Function and Class Index, Top
@unnumbered Variable Index
@printindex vr
@bye