asdf.texinfo 108 KB
Newer Older
1
2
\input texinfo          @c -*- texinfo -*-
@c %**start of header
3
@setfilename asdf.info
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
4
@settitle ASDF Manual
5
6
@c %**end of header

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
@c We use @&key, etc to escape & from TeX in lambda lists --
@c so we need to define them for info as well.
@macro &allow-other-keys
&allow-other-keys
@end macro
@macro &optional
&optional
@end macro
@macro &rest
&rest
@end macro
@macro &key
&key
@end macro
@macro &body
&body
@end macro

25
26
27
@c for install-info
@dircategory Software development
@direntry
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
28
* asdf: (asdf).           Another System Definition Facility (for Common Lisp)
29
30
@end direntry

31
@copying
32
33
This manual describes ASDF, a system definition facility
for Common Lisp programs and libraries.
34

35
ASDF Copyright @copyright{} 2001-2010 Daniel Barlow and contributors.
36

37
38
This manual Copyright @copyright{} 2001-2010 Daniel Barlow and contributors.

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
39
This manual revised @copyright{} 2009-2010 Robert P. Goldman and Francois-Rene Rideau.
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
``Software''), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

@end copying



@titlepage
@title asdf: another system definition facility
66

67
68
69
70
71
@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
72

73
74
75
76
77
78
79
@c Output the table of contents at the beginning.
@contents

@c -------------------

@ifnottex

80
@node Top, Introduction, (dir), (dir)
81
@top asdf: another system definition facility
82

83
84
85
@insertcopying

@menu
86
87
* Introduction::
* Loading ASDF::
88
89
* Configuring ASDF::
* Using ASDF::
90
91
* Defining systems with defsystem::
* The object model of ASDF::
92
* Controlling where ASDF searches for systems::
93
94
95
96
97
* Controlling where ASDF saves compiled files::
* Error handling::
* Miscellaneous additional functionality::
* Getting the latest version::
* FAQ::
98
* TODO list::
99
100
101
102
103
* missing bits in implementation::
* Inspiration::
* Concept Index::
* Function and Class Index::
* Variable Index::
104

105
106
@c @detailmenu
@c  --- The Detailed Node Listing ---
107

108
@c Defining systems with defsystem
109

110
111
112
113
@c * The defsystem form::
@c * A more involved example::
@c * The defsystem grammar::
@c * Other code in .asd files::
114

115
@c The object model of ASDF
116

117
118
@c * Operations::
@c * Components::
119

120
@c Operations
121

122
123
@c * Predefined operations of ASDF::
@c * Creating new operations::
124

125
@c Components
126

127
128
129
@c * Common attributes of components::
@c * Pre-defined subclasses of component::
@c * Creating new component types::
130

131
@c properties
132

133
134
@c * Pre-defined subclasses of component::
@c * Creating new component types::
135

136
@c @end detailmenu
137
138
139
140
141
142
@end menu

@end ifnottex

@c -------------------

143
@node Introduction, Loading ASDF, Top, Top
144
145
@comment  node-name,  next,  previous,  up
@chapter Introduction
Robert P. Goldman's avatar
Robert P. Goldman committed
146
147
148
149
150
151
@cindex ASDF-related features
@vindex *features*
@cindex Testing for ASDF
@cindex ASDF versions
@cindex :asdf
@cindex :asdf2
152

153
154
155
156
157
158
159
160
161
162
ASDF is Another System Definition Facility:
a tool for specifying how systems of Common Lisp software
are comprised of components (sub-systems and files),
and how to operate on these components in the right order
so that they can be compiled, loaded, tested, etc.

ASDF presents three faces:
one for users of Common Lisp software who want to reuse other people's code,
one for writers of Common Lisp software who want to specify how to build their systems,
one for implementers of Common Lisp extensions who want to extend the build system.
Robert P. Goldman's avatar
Robert P. Goldman committed
163
@xref{Using ASDF,,Loading a system},
164
to learn how to use ASDF to load a system.
Robert P. Goldman's avatar
Robert P. Goldman committed
165
@xref{Defining systems with defsystem},
166
to learn how to define a system of your own.
167
@xref{The object model of ASDF}, for a description of
Robert P. Goldman's avatar
Robert P. Goldman committed
168
the ASDF internals and how to extend ASDF.
169

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
170
@emph{Nota Bene}:
171
172
We are preparing for a release of ASDF 2,
which will have version 2.000 and later.
173
174
Current releases, in the 1.600 series and beyond,
should be considered as release candidates.
175
176
We're still working on polishing the code and documentation.
@ref{FAQ,,``What has changed between ASDF 1 and ASDF 2?''}.
177

178

179
@node Loading ASDF, Configuring ASDF, Introduction, Top
180
@comment  node-name,  next,  previous,  up
181
@chapter Loading ASDF
182
@vindex *central-registry*
183
@cindex link farm
184
185
186
187
188
189
@findex load-system
@findex compile-system
@findex test-system
@cindex system directory designator
@findex operate
@findex oos
190

191
@c @menu
192
@c * Installing ASDF::
193
194
195
@c @end menu


196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
@section Loading a pre-installed ASDF

Many Lisp implementations include a copy of ASDF.
You can usually load this copy using Common Lisp's @code{require} function:

@lisp
(require :asdf)
@end lisp

Consult your Lisp implementation's documentation for details.

Hopefully, ASDF 2 will soon be bundled with every Common Lisp implementation,
and you can load it that way.


@section Checking whether ASDF is loaded

To check whether ASDF is properly loaded in your current Lisp image,
you can run this form:

@lisp
(asdf:asdf-version)
@end lisp

If it returns a string,
that is the version of ASDF that is currently installed.

If it raises an error,
then either ASDF is not loaded, or
you are using an old version of ASDF.

You can check whether an old version is loaded
by checking if the ASDF package is present.
The form below will allow you to programmatically determine
whether a recent version is loaded, an old version is loaded,
or none at all:

