The defsystem grammar - asdf Manual
Description: asdf Manual

Previous: A more involved example, Up: Defining systems with defsystem

### 2.3 The defsystem grammar

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

    option := :components component-list
            | :pathname pathname
            | :default-component-class
            | :perform method-form
            | :explain method-form
    	| :output-files  method-form
            | :operation-done-p method-form
            | :depends-on ( {simple-component-name}* )
    	| :serial [ t | nil ]
            | :in-order-to ( {dependency}+ )

    component-list := ( {component-def}* )

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

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

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

#### 2.3.1 Serial dependencies

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

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

is equivalent to

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

#### 2.3.2 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:

- The host/device/directory parts of `*load-truename*`, if it is bound
- `*default-pathname-defaults*`, otherwise

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

- changed, if explicitly supplied or obtained from `*load-truename*` (so that an updated source location is reflected in the system definition)
- changed if it had previously been set from `*default-pathname-defaults*`
- left as before, if it had previously been set from `*load-truename*` and `*load-truename*` is currently unbound (so that a developer can evaluate a `defsystem` form from within an editor without clobbering its source location)