asdf.texinfo 94.4 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
@c for install-info
@dircategory Software development
@direntry
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
10
* asdf: (asdf).           Another System Definition Facility (for Common Lisp)
11
12
@end direntry

13
@copying
14
15
This manual describes ASDF, a system definition facility
for Common Lisp programs and libraries.
16

17
ASDF Copyright @copyright{} 2001-2010 Daniel Barlow and contributors.
18

19
20
This manual Copyright @copyright{} 2001-2010 Daniel Barlow and contributors.

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
21
This manual revised @copyright{} 2009-2010 Robert P. Goldman and Francois-Rene Rideau.
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

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
48

49
50
51
52
53
@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
54

55
56
57
58
59
60
61
@c Output the table of contents at the beginning.
@contents

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

@ifnottex

62
@node Top, Introduction, (dir), (dir)
63
@top asdf: another system definition facility
64

65
66
67
@insertcopying

@menu
68
69
* Introduction::
* Loading ASDF::
70
71
* Configuring ASDF::
* Using ASDF::
72
73
* Defining systems with defsystem::
* The object model of ASDF::
74
* Controlling where ASDF searches for systems::
75
76
77
78
79
* Controlling where ASDF saves compiled files::
* Error handling::
* Miscellaneous additional functionality::
* Getting the latest version::
* FAQ::
80
* TODO list::
81
82
83
84
85
* missing bits in implementation::
* Inspiration::
* Concept Index::
* Function and Class Index::
* Variable Index::
86

87
88
@c @detailmenu
@c  --- The Detailed Node Listing ---
89

90
@c Defining systems with defsystem
91

92
93
94
95
@c * The defsystem form::
@c * A more involved example::
@c * The defsystem grammar::
@c * Other code in .asd files::
96

97
@c The object model of ASDF
98

99
100
@c * Operations::
@c * Components::
101

102
@c Operations
103

104
105
@c * Predefined operations of ASDF::
@c * Creating new operations::
106

107
@c Components
108

109
110
111
@c * Common attributes of components::
@c * Pre-defined subclasses of component::
@c * Creating new component types::
112

113
@c properties
114

115
116
@c * Pre-defined subclasses of component::
@c * Creating new component types::
117

118
@c @end detailmenu
119
120
121
122
123
124
@end menu

@end ifnottex

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

125
@node Introduction, Loading ASDF, Top, Top
126
127
@comment  node-name,  next,  previous,  up
@chapter Introduction
Robert P. Goldman's avatar
Robert P. Goldman committed
128
129
130
131
132
133
@cindex ASDF-related features
@vindex *features*
@cindex Testing for ASDF
@cindex ASDF versions
@cindex :asdf
@cindex :asdf2
134

135
136
137
138
139
140
141
142
143
144
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
145
@xref{Using ASDF,,Loading a system},
146
to learn how to use ASDF to load a system.
Robert P. Goldman's avatar
Robert P. Goldman committed
147
@xref{Defining systems with defsystem},
148
to learn how to define a system of your own.
149
@xref{The object model of ASDF}, for a description of
Robert P. Goldman's avatar
Robert P. Goldman committed
150
the ASDF internals and how to extend ASDF.
151

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
152
@emph{Nota Bene}:
153
154
We are preparing for a release of ASDF 2,
which will have version 2.000 and later.
155
Releases in the 1.600 series and beyond should be considered as
Robert P. Goldman's avatar
Robert P. Goldman committed
156
release candidates,
157
158
but we're still working on documentation,
and on fixing the occasional bug.
159
For all practical purposes, ASDF 2 refers to releases later than 1.635,
160
and ASDF 1 to any release earlier than 1.369 or so.
Robert P. Goldman's avatar
Robert P. Goldman committed
161

162
ASDF 2.000 release candidates and beyond will have
Robert P. Goldman's avatar
Robert P. Goldman committed
163
164
165
@code{:asdf2} onto @code{*features*} so that if you are writing
ASDF-dependent code you may check for this feature to see if the new API
is present.  @emph{All} versions of ASDF should have the @code{:asdf} feature.
166

