The defsystem form - asdf Manual
Description: asdf Manual

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

### 2.1 The defsystem form

Systems can be constructed programmatically by instantiating components using make-instance. Most of the time, however, it is much more practical to use a static `defsystem` form. This section begins with an example of a system definition, then gives the full grammar of `defsystem`.

Let's look at a simple system. This is a complete file that would usually be saved as `hello-lisp.asd`:

         (defpackage hello-lisp-system
           (:use :common-lisp :asdf))

         (in-package :hello-lisp-system)

         (defsystem "hello-lisp"
             :description "hello-lisp: a sample Lisp system."
             :version "0.2"
             :author "Joe User <joe@example.com>"
             :licence "Public Domain"
             :components ((:file "packages")
                          (:file "macros" :depends-on ("packages"))
                          (:file "hello" :depends-on ("macros"))))

Some notes about this example:

- The file starts with `defpackage` and `in-package` forms to make and use a package expressly for defining this system in. This package is named by taking the system name and suffixing `-system` - note that it is not the same package as you will use for the application code.

  This is not absolutely required by asdf, but helps avoid namespace pollution and so is considered good form.

- The defsystem form defines a system named "hello-lisp" that contains three source files: `packages`, `macros` and `hello`.
- The file `macros` depends on `packages` (presumably because the package it's in is defined in `packages`), and the file `hello` depends on `macros` (and hence, transitively on `packages`). This means that asdf will compile and load `packages` and `macros` before starting the compilation of file `hello`.
- The files are located in the same directory as the file with the system definition. asdf resolves symbolic links before loading the system definition file and stores its location in the resulting system1. This is a good thing because the user can move the system sources without having to edit the system definition.

#### Footnotes

[1] It is possible, though almost never necessary, to override this behaviour.