-Defining a System
The DEFSYSTEM macro is used to define a system. Note that it is used only to define the system, not to load it. Other functions are used to manipulate a defined system. The DEFSYSTEM macro has the form:
(defsystem <name>
<options>...)
where the name may be a keyword, a symbol or a string. The DEFSYSTEM macro should be stored in a file inside one of the *CENTRAL-REGISTRY* folders and be named "<name>.system" so that YADS can find it.
| Options The options, which can be written in any order, may be zero or more of the following: |
| • :PACKAGE
followed by a keyword, symbol or string naming the package in which
to load the module. The package must already exist. |
| • :COMPILE-P
followed by NIL or T (the default) controls compilation of this component:
if T it may be compiled and a binary file generated as necessary. If NIL,
the source will be loaded but never compiled. |
| • :SOURCE-DIRECTORY
followed by a keyword, symbol or string naming the directory where the
source files of this system or module may be found. Submodule directories
are named after the module, unless the name is explicitly given, and reside
in their parent module's directory. They thus are nested automatically.
If the directory is given as the empty string, "", no subdirectory
is used. |
| • :BINARY-DIRECTORY
is similar to the :source-directory option, but specifies where the
compiled binaries (fasl or pfsl files) reside. If unspecified and uninherited,
binaries are put in the same directory as the sources. Submodule directories
are named after the module, unless the name is explicitly given, and reside
in their parent module's directory. They thus are nested automatically.
If the directory is given as the empty string, "", no binary subdirectory
is used/created for the submodule. |
| • :SOURCE-EXTENSION
and :BINARY-EXTENSION are used to set the file type extension for
source and binary files, respectively. They default to the values of the
variables *.LISP-PATHNAME* and *.FASL-PATHNAME* respectively, whose values
in MCL are #P".lisp" for sources and #P".pfsl" or #P".fasl"
for compiled files. |
| • :DEPENDS-ON
followed by a list of keywords, symbols or strings naming the systems and
/ or Yads modules that must be loaded before this one. |
| • :REQUIRED
followed by a list of keywords, symbols or strings naming source modules
to REQUIRE before loading this system or Yads module. |
| • :INITIALLY-DO
followed by a Lisp form to execute before loading this component |
| • :COMPONENTS
followed by a list of the components that constitute this Yads module. Each
component may be a file-name string, pathname or keyword naming a specific
file, or, for submodules, it may be a list headed by one of the keywords
:system, :subsystem, :module (the most common) and
:file. See below for more information. |
| • :FINALLY-DO
followed by a Lisp form to execute after this component has been loaded.
|
Note that a single-element list can always be replaced by its element. You can see an example of this in the first example system definition above: the option
:required :quickdraw
could just as well have been written
:required (:quickdraw)
Also note that nothing needs to be quoted.
Nested Components
Components may be nested to any depth. An atomic component will always be interpreted as a file name. Lists are used to specify further options for a component. Such a list should take the one of the following forms
(:system <name> <options>...)
(:subsystem <name> <options>...)
(:module <name> <options>...)
(:file <name> <options>...)
The by far most used one is :MODULE. All the usual options may be used with :SYSTEM, :SUBSYSTEM and :MODULE.:FILE does not accept :PACKAGE, :DEPENDS-ON, :REQUIRED, :INITIALLY-DO, :COMPONENTS or :FINALLY-DO.:SYSTEM also accepts the option :COMPILE-EXTERNAL-P (also accepted by the top-level DEFSYSTEM form). When this option is T, the system may be compiled as necessary by any system mentioning it in its :DEPENDS-ON list. If NIL (the default) it must be explictly updated.
Inheritance of Directories and Extensions
Source and binary directories are (usually) inherited from parent to component, with subdirectories added to the pathname according to the name of the module, unless explicitly changed. This effectively creates a hierarchy of folders.
Thus in the second example above the file "Conditionals.fasl" will be stored in the directory "myapp:binaries;macros;", while "Foo.fasl" will be stored in "myapp:binaries;abstractions;". If the source directory is given as "", no subdirectory will be created and/or used, which effectively puts a component's files in the same directory as its parent component or system. This can be used to create a flat directory structure.
Similarly, file type extensions (".lisp", ".fasl", etc) are (usually) inherited from parent to subcomponent, unless explicitly given.
Inheritance varies according to the component type. This is the main reason there are different component types. Here is a summary of how inheritance works when nothing is explicitly specified using :SOURCE-DIRECTORY, :BINARY-DIRECTORY, :SOURCE-EXTENSION and :BINARY-EXTENSION:
| Module type | Source & Binary Directories | File Type Extensions |
|---|---|---|
| :system | Does not inherit from the system's parent: its directory pathnames are absolute and should be specified explicitly | Does not inherit any file type extensions. They default to the values of the variables *.LISP-PATHNAME* and *.FASL-PATHNAME* respectively |
| :subsystem | Does not inherit from the subsystem's parent: its directory pathnames are absolute and should be specified explicitly | Inherits the file type extensions of its parent |
| :module | Inherits the directory pathnames of its parent, adding the module's name as a relative subdirectory | Inherits the file type extensions of its parent |
| :file | Inherits the directory pathnames of its parent | Inherits the file type extensions of its parent |
back to Defsystem mainpage |