167

168
@node Loading ASDF, Configuring ASDF, Introduction, Top
169
@comment  node-name,  next,  previous,  up
170
@chapter Loading ASDF
171
@vindex *central-registry*
172
@cindex link farm
173
174
175
176
177
178
@findex load-system
@findex compile-system
@findex test-system
@cindex system directory designator
@findex operate
@findex oos
179

180
@c @menu
181
@c * Installing ASDF::
182
183
184
@c @end menu


185
186
187
188
189
190
191
192
193
194
195
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
@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
223
(and (find-package :asdf) #+asdf2 (asdf:asdf-version) #-asdf2 :old)
224
225
226
227
@end lisp

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

231
If you are running a version older than 1.645,
232
233
234
235
236
237
we recommend that you load a newer ASDF using the method below.


@section Loading an otherwise installed ASDF

If your implementation doesn't include ASDF,
238
or includes an old version of it (before 1.600),
239
240
241
242
243
244
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
245

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

248
You can extract this file from latest release tarball on the
249
@url{http://common-lisp.net/project/asdf/,ASDF website}.
250
If you are daring and willing to report bugs, you can get
251
the latest and greatest version of ASDF from its git repository.
252
253
254
255
256
257
258
@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.

259
260
@node Configuring ASDF, Using ASDF, Loading ASDF, Top
@comment  node-name,  next,  previous,  up
261
262
263
264
265
266
267
268

@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.

269
Since ASDF 1.600, the preferred way to configure where ASDF finds your systems is
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
270
271
272
the @code{source-registry} facility,
fully described in its own chapter of this manual.
@xref{Controlling where ASDF searches for systems}.
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308

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:
309

310
311
312
313
314
315
316
317
318
319
@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
320
@section Configuring ASDF to find your systems -- old style
321
322
323
324
325
326
327
328
329
330
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
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390

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
391
392
393
394
395
396
397
398
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

399
400
401
402
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.

403

404
@section Configuring where ASDF stores object files
405
@findex clear-output-locations
406
407
408
409
410
411
412
413
414
415
416
417

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.

418
Starting with ASDF 1.600, the @code{asdf-output-translations} facility
419
was added to ASDF itself, that controls where object files will be stored.
420
This facility is fully described in a chapter of this manual,
421
@ref{Controlling where ASDF saves compiled files}.
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
449
450
451
452
453
454
455
456
457
458
459
460
461
462

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/}.
Once again, see the document @file{README.asdf-output-translations}
for full details.

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:
463
464

@lisp
465
(asdf:clear-output-translations)
466
467
@end lisp

468
469
470
471
472
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.

473
Finally note that before ASDF 1.600,
474
475
476
477
478
479
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.
480

481
482
@node Using ASDF, Defining systems with defsystem, Configuring ASDF, Top
@comment  node-name,  next,  previous,  up
483

484
485
486
487
488
489
@chapter Using ASDF

@section Loading a system

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

@example
492
(asdf:load-system :@var{foo})
493
494
@end example

495
496
497
In older versions of ASDF, you needed to use
@code{(asdf:oos 'asdf:load-op :@var{foo})}.
We recommend that you upgrade from such older versions.
498
@xref{Loading ASDF,,Loading an otherwise installed ASDF}.
499

500

501
@section Other Operations
502

503
504
ASDF provides three commands for the most common system operations:
@code{load-system}, @code{compile-system} or @code{test-system}.
505

506
507
508
509
510
511
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.
512

513
514
515
516
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.
517

518
519
Reminder: before ASDF can operate on a system, however,
it must be able to find and load that system's definition.
520
@xref{Configuring ASDF,,Configuring ASDF to find your systems}.
521
522


523
524
525
526
527
@section Summary

To use ASDF:

@itemize
528
@item
529
530
531
Load ASDF itself into your Lisp image, either through
@code{(require :asdf)} or else through
@code{(load "/path/to/asdf.lisp")}.
532

533
@item
534
535
Make sure ASDF can find system definitions
thanks to proper source-registry configuration.
536

537
@item
538
539
Load a system with @code{(load-system :my-system)}
or use some other operation on some system of your choice.
540
541
542

@end itemize

543
@section Moving on
544

545
546
547
548
549
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.

550

551
@node Defining systems with defsystem, The object model of ASDF, Using ASDF, Top
552
553
554
555
556
557
558
559
@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
560
561
562
563
* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
564
565
566
567
568
569
@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

570
571
572
573
574
575
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}.
576

577
578
Let's look at a simple system.
This is a complete file that would
579
usually be saved as @file{hello-lisp.asd}:
580
581

@lisp
582
(in-package :asdf)
583

584
(defsystem "hello-lisp"
585
586
587
588
589
590
591
  :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"))))
592
593
594
595
596
@end lisp

Some notes about this example:

@itemize
597
598

@item
599
600
601
602
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}.
603

604
@item
605
606
607
608
609
610
611
612
613
614
615
616
617
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
618
619

@item
620
621
622
The @code{defsystem} form defines a system named @code{hello-lisp}
that contains three source files:
@file{packages}, @file{macros} and @file{hello}.
623

624
625
626
627
628
629
630
@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}.
631
632

@item
633
634
635
636
637
638
639
640
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.
641
642
643
644
645
646
647
648
649
650
651
652
653

@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"
654
  :components ((:module "foo" :components ((:file "bar") (:file"baz")
655
                                           (:file "quux"))
Robert P. Goldman's avatar
Nits.    
Robert P. Goldman committed
656
657
658
659
                :perform (compile-op :after (op c)
                          (do-something c))
                :explain (compile-op :after (op c)
                          (explain-something c)))
660
661
662
663
664
665
               (:file "blah")))
