Skip to content
Snippets Groups Projects
asdf.texinfo 51.4 KiB
Newer Older
* 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 child components which don't
specify their class explicitly are inferred to be of this type.

@item
@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
compiled.

@item
@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.

@end itemize

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}.

@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
@comment  node-name,  next,  previous,  up
@chapter Controlling where ASDF saves compiled files
@cindex ASDF-binary-locations

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
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
implementation to the next.

As of version 1.365, ASDF includes @emph{ASDF-binary-locations} to
mitigate the problem.

@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:

@itemize
@item SBCL, version 1.0 on Mac OS X for intel: @code{sbcl-1.0-darwin-x86}

@item Franz Allegro, version 8.0, ANSI Common Lisp:  @code{allegro-8.0a-macosx-x86}

@item Franz Allegro, version 8.1, Modern (case sensitive) Common Lisp: @code{allegro-8.1m-macosx-x86}
@end itemize

If you want to keep compiled files out of the source tree entirely, use
@code{*centralize-lisp-binaries*} to put compiled files into
sub-directories of a single central location (see below).

Here is a summary of the variables that control ASDF's source-to-binary
mappings.  All of them are in the ASDF package, so must be set
@emph{after} loading ASDF.
@defvar *enable-asdf-binary-locations*
   If false, then ASDF will place binaries in the same directory as the
    source. If true, then ASDF will move the binaries using the rest of
    the configuration. Defaults to @code{nil}.
 @defvar *centralize-lisp-binaries*
 If true, compiled lisp files
    without an explicit mapping (see @code{*source-to-target-mappings*})
    will be placed in subdirectories of
    @code{*default-toplevel-directory*}. If false, then compiled lisp
    files without an explicit mapping will be placed in subdirectories
    of their sources. Defaults to @code{nil}.
 @defvar *default-toplevel-directory*
 If
    @code{*centralize-lisp-binaries*} is true, then compiled lisp files
    without an explicit mapping (see @code{*source-to-target-mappings*})
    will be placed in subdirectories of
    @code{*default-toplevel-directory*}.  Defaults to a sub-directory
    named `.fasls` in the current user's home directory.
 @defvar *include-per-user-information*
 specifies whether or not
    to include user information in the directory. Only used when
    @code{*centralize-lisp-binaries*} is true. Defaults to @code{nil}.
 @defvar *map-all-source-files*
 If true, then all source files
    will be mapped by ASDF. If @code{nil}, then only Common Lisp Source
    Files (i.e., instances of cl-source-file or its subclasses) will
    be. Defaults to @code{nil}.
 @defvar *source-to-target-mappings*
 This specifies mappings
    from source to target. If the target is nil, then it
    means to *not* map the source to anything. I.e., to leave
    it as is. This has the effect of turning off
    ASDF-Binary-Locations for the given source directory. The
    default depends on the Lisp implementation.

These variables are used by
@code{output-files-for-system-and-operation} to determine where to
place a source file's binary. You can further customize asdf-binary-locations
by writing additional methods on the generic function
@code{output-files-for-system-and-operation}.

@c See the [manual][binary-locations] for more details.

@subsection Notes and Issues

SBCL ships with several included ASDF libraries which used to confuse
ABL because it would try to recompile the FASLs and then run into
directory permission problems. ASDF knows about these and uses a mapping
like @file{/usr/local/lib/sbcl} to @code{nil} so that the FASLs are not
relocated.

@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 @code{*compile-file-warnings-behaviour*} and
@code{*compile-file-errors-behavior*} controls 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 Additional Functionality

Robert P. Goldman's avatar
Robert P. Goldman committed
@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
system-relative-pathname 

It's often handy to locate a file relative to some system. The 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, TODO list, Miscellaneous additional functionality, Top
@comment  node-name,  next,  previous,  up
@chapter Getting the latest version

Robert P. Goldman's avatar
Robert P. Goldman committed
@emph{FIXME:  Need to revise this to give information about the git repository.}
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  TODO list, missing bits in implementation, Getting the latest version, Top
@comment  node-name,  next,  previous,  up
@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)

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) 
@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 
no longer necessary.

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
system.  

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://world.std.com/~pitman/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