26.2 A brief introduction to systems

A system is defined with a defsystem form in an ordinary Lisp source file. This form must be evaluated in the Lisp image in order to use the system.

Once defined, operations can be carried out on the system by invoking Lisp functions.

For example, the expression:

CL-USER 5 > (compile-system 'debug-app :force t)

would compile every file in a system called debug-app.

Note: When defining a hierarchy of systems, the leaf systems must be defined first - that is, a system must be defined before any systems that include it.

By convention, system definitions are placed in a file called defsys.lisp which usually resides in the same directory as the members of the system.

26.2.1 Examples

Consider an example system, demo, defined as follows:

(defsystem demo (:package "CL-USER")
  :members ("macros"
            "demo-utils"
            "demo-functions")
  :rules ((:in-order-to :compile ("demo-utils" "demo-functions")
           (:caused-by (:compile "macros"))
           (:requires (:load "macros")))))

This system compiles and loads members in the CL-USER package if the members themselves do not specify packages. The system contains three members - macros, demo-utils, and demo-functions - which may themselves be either files or other systems. There is only one explicit rule in the example. If macros needs to be compiled (for instance, if it has been changed), then this causes demo-utils and demo-functions to be compiled as well, irrespective of whether they have themselves changed. In order for them to be compiled, macros must first be loaded.

Implicitly, it is always the case that if any member changes, it needs to be compiled when you compile the system. The explicit rule above means that if the changed member happens to be macros, then every member gets compiled. If the changed member is not macros, then macros must at least be loaded before compiling takes place.

The next example shows a system consisting of three files:

(defsystem my-system  
  (:default-pathname "~/junk/")
   :members ("a" "b" "c")
   :rules ((:in-order-to :compile  ("c")
            (:requires (:load "a"))
            (:caused-by (:compile "b")))))

What plan is produced when all three files have already been compiled, but the file b.lisp has since been changed?

First, file a.lisp is considered. This file has already been compiled, so no instructions are added to the plan.

Second, file b.lisp is considered. Since this file has changed, the instruction compile b is added to the plan.

Finally file c.lisp is considered. Although this has already been compiled, the clause:

(:caused-by (:compile "b")) 

causes the instruction compile c to be added to the plan. The compilation of c.lisp also requires that a.lisp is loaded, so the instruction load a is added to the plan first. This gives us the following plan:

1. Compile b.lisp.
2. Load a.lisp.
3. Compile c.lisp.