@end lisp

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

@lisp
666
667
668
669
                :perform (compile-op :after (op c)
                          (do-something c))
                :explain (compile-op :after (op c)
                          (explain-something c))
670
671
672
673
674
675
@end lisp

has the effect of

@lisp
(defmethod perform :after ((op compile-op) (c (eql ...)))
676
           (do-something c))
677
(defmethod explain :after ((op compile-op) (c (eql ...)))
678
           (explain-something c))
679
680
@end lisp

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
681
682
683
684
685
686
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.
687

688
@node  The defsystem grammar, Other code in .asd files, A more involved example, Defining systems with defsystem
689
690
691
692
693
694
695
@comment  node-name,  next,  previous,  up
@section The defsystem grammar

@verbatim
system-definition := ( defsystem system-designator {option}* )

option := :components component-list
696
        | :pathname pathname-specifier
697
        | :default-component-class
698
        | :perform method-form
699
        | :explain method-form
700
        | :output-files method-form
701
        | :operation-done-p method-form
702
        | :depends-on ( {dependency-def}* )
703
        | :serial [ t | nil ]
704
705
706
        | :in-order-to ( {dependency}+ )

component-list := ( {component-def}* )
707

708
component-def  := ( component-type simple-component-name {option}* )
709

710
component-type := :system | :module | :file | :static-file | other-component-type
711

Gary King's avatar
Gary King committed
712
713
714
715
dependency-def := simple-component-name
               | ( :feature name )
               | ( :version simple-component-name version-specifier)

716
717
718
719
720
dependency := (dependent-op {requirement}+)
requirement := (required-op {required-component}+)
             | (feature feature-name)
dependent-op := operation-name
required-op := operation-name | feature
Gary King's avatar
Gary King committed
721
722
723

simple-component-name := string
                      |  symbol
724

725
726
pathname-specifier := pathname | string | symbol

727
728
method-form := (operation-name qual lambda-list &rest body)
qual := method qualifier
729
730
@end verbatim

731
732
@subsection Component names

