Next: , Previous: , Up: Defining systems with defsystem   [Contents][Index]


5.3 The defsystem grammar

system-definition := ( defsystem system-designator system-option* )

system-option := :defsystem-depends-on system-list
                 | module-option
                 | option

module-option := :components component-list
                 | :serial [ t | nil ]
                 | :if-component-dep-fails component-dep-fail-option

option :=
        | :pathname pathname-specifier
        | :default-component-class class-name
        | :perform method-form
        | :explain method-form
        | :output-files method-form
        | :operation-done-p method-form
        | :depends-on ( dependency-def* )
        | :in-order-to ( dependency+ )


system-list := ( simple-component-name* )

component-list := ( component-def* )

component-def  := ( component-type simple-component-name option* )

component-type := :system | :module | :file | :static-file | other-component-type

other-component-type := symbol-by-name (see Component types)

dependency-def := simple-component-name
               | ( :feature name )
               | ( :version simple-component-name version-specifier)

dependency := (dependent-op requirement+)
requirement := (required-op required-component+)
             | (feature feature-name)
dependent-op := operation-name
required-op := operation-name | feature

simple-component-name := string
                      |  symbol

pathname-specifier := pathname | string | symbol

method-form := (operation-name qual lambda-list &rest body)
qual := method qualifier

component-dep-fail-option := :fail | :try-next | :ignore

5.3.1 Component names

Component names (simple-component-name) may be either strings or symbols.

5.3.2 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 the current package my-system-asd can be specified as :my-component-type, or my-component-type.

5.3.3 Defsystem depends on

The :defsystem-depends-on option to defsystem allows the programmer to specify another ASDF-defined system or set of systems that 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.

5.3.4 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, which is the usual case, the component name itself is used.

If a string is given, which is the usual case, the string will be interpreted as a Unix-style pathname where / characters will be interpreted as directory separators. Usually, Unix-style relative pathnames are used (i.e. not starting with /, as opposed to absolute pathnames); they are relative to the path of the parent component. Finally, depending on the component-type, the pathname may be interpreted as either a file or a directory, and if it’s a file, a file type may be added corresponding to the component-type, or else it will be extracted from the string itself (if applicable).

For instance, the component-type :module wants a directory pathname, and so a string "foo/bar" will be interpreted as the pathname #p"foo/bar/". On the other hand, the component-type :file wants a file of type lisp, and so a string "foo/bar" will be interpreted as the pathname #p"foo/bar.lisp", and a string "foo/bar.quux" will be interpreted as the pathname #p"foo/bar.quux.lisp". Finally, the component-type :static-file wants a file without specifying a type, and so a string "foo/bar" will be interpreted as the pathname #p"foo/bar", and a string "foo/bar.quux" will be interpreted as the pathname #p"foo/bar.quux".

ASDF does not interpret the string ".." to designate the parent directory. This string will be passed through to the underlying operating system for interpretation. We believe that this will work on all platforms where ASDF is deployed, but do not guarantee this behavior. A pathname object with a relative directory component of :up or :back is the only guaranteed way to specify a parent directory.

If a symbol is given, it will be translated into a string, 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) 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.

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 ...). Note however, that #p... is a shorthand for #.(parse-namestring ...) and that the behavior of parse-namestring is completely non-portable, unless you are using Common Lisp logical-pathnames (see Warning about logical pathnames, below). 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 the component-type default file type for a given component. Therefore, pathname objects should only rarely be used. Unhappily, ASDF 1 didn’t properly support parsing component names as strings specifying paths with directories, and the cumbersome #.(make-pathname ...) syntax had to be used.

Note that when specifying pathname objects, ASDF does not do any special interpretation of the pathname influenced by the component type, unlike the procedure for pathname-specifying strings. On the one hand, you have to be careful to provide a pathname that correctly fulfills whatever constraints are required from that component type (e.g. naming a directory or a file with appropriate type); on the other hand, you can circumvent the file type that would otherwise be forced upon you if you were specifying a string.

5.3.5 Warning about logical pathnames

We recommend that you not use logical pathnames in your asdf system definitions at this point, but logical pathnames are supported.

To use logical pathnames, you will have to provide a pathname object as a :pathname specifier to components that use it, using such syntax as #p"LOGICAL-HOST:absolute;path;to;component.lisp".

You only have to specify such logical pathname for your system or some top-level component. Sub-components’ relative pathnames, specified using the string syntax for names, will be properly merged with the pathnames of their parents. The specification of a logical pathname host however is not otherwise directly supported in the ASDF syntax for pathname specifiers as strings.

The asdf-output-translation layer will avoid trying to resolve and translate logical-pathnames. The advantage of this is that you can define yourself what translations you want to use with the logical pathname facility. The disadvantage is that if you do not define such translations, any system that uses logical pathnames will behave differently under asdf-output-translations than other systems you use.

If you wish to use logical pathnames you will have to configure the translations yourself before they may be used. ASDF currently provides no specific support for defining logical pathname translations.

5.3.6 Serial dependencies

If the :serial t option is specified for a module, ASDF will add dependencies for each child component, on all the children textually preceding it. This is done as if by :depends-on.

:serial t
:components ((:file "a") (:file "b") (:file "c"))

is equivalent to

:components ((:file "a")
             (:file "b" :depends-on ("a"))
             (:file "c" :depends-on ("a" "b")))

5.3.7 Source location

The :pathname option is optional in all cases for systems defined via defsystem, and in the usual case the user is recommended not to supply it.

Instead, ASDF follows a hairy set of rules that are designed so that

  1. find-system will load a system from disk and have its pathname default to the right place.
  2. This pathname information will not be overwritten with *default-pathname-defaults* (which could be somewhere else altogether) if the user loads up the .asd file into his editor and interactively re-evaluates that form.

If a system is being loaded for the first time, its top-level pathname will be set to:

If a system is being redefined, the top-level pathname will be

5.3.8 if-component-dep-fails option

This option is only appropriate for module components (including systems), not individual source files.

For more information about this option, see Pre-defined subclasses of component.


Next: , Previous: , Up: Defining systems with defsystem   [Contents][Index]