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 system¹. This is a good thing because the user can move the system sources without having to edit the system definition.