733
734
Component names (@code{simple-component-name})
may be either strings or symbols.
735
736
737

@subsection Pathname specifiers

738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
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,
785
786
unless you are using Common Lisp @code{logical-pathname}s.
(@xref{The defsystem grammar,,Warning about logical pathnames}, below.)
787
788
789
790
791
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.
792
Unhappily, old versions of ASDF (before 1.600) didn't properly support
793
794
parsing component names as strings specifying paths with directories,
and the cumbersome @code{#.(make-pathname ...)} syntax had to be used.
795
796
797
798
799
800
801
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.
802
803
804
805


@subsection Warning about logical pathnames

806
807
808
809
810
811
812
813
814
815
816
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.
817

818
819
820
821
822
823
824
825
826
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.
827
828


829
830
@subsection Serial dependencies

831
832
833
834
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}.
835
836
837
838
839
840
841
842
843

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

is equivalent to

@lisp
844
:components ((:file "a")
845
846
             (:file "b" :depends-on ("a"))
             (:file "c" :depends-on ("a" "b")))
847
848
849
850
851
852
@end lisp


@subsection Source location

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

856
Instead, ASDF follows a hairy set of rules that are designed so that
857
@enumerate
858
@item
Francois-Rene Rideau's avatar
1.647:    
Francois-Rene Rideau committed
859
860
@code{find-system}
will load a system from disk
861
862
863
864
865
866
867
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.
868
869
@end enumerate

870
871
If a system is being loaded for the first time,
its top-level pathname will be set to:
872
873

@itemize
874
875
876
877
878
@item
The host/device/directory parts of @code{*load-truename*},
if it is bound.
@item
@code{*default-pathname-defaults*}, otherwise.
879
880
881
882
883
884
@end itemize

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

@itemize
@item
885
886
changed, if explicitly supplied or obtained from @code{*load-truename*}
(so that an updated source location is reflected in the system definition)
887
@item
888
changed if it had previously been set from @code{*default-pathname-defaults*}
889
@item
890
891
892
893
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)
894
895
@end itemize

896
@node Other code in .asd files,  , The defsystem grammar, Defining systems with defsystem
897
898
@section Other code in .asd files

899
900
901
902
903
904
905
906
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:
907
908
909

@itemize
@item
910
911
912
913
914
915
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.
916
@end itemize
917
918


919
@node The object model of ASDF, Controlling where ASDF searches for systems, Defining systems with defsystem, Top
920
@comment  node-name,  next,  previous,  up
921
922
923
924
925
926
927
928
929
930
931
932
933
@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.
934
935
936
937



@menu
938
939
* Operations::
* Components::
940
941
@end menu

942
@node  Operations, Components, The object model of ASDF, The object model of ASDF
943
944
945
946
947
948
949
950
951
952
953
954
955
@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

956
957
958
959
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
960
961
that actually do the grunt work.

962
963
964
965
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.
966
967

Operations are invoked on systems via @code{operate}.
968
@anchor{operate}
969
970
971
972
@deffn {Generic function} @code{operate} @var{operation} @var{system} @code{&rest} @var{initargs}
@deffnx {Generic function} @code{oos} @var{operation} @var{system} @code{&rest} @var{initargs}
@code{operate} invokes @var{operation} on @var{system}.
@code{oos} is a synonym for @code{operate}.
973
974
975
976
977

@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.

978
979
980
981
982
983
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.
984
985
986
987

@end deffn

@menu
988
989
* Predefined operations of ASDF::
* Creating new operations::
990
991
@end menu

992
@node Predefined operations of ASDF, Creating new operations, Operations, Operations
993
@comment  node-name,  next,  previous,  up
994
@subsection Predefined operations of ASDF
995

996
997
All the operations described in this section are in the @code{asdf} package.
They are invoked via the @code{operate} generic function.
998
999

@lisp
1000
(asdf:operate 'asdf:@var{operation-name} :@var{system-name} @{@var{operation-options ...}@})