@lisp
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
234
(and (find-package :asdf) #+asdf2 (asdf:asdf-version) #-asdf2 :old)
235
236
237
238
@end lisp

If it returns a version number, that's the version of ASDF installed.
If it returns the keyword @code{:OLD},
239
then you're using an old version of ASDF (from before 1.635).
240
241
If it returns @code{NIL} then ASDF is not installed.

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
242
If you are running a version older than 1.656,
243
244
245
we recommend that you load a newer ASDF using the method below.


246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
@section Upgrading ASDF

If your implementation does provide ASDF 2 or later,
and you want to upgrade to a more recent version,
just install ASDF like any other package
(see @pxref{Loading ASDF,,Loading an otherwise installed ASDF} below),
configure ASDF as usual (see @pxref{Configuring ASDF} below),
and upgrade with:

@lisp
(require :asdf)
(asdf:load-system :asdf)
@end lisp

If on the other hand, your implementation only provides an old ASDF,
you will require a special configuration step and an old-style loading:

@lisp
(require :asdf)
(push #p"@var{/path/to/new/asdf/}" asdf:*central-registry*)
(asdf:oos 'asdf:load-op :asdf)
@end lisp

Don't forget the trailing @code{/} at the end of your pathname.

Also, note that older versions of ASDF won't redirect their output,
or at least won't do it according to your usual ASDF 2 configuration.
You therefore need write access on the directory
where you install the new ASDF,
and make sure you're not using it
for multiple mutually incompatible implementations.
At worst, you may have to have multiple copies of the new ASDF,
e.g. one per implementation installation, to avoid clashes.

280
281
282
283
284
285
286
287
288
289
Finally, note that there are some limitations to upgrading ASDF:
@itemize
@item
Any ASDF extension is invalidated, and will need to be reloaded.
@item
It is safer if you upgrade ASDF and its extensions as a special step
at the very beginning of whatever script you are running,
before you start using ASDF to load anything else.
@end itemize

290

291
292
293
@section Loading an otherwise installed ASDF

If your implementation doesn't include ASDF,
294
295
if for some reason the upgrade somehow fails,
does not or cannot apply to your case,
296
297
298
299
300
301
you will have to install the file @file{asdf.lisp}
somewhere and load it with:

@lisp
(load "/path/to/your/installed/asdf.lisp")
@end lisp
302

303
The single file @file{asdf.lisp} is all you normally need to use ASDF.
304

305
You can extract this file from latest release tarball on the
306
@url{http://common-lisp.net/project/asdf/,ASDF website}.
307
If you are daring and willing to report bugs, you can get
308
the latest and greatest version of ASDF from its git repository.
309
310
311
312
313
314
315
@xref{Getting the latest version}.

For maximum convenience you might want to have ASDF loaded
whenever you start your Lisp implementation,
for example by loading it from the startup script or dumping a custom core
--- check your Lisp implementation's manual for details.

316

317
318
@node Configuring ASDF, Using ASDF, Loading ASDF, Top
@comment  node-name,  next,  previous,  up
319
320
321
322
323
324
325
326

@chapter Configuring ASDF

@section Configuring ASDF to find your systems

So it may compile and load your systems, ASDF must be configured to find
the @file{.asd} files that contain system definitions.

327
Since ASDF 2, the preferred way to configure where ASDF finds your systems is
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
328
329
330
the @code{source-registry} facility,
fully described in its own chapter of this manual.
@xref{Controlling where ASDF searches for systems}.
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366

The default location for a user to install Common Lisp software is under
@file{~/.local/share/common-lisp/source/}.
If you install software there, you don't need further configuration.
If you're installing software yourself at a location that isn't standard,
you have to tell ASDF where you installed it. See below.
If you're using some tool to install software,
the authors of that tool should already have configured ASDF.

The simplest way to add a path to your search path,
say @file{/foo/bar/baz/quux/}
is to create the directory
@file{~/.config/common-lisp/source-registry.conf.d/}
and there create a file with any name of your choice,
for instance @file{42-bazquux.conf}
containing the line:

@kbd{(:directory "/foo/bar/baz/quux/")}

If you want all the subdirectories under @file{/foo/bar/baz/}
to be recursively scanned for @file{.asd} files, instead use:

@kbd{(:tree "/foo/bar/baz/quux/")}

Note that your Operating System distribution or your system administrator
may already have configured system-managed libraries for you.

Also note that when choosing a filename, the convention is to use
the @file{.conf} extension
(and a non-empty extension is required for CLISP compatibility),
and it is customary to start the filename with two digits
that specify the order in which the directories will be scanned.

ASDF will automatically read your configuration
the first time you try to find a system.
You can reset the source-registry configuration with:
367

368
369
370
371
372
373
374
375
376
377
@lisp
(asdf:clear-source-registry)
@end lisp

And you probably should do so before you dump your Lisp image,
if the configuration may change
between the machine where you save it at the time you save it
and the machine you resume it at the time you resume it.


Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
378
@section Configuring ASDF to find your systems -- old style
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448

The old way to configure ASDF to find your systems is by
@code{push}ing directory pathnames onto the variable
@code{asdf:*central-registry*}.

You must configure this variable between the time you load ASDF
and the time you first try to use it.
Loading and configuring ASDF presumably happen
as part of some initialization script that builds or starts
your Common Lisp software system.
(For instance, some SBCL users used to put it in their @file{~/.sbclrc}.)

The @code{asdf:*central-registry*} is empty by default in ASDF 2,
but is still supported for compatibility with ASDF 1.
When used, it takes precedence over the above source-registry@footnote{
It is possible to further customize
the system definition file search.
That's considered advanced use, and covered later:
search forward for
@code{*system-definition-search-functions*}.
@xref{Defining systems with defsystem}.}.

For instance, if you wanted ASDF to find the @file{.asd} file
@file{/home/me/src/foo/foo.asd} your initialization script
could after it loads ASDF with @code{(require :asdf)}
configure it with:

@lisp
(push "/home/me/src/foo/" asdf:*central-registry*)
@end lisp

Note the trailing slash: when searching for a system,
ASDF will evaluate each entry of the central registry
and coerce the result to a pathname@footnote{
ASDF will indeed call @code{EVAL} on each entry.
It will also skip entries that evaluate to @code{NIL}.

Strings and pathname objects are self-evaluating,
in which case the @code{EVAL} step does nothing;
but you may push arbitrary SEXP onto the central registry,
that will be evaluated to compute e.g. things that depend
on the value of shell variables or the identity of the user.

The variable @code{asdf:*central-registry*} is thus a list of
``system directory designators''.
A @dfn{system directory designator} is a form
which will be evaluated whenever a system is to be found,
and must evaluate to a directory to look in.
By ``directory'' here, we mean
``designator for a pathname with a supplied DIRECTORY component''.
}
at which point the presence of the trailing directory name separator
is necessary to tell Lisp that you're discussing a directory
rather than a file.

Typically, however, there are a lot of @file{.asd} files, and
a common idiom was to have to put
a bunch of @emph{symbolic links} to @file{.asd} files
in a common directory
and push @emph{that} directory (the ``link farm'')
to the
@code{asdf:*central-registry*}
instead of pushing each of the many involved directories
to the @code{asdf:*central-registry*}.
ASDF knows how to follow such @emph{symlinks}
to the actual file location when resolving the paths of system components
(on Windows, you can use Windows shortcuts instead of POSIX symlinks).

For example, if @code{#p"/home/me/cl/systems/"} (note the trailing slash)
is a member of @code{*central-registry*}, you could set up the
449
450
451
452
453
454
455
456
system @var{foo} for loading with asdf with the following
commands at the shell:

@example
$ cd /home/me/cl/systems/
$ ln -s ~/src/foo/foo.asd .
@end example

457
458
459
460
This old style for configuring ASDF is not recommended for new users,
but it is supported for old users, and for users who want to programmatically
control what directories are added to the ASDF search path.

461

462
@section Configuring where ASDF stores object files
463
@findex clear-output-locations
464
465
466
467
468
469
470
471
472
473
474
475

ASDF lets you configure where object files will be stored.
Sensible defaults are provided and
you shouldn't normally have to worry about it.

This allows the same source code repository may be shared
between several versions of several Common Lisp implementations,
between several users using different compilation options
and without write privileges on shared source directories, etc.
This also allows to keep source directories uncluttered
by plenty of object files.

476
Starting with ASDF 2, the @code{asdf-output-translations} facility
477
was added to ASDF itself, that controls where object files will be stored.
478
This facility is fully described in a chapter of this manual,
479
@ref{Controlling where ASDF saves compiled files}.
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508

The simplest way to add a translation to your search path,
say from @file{/foo/bar/baz/quux/}
to @file{/where/i/want/my/fasls/}
is to create the directory
@file{~/.config/common-lisp/asdf-output-translations.conf.d/}
and there create a file with any name of your choice,
for instance @file{42-bazquux.conf}
containing the line:

@kbd{("/foo/bar/baz/quux/" "/where/i/want/my/fasls/")}

To disable output translations for source under a given directory,
say @file{/toto/tata/}
you can create a file @file{40-disable-toto.conf}
with the line:

@kbd{("/toto/tata/")}

To wholly disable output translations for all directories,
you can create a file @file{00-disable.conf}
with the line:

@kbd{(:root :root)}

Note that your Operating System distribution or your system administrator
may already have configured translations for you.
In absence of any configuration, the default is to redirect everything
under an implementation-dependent subdirectory of @file{~/.cache/common-lisp/}.
509
@xref{Controlling where ASDF searches for systems}, for full details.
510

511
512
513
514
515
516
517
518
519
520

Also note that when choosing a filename, the convention is to use
the @file{.conf} extension
(and a non-empty extension is required for CLISP compatibility),
and it is customary to start the filename with two digits
that specify the order in which the directories will be scanned.

ASDF will automatically read your configuration
the first time you try to find a system.
You can reset the source-registry configuration with:
521
522

@lisp
523
(asdf:clear-output-translations)
524
525
@end lisp

526
527
528
529
530
And you probably should do so before you dump your Lisp image,
if the configuration may change
between the machine where you save it at the time you save it
and the machine you resume it at the time you resume it.

531
Finally note that before ASDF 2,
532
533
534
535
536
537
other ASDF add-ons offered the same functionality,
each in subtly different and incompatible ways:
ASDF-Binary-Locations, cl-launch, common-lisp-controller.
ASDF-Binary-Locations is now not needed anymore and should not be used.
cl-launch 3.0 and common-lisp-controller 7.1 have been updated
to just delegate this functionality to ASDF.
538

539
540
@node Using ASDF, Defining systems with defsystem, Configuring ASDF, Top
@comment  node-name,  next,  previous,  up
541

542
543
544
545
546
547
@chapter Using ASDF

@section Loading a system

The system @var{foo} is loaded (and compiled, if necessary)
by evaluating the following Lisp form:
548
549

@example
550
(asdf:load-system :@var{foo})
551
552
@end example

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
553
554
555
556
557
558
559
560
On some implementations (namely, SBCL and Clozure CL),
ASDF hooks into the @code{CL:REQUIRE} facility
and you can just use:

@example
(require :@var{foo})
@end example

561
562
In older versions of ASDF, you needed to use
@code{(asdf:oos 'asdf:load-op :@var{foo})}.
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
563
564
If your ASDF is too old to provide @code{asdf:load-system} though
we recommend that you upgrade to ASDF 2.
565
@xref{Loading ASDF,,Loading an otherwise installed ASDF}.
566

567

568
@section Other Operations
569

570
571
ASDF provides three commands for the most common system operations:
@code{load-system}, @code{compile-system} or @code{test-system}.
572

573
574
575
576
577
578
Because ASDF is an extensible system
for defining @emph{operations} on @emph{components},
it also provides a generic function @code{operate}
(which is usually abbreviated by @code{oos}).
You'll use @code{oos} whenever you want to do something beyond
compiling, loading and testing.
579

580
581
582
583
Output from ASDF and ASDF extensions are supposed to be sent
to the CL stream @code{*standard-output*},
and so rebinding that stream around calls to @code{asdf:operate}
should redirect all output from ASDF operations.
584

585
586
Reminder: before ASDF can operate on a system, however,
it must be able to find and load that system's definition.
587
@xref{Configuring ASDF,,Configuring ASDF to find your systems}.
588
589


590
591
592
593
594
@section Summary

To use ASDF:

@itemize
595
@item
596
597
598
Load ASDF itself into your Lisp image, either through
@code{(require :asdf)} or else through
@code{(load "/path/to/asdf.lisp")}.
599

600
@item
601
602
Make sure ASDF can find system definitions
thanks to proper source-registry configuration.
603

604
@item
605
606
Load a system with @code{(load-system :my-system)}
or use some other operation on some system of your choice.
607
608
609

@end itemize

610
@section Moving on
611

612
613
614
615
616
That's all you need to know to use ASDF to load systems written by others.
The rest of this manual deals with writing system definitions
for Common Lisp software you write yourself,
including how to extend ASDF to define new operation and component types.

617

618
@node Defining systems with defsystem, The object model of ASDF, Using ASDF, Top
619
620
621
622
623
624
625
626
@comment  node-name,  next,  previous,  up
@chapter Defining systems with defsystem

This chapter describes how to use asdf to define systems and develop
software.


@menu
627
628
629
630
* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
631
632
633
634
635
636
@end menu

@node  The defsystem form, A more involved example, Defining systems with defsystem, Defining systems with defsystem
@comment  node-name,  next,  previous,  up
@section The defsystem form

637
638
639
640
641
642
Systems can be constructed programmatically
by instantiating components using @code{make-instance}.
Most of the time, however, it is much more practical to use
a static @code{defsystem} form.
This section begins with an example of a system definition,
then gives the full grammar of @code{defsystem}.
643

644
645
Let's look at a simple system.
This is a complete file that would
646
usually be saved as @file{hello-lisp.asd}:
647
648

@lisp
649
(in-package :asdf)
650

651
(defsystem "hello-lisp"
652
653
654
655
656
657
658
  :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"))))
659
660
661
662
663
@end lisp

Some notes about this example:

@itemize
664
665

@item
666
667
668
669
The file starts with an @code{in-package} form
to use package @code{asdf}.
You could instead start your definition by using
a qualified name @code{asdf:defsystem}.
670

671
@item
672
673
674
675
676
677
678
679
680
681
682
683
684
If in addition to simply using @code{defsystem},
you are going to define functions,
create ASDF extension, globally bind symbols, etc.,
it is recommended that to avoid namespace pollution between systems,
you should create your own package for that purpose,
for instance replacing the above @code{(in-package :asdf)} with:

@lisp
(defpackage :foo-system
  (:use :cl :asdf))

(in-package :foo-system)
@end lisp
685
686

@item
687
688
689
The @code{defsystem} form defines a system named @code{hello-lisp}
that contains three source files:
@file{packages}, @file{macros} and @file{hello}.
690

691
692
693
694
695
696
697
@item
The file @file{macros} depends on @file{packages}
(presumably because the package it's in is defined in @file{packages}),
and the file @file{hello} depends on @file{macros}
(and hence, transitively on @file{packages}).
This means that ASDF will compile and load @file{packages} and @file{macros}
before starting the compilation of file @file{hello}.
698
699

@item
700
701
702
703
704
705
706
707
The files are located in the same directory
as the file with the system definition.
ASDF resolves symbolic links (or Windows shortcuts)
before loading the system definition file and
stores its location in the resulting system@footnote{
It is possible, though almost never necessary, to override this behaviour.}.
This is a good thing because the user can move the system sources
without having to edit the system definition.
708
709
710
711
712
713
714
715
716
717
718
719
720

@end itemize

@node  A more involved example, The defsystem grammar, The defsystem form, Defining systems with defsystem
@comment  node-name,  next,  previous,  up
@section A more involved example

Let's illustrate some more involved uses of @code{defsystem} via a
slightly convoluted example:

@lisp
(defsystem "foo"
  :version "1.0"
721
  :components ((:module "foo" :components ((:file "bar") (:file"baz")
722
                                           (:file "quux"))
Robert P. Goldman's avatar
Nits.    
Robert P. Goldman committed
723
724
725
726
                :perform (compile-op :after (op c)
                          (do-something c))
                :explain (compile-op :after (op c)
                          (explain-something c)))
727
728
729
730
731
732
               (:file "blah")))
@end lisp

The method-form tokens need explaining: essentially, this part:

@lisp
733
734
735
736
                :perform (compile-op :after (op c)
                          (do-something c))
                :explain (compile-op :after (op c)
                          (explain-something c))
737
738
739
740
741
742
@end lisp

has the effect of

@lisp
(defmethod perform :after ((op compile-op) (c (eql ...)))
743
           (do-something c))
744
(defmethod explain :after ((op compile-op) (c (eql ...)))
745
           (explain-something c))
746
747
@end lisp

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
748
749
750
751
752
753
where @code{...} is the component in question;
note that although this also supports @code{:before} methods,
they may not do what you want them to ---
a @code{:before} method on perform @code{((op compile-op) (c (eql ...)))}
will run after all the dependencies and sub-components have been processed,
but before the component in question has been compiled.
754

755
@node  The defsystem grammar, Other code in .asd files, A more involved example, Defining systems with defsystem
756
757
758
@comment  node-name,  next,  previous,  up
@section The defsystem grammar

759
760
@example
system-definition := ( defsystem system-designator @var{option}* )
761
762

option := :components component-list
763
        | :pathname pathname-specifier
764
        | :default-component-class
765
        | :perform method-form
766
        | :explain method-form
767
        | :output-files method-form
768
        | :operation-done-p method-form
769
        | :depends-on ( @var{dependency-def}* )
770
        | :serial [ t | nil ]
771
        | :in-order-to ( @var{dependency}+ )
772

773
component-list := ( @var{component-def}* )
774

775
component-def  := ( component-type simple-component-name @var{option}* )
776

777
component-type := :system | :module | :file | :static-file | other-component-type
778

779
other-component-type := symbol-by-name (@pxref{The defsystem grammar,,Component types})
780

Gary King's avatar
Gary King committed
781
782
783
784
dependency-def := simple-component-name
               | ( :feature name )
               | ( :version simple-component-name version-specifier)

785
786
dependency := (dependent-op @var{requirement}+)
requirement := (required-op @var{required-component}+)
787
788
789
             | (feature feature-name)
dependent-op := operation-name
required-op := operation-name | feature
Gary King's avatar
Gary King committed
790
791
792

simple-component-name := string
                      |  symbol
793

794
795
pathname-specifier := pathname | string | symbol

796
method-form := (operation-name qual lambda-list @&rest body)
797
qual := method qualifier
798
@end example
799

800
801
@subsection Component names

802
803
Component names (@code{simple-component-name})
may be either strings or symbols.
804

805
@subsection Component types
806
807
808
809
810
811
812

Component type names, even if expressed as keywords, will be looked up
by name in the current package and in the asdf package, if not found in
the current package.  So a component type @code{my-component-type}, in
the current package @code{my-system-asd} can be specified as
@code{:my-component-type}, or @code{my-component-type}.

813
814
@subsection Pathname specifiers

815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
A pathname specifier (@code{pathname-specifier})
may be a pathname, a string or a symbol.
When no pathname specifier is given for a component,
which is the usual case, the component name itself is used.

If a string is given, which is the usual case,
the string will be interpreted as a Unix-style pathname
where @code{/} characters will be interpreted as directory separators.
Usually, Unix-style relative pathnames are used
(i.e. not starting with @code{/}, as opposed to absolute pathnames);
they are relative to the path of the parent component.
Finally, depending on the @code{component-type},
the pathname may be interpreted as either a file or a directory,
and if it's a file,
a file type may be added corresponding to the @code{component-type},
or else it will be extracted from the string itself (if applicable).

For instance, the @code{component-type} @code{:module}
wants a directory pathname, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar/"}.
On the other hand, the @code{component-type} @code{:file}
wants a file of type @code{lisp}, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar.lisp"},
and a string @code{"foo/bar.quux"}
will be interpreted as the pathname @file{#p"foo/bar.quux.lisp"}.
Finally, the @code{component-type} @code{:static-file}
wants a file without specifying a type, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar"},
and a string @code{"foo/bar.quux"}
will be interpreted as the pathname @file{#p"foo/bar.quux"}.

If a symbol is given, it will be translated into a string,
and downcased in the process.
The downcasing of symbols is unconventional,
but was selected after some consideration.
Observations suggest that the type of systems we want to support
either have lowercase as customary case (Unix, Mac, windows)
or silently convert lowercase to uppercase (lpns),
so this makes more sense than attempting to use @code{:case :common}
as argument to @code{make-pathname},
which is reported not to work on some implementations.

Pathnames objects may be given to override the path for a component.
Such objects are typically specified using reader macros such as @code{#p}
or @code{#.(make-pathname ...)}.
Note however, that @code{#p...} is a short for @code{#.(parse-namestring ...)}
and that the behavior @code{parse-namestring} is completely non-portable,
862
863
unless you are using Common Lisp @code{logical-pathname}s.
(@xref{The defsystem grammar,,Warning about logical pathnames}, below.)
864
865
866
867
868
Pathnames made with @code{#.(make-pathname ...)}
can usually be done more easily with the string syntax above.
The only case that you really need a pathname object is to override
the component-type default file type for a given component.
Therefore, it is a rare case that pathname objects should be used at all.
869
Unhappily, ASDF 1 didn't properly support
870
871
parsing component names as strings specifying paths with directories,
and the cumbersome @code{#.(make-pathname ...)} syntax had to be used.
872
873
874
875
876
877
878
Note that when specifying pathname objects, no magic interpretation of the pathname
is made depending on the component type.
On the one hand, you have to be careful to provide a pathname that correctly
fulfills whatever constraints are required from that component type
(e.g. naming a directory or a file with appropriate type);
on the other hand, you can circumvent the file type that would otherwise
be forced upon you if you were specifying a string.
879
880
881
882


@subsection Warning about logical pathnames

883
884
885
886
887
888
889
890
891
892
893
To use logical pathnames,
you will have to provide a pathname object as a @code{:pathname} specifier
to components that use it, using such syntax as
@code{#p"LOGICAL-HOST:absolute;path;to;component.lisp"}.

You only have to specify such logical pathname for your system or
some top-level component, as sub-components using the usual string syntax
for names will be properly merged with the pathname of their parent.
The specification of a logical pathname host however is @emph{not}
otherwise directly supported in the ASDF syntax
for pathname specifiers as strings.
894

895
896
897
898
899
900
901
902
903
Logical pathnames are not specifically recommended to newcomers,
but are otherwise supported.
Moreover, the @code{asdf-output-translation} layer will
avoid trying to resolve and translate logical-pathnames,
so you can define yourself what translations you want to use
with the logical pathname facility.

The user of logical pathnames will have to configure logical pathnames himself,
before they may be used, and ASDF provides no specific support for that.
904
905


906
907
@subsection Serial dependencies

908
909
910
911
If the @code{:serial t} option is specified for a module,
ASDF will add dependencies for each each child component,
on all the children textually preceding it.
This is done as if by @code{:depends-on}.
912
913
914
915
916
917
918
919
920

@lisp
:components ((:file "a") (:file "b") (:file "c"))
:serial t
@end lisp

is equivalent to

@lisp
921
:components ((:file "a")
922
923
             (:file "b" :depends-on ("a"))
             (:file "c" :depends-on ("a" "b")))
924
925
926
927
928
929
@end lisp


@subsection Source location

The @code{:pathname} option is optional in all cases for systems
930
931
defined via @code{defsystem},
and in the usual case the user is recommended not to supply it.
932

933
Instead, ASDF follows a hairy set of rules that are designed so that
934
@enumerate
935
@item
Francois-Rene Rideau's avatar
1.647:    
Francois-Rene Rideau committed
936
937
@code{find-system}
will load a system from disk
938
939
940
941
942
943
944
and have its pathname default to the right place.
@item
This pathname information will not be overwritten with
@code{*default-pathname-defaults*}
(which could be somewhere else altogether)
if the user loads up the @file{.asd} file into his editor
and interactively re-evaluates that form.
945
946
@end enumerate

947
948
If a system is being loaded for the first time,
its top-level pathname will be set to:
949
950

@itemize
951
952
953
954
955
@item
The host/device/directory parts of @code{*load-truename*},
if it is bound.
@item
@code{*default-pathname-defaults*}, otherwise.
956
957
958
959
960
961
@end itemize

If a system is being redefined, the top-level pathname will be

@itemize
@item
962
963
changed, if explicitly supplied or obtained from @code{*load-truename*}
(so that an updated source location is reflected in the system definition)
964
@item
965
changed if it had previously been set from @code{*default-pathname-defaults*}
966
@item
967
968
969
970
left as before, if it had previously been set from @code{*load-truename*}
and @code{*load-truename*} is currently unbound
(so that a developer can evaluate a @code{defsystem} form
from within an editor without clobbering its source location)
971
972
@end itemize

973
@node Other code in .asd files,  , The defsystem grammar, Defining systems with defsystem
974
975
@section Other code in .asd files

976
977
978
979
980
981
982
983
Files containing @code{defsystem} forms
are regular Lisp files that are executed by @code{load}.
Consequently, you can put whatever Lisp code you like into these files
(e.g., code that examines the compile-time environment
and adds appropriate features to @code{*features*}).
However, some conventions should be followed,
so that users can control certain details of execution
of the Lisp in @file{.asd} files:
984
985
986

@itemize
@item
987
988
989
990
991
992
Any informative output
(other than warnings and errors,
which are the condition system's to dispose of)
should be sent to the standard CL stream @code{*standard-output*},
so that users can easily control the disposition
of output from ASDF operations.
993
@end itemize
994
995


996
@node The object model of ASDF, Controlling where ASDF searches for systems, Defining systems with defsystem, Top
997
@comment  node-name,  next,  previous,  up
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
@chapter The object model of ASDF

ASDF is designed in an object-oriented way from the ground up.
Both a system's structure and the operations that can be performed on systems
follow a protocol.
ASDF is extensible to new operations and to new component types.
This allows the addition of behaviours:
for example, a new component could be added for Java JAR archives,
and methods specialised on @code{compile-op} added for it
that would accomplish the relevant actions.

This chapter deals with @emph{components}, the building blocks of a system,
and @emph{operations}, the actions that can be performed on a system.
1011
1012
1013
1014



@menu
1015
1016
* Operations::
* Components::
1017
1018
@end menu

1019
@node  Operations, Components, The object model of ASDF, The object model of ASDF
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
@comment  node-name,  next,  previous,  up
@section Operations
@cindex operation

An @dfn{operation} object of the appropriate type is instantiated
whenever the user wants to do something with a system like

@itemize
@item compile all its files
@item load the files into a running lisp environment
@item copy its source files somewhere else
@end itemize

1033
1034
1035
1036
Operations can be invoked directly, or examined
to see what their effects would be without performing them.
@emph{FIXME: document how!}
There are a bunch of methods specialised on operation and component type
1037
1038
that actually do the grunt work.

1039
1040
1041
1042
The operation object contains whatever state is relevant for this purpose
(perhaps a list of visited nodes, for example)
but primarily is a nice thing to specialise operation methods on
and easier than having them all be @code{EQL} methods.
1043
1044

Operations are invoked on systems via @code{operate}.
1045
@anchor{operate}
1046
1047
@deffn {Generic function} @code{operate} @var{operation} @var{system} @&rest @var{initargs}
@deffnx {Generic function} @code{oos} @var{operation} @var{system} @&rest @var{initargs}
1048
1049
@code{operate} invokes @var{operation} on @var{system}.
@code{oos} is a synonym for @code{operate}.
1050
1051
1052
1053
1054

@var{operation} is a symbol that is passed, along with the supplied
@var{initargs}, to @code{make-instance} to create the operation object.
@var{system} is a system designator.

1055
1056
1057
1058
1059
1060
The @var{initargs} are passed to the @code{make-instance} call
when creating the operation object.
Note that dependencies may cause the operation
to invoke other operations on the system or its components:
the new operations will be created
with the same @var{initargs} as the original one.
1061
1062
1063
1064

@end deffn

@menu
1065
1066
* Predefined operations of ASDF::
* Creating new operations::
1067
1068
@end menu

1069
@node Predefined operations of ASDF, Creating new operations, Operations, Operations
1070
@comment  node-name,  next,  previous,  up
1071
@subsection Predefined operations of ASDF
1072

1073
1074
All the operations described in this section are in the @code{asdf} package.
They are invoked via the @code{operate} generic function.
1075
1076

@lisp
1077
(asdf:operate 'asdf:@var{operation-name} :@var{system-name} @{@var{operation-options ...}@})
1078
1079
@end lisp

1080
@deffn Operation @code{compile-op} @&key @code{proclamations}
1081

1082
1083
1084
This operation compiles the specified component.
If proclamations are supplied, they will be proclaimed.
This is a good place to specify optimization settings.
1085

1086
1087
When creating a new component type,
you should provide methods for @code{compile-op}.
1088

1089
1090
1091
1092
1093
1094
When @code{compile-op} is invoked,
component dependencies often cause some parts of the system
to be loaded as well as compiled.
Invoking @code{compile-op}
does not necessarily load all the parts of the system, though;
use @code{load-op} to load a system.
1095
1096
@end deffn

1097
@deffn Operation @code{load-op} @&key @code{proclamations}
1098
1099
1100
1101

This operation loads a system.

The default methods for @code{load-op} compile files before loading them.
1102
For parity, your own methods on new component types should probably do so too.
1103
1104
@end deffn

1105
@deffn Operation @code{load-source-op}
1106

1107
1108
1109
1110
1111
1112
This operation will load the source for the files in a module
even if the source files have been compiled.
Systems sometimes have knotty dependencies
which require that sources are loaded
before they can be compiled.
This is how you do that.
1113

1114
1115
If you are creating a component type,
you need to implement this operation --- at least, where meaningful.
1116
1117
@end deffn

1118
@anchor{test-op}
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
@deffn Operation @code{test-op}

This operation will perform some tests on the module.
The default method will do nothing.
The default dependency is to require
@code{load-op} to be performed on the module first.
The default @code{operation-done-p} is that the operation is @emph{never} done
---
we assume that if you invoke the @code{test-op},
you want to test the system, even if you have already done so.

The results of this operation are not defined by ASDF.
It has proven difficult to define how the test operation
should signal its results to the user
in a way that is compatible with all of the various test libraries
and test techniques in use in the community.
Robert P. Goldman's avatar
Robert P. Goldman committed
1135
1136
@end deffn

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
1137
@c @deffn Operation test-system-version @&key minimum
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149

@c Asks the system whether it satisfies a version requirement.

@c The default method accepts a string, which is expected to contain of a
@c number of integers separated by #\. characters.  The method is not
@c recursive.  The component satisfies the version dependency if it has
@c the same major number as required and each of its sub-versions is
@c greater than or equal to the sub-version number required.

@c @lisp
@c (defun version-satisfies (x y)
@c   (labels ((bigger (x y)
1150
1151
1152
1153
1154
@c           (cond ((not y) t)
@c                 ((not x) nil)
@c                 ((> (car x) (car y)) t)
@c                 ((= (car x) (car y))
@c                  (bigger (cdr x) (cdr y))))))
1155
@c     (and (= (car x) (car y))
1156
@c       (or (not (cdr y)) (bigger (cdr x) (cdr y))))))
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
@c @end lisp

@c If that doesn't work for your system, you can override it.  I hope
@c you have as much fun writing the new method as @verb{|#lisp|} did
@c reimplementing this one.
@c @end deffn

@c @deffn Operation feature-dependent-op

@c An instance of @code{feature-dependent-op} will ignore any components
@c which have a @code{features} attribute, unless the feature combination
@c it designates is satisfied by @code{*features*}.  This operation is
@c not intended to be instantiated directly, but other operations may
@c inherit from it.

@c @end deffn
1173

1174
@node  Creating new operations,  , Predefined operations of ASDF, Operations
1175
1176
1177
@comment  node-name,  next,  previous,  up
@subsection Creating new operations

1178
1179
1180
ASDF was designed to be extensible in an object-oriented fashion.
To teach ASDF new tricks, a programmer can implement the behaviour he wants
by creating a subclass of @code{operation}.
1181

1182
1183
1184
1185
1186
1187
ASDF's pre-defined operations are in no way ``privileged'',
but it is requested that developers never use the @code{asdf} package
for operations they develop themselves.
The rationale for this rule is that we don't want to establish a
``global asdf operation name registry'',
but also want to avoid name clashes.
1188
1189

An operation must provide methods for the following generic functions
1190
1191
when invoked with an object of type @code{source-file}:
@emph{FIXME describe this better}
1192
1193
1194
1195

@itemize

@item @code{output-files}
1196
1197
1198
1199
1200
1201
1202
The @code{output-files} method determines where the method will put its files.
It returns two values, a list of pathnames, and a boolean.
If the boolean is @code{T} then the pathnames are marked
not be translated by enclosing @code{:around} methods.
If the boolean is @code{NIL} then enclosing @code{:around} methods
may translate these pathnames, e.g. to ensure object files
are somehow stored in some implementation-dependent cache.
1203
@item @code{perform}
1204
1205
1206
1207
1208
1209
1210
The @code{perform} method must call @code{output-files}
to find out where to put its files,
because the user is allowed to override.
@item @code{output-files}
for local policy @code{explain}
@item @code{operation-done-p},
if you don't like the default one
1211
1212
1213

@end itemize

1214
1215
1216
Operations that print output should send that output to the standard
CL stream @code{*standard-output*}, as the Lisp compiler and loader do.

1217
@node Components,  , Operations, The object model of ASDF
1218
1219
1220
1221
1222
1223
1224
@comment  node-name,  next,  previous,  up
@section Components
@cindex component
@cindex system
@cindex system designator
@vindex *system-definition-search-functions*

1225
1226
1227
1228
A @dfn{component} represents a source file or
(recursively) a collection of components.
A @dfn{system} is (roughly speaking) a top-level component
that can be found via @code{find-system}.
1229

1230
1231
1232
A @dfn{system designator} is a string or symbol
and behaves just like any other component name
(including with regard to the case conversion rules for component names).
1233
1234
1235
1236


@defun find-system system-designator &optional (error-p t)

1237
1238
1239
1240
Given a system designator, @code{find-system} finds and returns a system.
If no system is found, an error of type
@code{missing-component} is thrown,
or @code{nil} is returned if @code{error-p} is false.
1241
1242

To find and update systems, @code{find-system} funcalls each element
1243
1244
1245
in the @code{*system-definition-search-functions*} list,
expecting a pathname to be returned.
The resulting pathname is loaded if either of the following conditions is true:
1246
1247

@itemize
1248
1249
1250
1251
1252
@item
there is no system of that name in memory
@item
the file's @code{last-modified} time exceeds the @code{last-modified} time
of the system in memory
1253
1254
@end itemize

1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
When system definitions are loaded from @file{.asd} files,
a new scratch package is created for them to load into,
so that different systems do not overwrite each others operations.
The user may also wish to (and is recommended to)
include @code{defpackage} and @code{in-package} forms
in his system definition files, however,
so that they can be loaded manually if need be.

The default value of @code{*system-definition-search-functions*}
is a list of two functions.
The first function looks in each of the directories given
by evaluating members of @code{*central-registry*}
for a file whose name is the name of the system and whose type is @file{asd}.
The first such file is returned,
whether or not it turns out to actually define the appropriate system.
The second function does something similar,
for the directories specified in the @code{source-registry}.
Hence, it is strongly advised to define a system
1273
1274
1275
1276
1277
@var{foo} in the corresponding file @var{foo.asd}.
@end defun


@menu
1278
1279
1280
* Common attributes of components::
* Pre-defined subclasses of component::
* Creating new component types::
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
@end menu

@node  Common attributes of components, Pre-defined subclasses of component, Components, Components
@comment  node-name,  next,  previous,  up
@subsection Common attributes of components

All components, regardless of type, have the following attributes.
All attributes except @code{name} are optional.

@subsubsection Name

1292
1293
A component name is a string or a symbol.
If a symbol, its name is taken and lowercased.
1294

1295
1296
Unless overridden by a @code{:pathname} attribute,
the name will be interpreted as a pathname specifier according
1297
1298
to a Unix-style syntax.
@xref{The defsystem grammar,,Pathname specifiers}.
1299
1300
1301

@subsubsection Version identifier

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
1302
This optional attribute is used by the @code{test-system-version} operation.
1303
1304
1305
1306
@xref{Predefined operations of ASDF}.
For the default method of @code{test-system-version},
the version should be a string of integers separated by dots,
for example @samp{1.0.11}.
1307

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
1308
1309
1310
1311
1312
1313
@emph{Nota Bene}:
This operation, planned for ASDF 1,
is still not implement yet as of ASDF 2.
Don't hold your breath.


1314
1315
@subsubsection Required features

1316
1317
1318
@emph{FIXME: This subsection seems to contradict the
@code{defsystem} grammar subsection,
which doesn't provide any obvious way to specify required features.
1319
1320
Furthermore, in 2009, discussions on the
@uref{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}
1321
1322
suggested that the specification of required features may be broken,
and that no one may have been using them for a while.
1323
1324
1325
Please contact the
@uref{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}
if you are interested in getting this features feature fixed.}
1326
1327
1328
1329
1330
1331
1332

Traditionally defsystem users have used reader conditionals
to include or exclude specific per-implementation files.
This means that any single implementation cannot read the entire system,
which becomes a problem if it doesn't wish to compile it,
but instead for example to create an archive file containing all the sources,
as it will omit to process the system-dependent sources for other systems.
1333
1334

Each component in an asdf system may therefore specify features using
1335
the same syntax as @code{#+} does, and it will (somehow) be ignored for
1336
1337
1338
1339
1340
1341
certain operations unless the feature conditional is a member of
@code{*features*}.


@subsubsection Dependencies

1342
1343
This attribute specifies dependencies of the component on its siblings.
It is optional but often necessary.
1344
1345
1346
1347

There is an excitingly complicated relationship between the initarg
and the method that you use to ask about dependencies

1348
1349
Dependencies are between (operation component) pairs.
In your initargs for the component, you can say
1350
1351
1352

@lisp
:in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))
1353
              (load-op (load-op "foo")))
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
@end lisp

This means the following things:
@itemize
@item
before performing compile-op on this component, we must perform
load-op on @var{a} and @var{b}, and compile-op on @var{c},
@item
before performing @code{load-op}, we have to load @var{foo}
@end itemize

The syntax is approximately

@verbatim
(this-op {(other-op required-components)}+)

required-components := component-name
                     | (required-components required-components)

component-name := string
                | (:version string minimum-version-object)
@end verbatim

Side note:

1379
1380
This is on a par with what ACL defsystem does.
mk-defsystem is less general: it has an implied dependency
1381
1382
1383
1384
1385
1386
1387
1388
1389

@verbatim
  for all x, (load x) depends on (compile x)
@end verbatim

and using a @code{:depends-on} argument to say that @var{b} depends on
@var{a} @emph{actually} means that

@verbatim
1390
  (compile b) depends on (load a)
1391
1392
1393
1394
1395
1396
1397
@end verbatim

This is insufficient for e.g. the McCLIM system, which requires that
all the files are loaded before any of them can be compiled ]

End side note

1398
1399
1400
In ASDF, the dependency information for a given component and operation
can be queried using @code{(component-depends-on operation component)},
which returns a list
1401
1402
1403
1404
1405
1406

@lisp
((load-op "a") (load-op "b") (compile-op "c") ...)
@end lisp

@code{component-depends-on} can be subclassed for more specific
1407
1408
1409
component/operation types: these need to @code{(call-next-method)}
and append the answer to their dependency, unless
they have a good reason for completely overriding the default dependencies.
1410

Robert P. Goldman's avatar
Nits.    
Robert P. Goldman committed
1411
If it weren't for CLISP, we'd be using @code{LIST} method
1412
1413
1414
1415
1416
combination to do this transparently.
But, we need to support CLISP.
If you have the time for some CLISP hacking,
I'm sure they'd welcome your fixes.
@c Doesn't CLISP now support LIST method combination?
1417
1418
1419

@subsubsection pathname

1420
1421
This attribute is optional and if absent (which is the usual case),
the component name will be used.
1422

1423
1424
@xref{The defsystem grammar,,Pathname specifiers},
for an explanation of how this attribute is interpreted.
1425

1426
Note that the @code{defsystem} macro (used to create a ``top-level'' system)
1427
1428
does additional processing to set the filesystem location of
the top component in that system.