Consider an example system,
demo
, defined as follows:
(defsystem demo (:package "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 into the
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: