asdf.texinfo 134 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
36
37
You can find the latest version of this manual at
@url{http://common-lisp.net/project/asdf/asdf.html}.

38
ASDF Copyright @copyright{} 2001-2011 Daniel Barlow and contributors.
39

40
This manual Copyright @copyright{} 2001-2011 Daniel Barlow and contributors.
41

42
This manual revised @copyright{} 2009-2011 Robert P. Goldman and Francois-Rene Rideau.
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

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
68
@title ASDF: Another System Definition Facility
69

70
71
72
73
74
@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
75

76
77
78
79
80
81
82
@c Output the table of contents at the beginning.
@contents

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

@ifnottex

83
@node Top, Introduction, (dir), (dir)
84
@top asdf: another system definition facility
85

86
87
88
@insertcopying

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

107
108
@c @detailmenu
@c  --- The Detailed Node Listing ---
109

110
@c Defining systems with defsystem
111

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

117
@c The object model of ASDF
118

119
120
@c * Operations::
@c * Components::
121

122
@c Operations
123

124
125
@c * Predefined operations of ASDF::
@c * Creating new operations::
126

127
@c Components
128

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

133
@c properties
134

135
136
@c * Pre-defined subclasses of component::
@c * Creating new component types::
137

138
@c @end detailmenu
139
140
141
142
143
144
@end menu

@end ifnottex

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

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

155
156
157
158
159
160
161
162
163
164
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
165
@xref{Using ASDF,,Loading a system},
166
to learn how to use ASDF to load a system.
Robert P. Goldman's avatar
Robert P. Goldman committed
167
@xref{Defining systems with defsystem},
168
to learn how to define a system of your own.
169
@xref{The object model of ASDF}, for a description of
Robert P. Goldman's avatar
Robert P. Goldman committed
170
the ASDF internals and how to extend ASDF.
171

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
172
@emph{Nota Bene}:
173
174
175
We have released ASDF 2.000 on May 31st 2010.
It hopefully will have been it included
in all CL maintained implementations shortly afterwards.
176
@xref{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
@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

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
205
206
207
208
209
210
211
212
213
214
215
216
217
As of the writing of this manual,
the following implementations provide ASDF 2 this way:
abcl allegro ccl clisp cmucl ecl sbcl xcl.
The following implementations don't provide it yet but might in a future release:
lispworks scl.
The following implementations are obsolete and most probably will never bundle it:
cormancl gcl genera mcl.

If the implementation you are using doesn't provide ASDF 2,
see @pxref{Loading ASDF,,Loading an otherwise installed ASDF} below.
If that implementation is still actively maintained,
you may also send a bug report to your Lisp vendor and complain
about their failing to provide ASDF.
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242


@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
243
(or #+asdf2 (asdf:asdf-version) #+asdf :old)
244
245
246
247
@end lisp

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

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
251
252
253
254
If you are experiencing problems with ASDF,
please try upgrading to the latest released version,
using the method below,
before you contact us and raise an issue.
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
280
281
282
283
284
285
286
287
288
289
@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.
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
290
291
292
Note that to our knowledge all implementations that provide ASDF
provide ASDF 2 in their latest release, so
you may want to upgrade your implementation rather than go through that hoop.
293

294
295
296
Finally, note that there are some limitations to upgrading ASDF:
@itemize
@item
297
Any ASDF extension becomes invalid, and will need to be reloaded.
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
298
This applies to e.g. CFFI-Grovel, or to hacks used by ironclad, etc.
299
300
301
Starting with ASDF 2.014.8, ASDF will actually invalidate
all previously loaded systems when it is loaded on top of
a different ASDF version.
302
@item
303
304
Until all implementations provide ASDF 2.015 or later,
it is safer if you upgrade ASDF and its extensions as a special step
305
306
at the very beginning of whatever script you are running,
before you start using ASDF to load anything else.
307
@item
308
309
Until all implementations provide ASDF 2.015 or later,
it is unsafe to upgrade ASDF as part of loading a system
310
311
312
313
314
315
316
317
318
319
320
321
322
that depends on a more recent version of ASDF,
since the new one might shadow the old one while the old one is running,
and the running old one will be confused
when extensions are loaded into the new one.
We recommend that your systems should @emph{not} specify
@code{:depends-on (:asdf)}, or @code{:depends-on ((:version :asdf "2.010"))},
but instead that they check that a recent enough ASDF is installed,
with such code as:
@example
(unless (or #+asdf2 (asdf:version-satisfies
                     (asdf:asdf-version) *required-asdf-version*))
  (error "FOO requires ASDF ~A or later." *required-asdf-version*))
@end example
323
324
@end itemize

325

326
327
328
@section Loading an otherwise installed ASDF

If your implementation doesn't include ASDF,
329
330
if for some reason the upgrade somehow fails,
does not or cannot apply to your case,
331
332
333
334
335
336
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
337

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

340
You can extract this file from latest release tarball on the
341
@url{http://common-lisp.net/project/asdf/,ASDF website}.
342
If you are daring and willing to report bugs, you can get
343
the latest and greatest version of ASDF from its git repository.
344
345
346
347
348
349
350
@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.

351

352
353
@node Configuring ASDF, Using ASDF, Loading ASDF, Top
@comment  node-name,  next,  previous,  up
354
355
356
357
358
359
360
361

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

362
Since ASDF 2, the preferred way to configure where ASDF finds your systems is
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
363
364
365
the @code{source-registry} facility,
fully described in its own chapter of this manual.
@xref{Controlling where ASDF searches for systems}.
366
367
368
369
370
371
372
373
374
375

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,
376
say @file{/home/luser/.asd-link-farm/}
377
378
is to create the directory
@file{~/.config/common-lisp/source-registry.conf.d/}
379
and there create a file with any name of your choice but the type @file{conf},
380
for instance @file{42-asd-link-farm.conf}
381
382
containing the line:

383
@kbd{(:directory "/home/luser/.asd-link-farm/")}
384

385
If you want all the subdirectories under @file{/home/luser/lisp/}
386
387
to be recursively scanned for @file{.asd} files, instead use:

388
@kbd{(:tree "/home/luser/lisp/")}
389
390
391
392

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

393
394
395
396
397
The required @file{.conf} extension allows you to have disabled files
or editor backups (ending in @file{~}), and works portably
(for instance, it is a pain to allow both empty and non-empty extension on CLISP).
Excluded are files the name of which start with a @file{.} character.
It is customary to start the filename with two digits
398
399
400
401
402
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:
403

404
405
406
407
408
409
410
411
412
413
@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
414
@section Configuring ASDF to find your systems -- old style
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
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484

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
485
486
487
488
489
490
491
492
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

493
494
495
496
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.

497

498
@section Configuring where ASDF stores object files
499
@findex clear-output-locations
500
501
502
503
504
505
506
507
508
509
510
511

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.

512
Starting with ASDF 2, the @code{asdf-output-translations} facility
513
was added to ASDF itself, that controls where object files will be stored.
514
This facility is fully described in a chapter of this manual,
515
@ref{Controlling where ASDF saves compiled files}.
516
517
518
519
520
521

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/}
522
and there create a file with any name of your choice and the type @file{conf},
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
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:

539
@kbd{(t t)}
540
541
542
543
544

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/}.
545
@xref{Controlling where ASDF searches for systems}, for full details.
546

547
548
549
550
551
The required @file{.conf} extension allows you to have disabled files
or editor backups (ending in @file{~}), and works portably
(for instance, it is a pain to allow both empty and non-empty extension on CLISP).
Excluded are files the name of which start with a @file{.} character.
It is customary to start the filename with two digits
552
553
554
555
556
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:
557
558

@lisp
559
(asdf:clear-output-translations)
560
561
@end lisp

562
563
564
565
566
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.

567
Finally note that before ASDF 2,
568
569
570
571
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.
572
cl-launch 3.000 and common-lisp-controller 7.2 have been updated
573
to just delegate this functionality to ASDF.
574

575
576
@node Using ASDF, Defining systems with defsystem, Configuring ASDF, Top
@comment  node-name,  next,  previous,  up
577

578
579
580
581
582
583
@chapter Using ASDF

@section Loading a system

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

@example
586
(asdf:load-system :@var{foo})
587
588
@end example

589
590
On some implementations (namely recent versions of
ABCL, Clozure CL, CLISP, CMUCL, ECL, SBCL and SCL),
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
591
592
593
594
595
596
597
ASDF hooks into the @code{CL:REQUIRE} facility
and you can just use:

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

598
599
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
600
601
If your ASDF is too old to provide @code{asdf:load-system} though
we recommend that you upgrade to ASDF 2.
602
@xref{Loading ASDF,,Loading an otherwise installed ASDF}.
603

604
605
606
607
608
609
610
611
612
613
614
615
616
Note the name of a system is specified as a string or a symbol,
typically a keyword.
If a symbol (including a keyword), its name is taken and lowercased.
The name must be a suitable value for the @code{:name} initarg
to @code{make-pathname} in whatever filesystem the system is to be found.
The lower-casing-symbols behaviour 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},
which is reported not to work on some implementations

617

618
@section Other Operations
619

620
621
ASDF provides three commands for the most common system operations:
@code{load-system}, @code{compile-system} or @code{test-system}.
622

623
624
625
626
627
628
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.
629

630
631
632
633
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.
634

635
636
Reminder: before ASDF can operate on a system, however,
it must be able to find and load that system's definition.
637
@xref{Configuring ASDF,,Configuring ASDF to find your systems}.
638
639


640
641
642
643
644
@section Summary

To use ASDF:

@itemize
645
@item
646
647
648
Load ASDF itself into your Lisp image, either through
@code{(require :asdf)} or else through
@code{(load "/path/to/asdf.lisp")}.
649

650
@item
651
652
Make sure ASDF can find system definitions
thanks to proper source-registry configuration.
653

654
@item
655
656
Load a system with @code{(load-system :my-system)}
or use some other operation on some system of your choice.
657
658
659

@end itemize

660
@section Moving on
661

662
663
664
665
666
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.

667

668
@node Defining systems with defsystem, The object model of ASDF, Using ASDF, Top
669
670
671
672
673
674
675
676
@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
677
678
679
680
* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
681
682
683
684
685
686
@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

687
688
689
690
691
692
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}.
693

694
695
Let's look at a simple system.
This is a complete file that would
696
usually be saved as @file{hello-lisp.asd}:
697
698

@lisp
699
(in-package :asdf)
700

701
(defsystem "hello-lisp"
702
  :description "hello-lisp: a sample Lisp system."
703
  :version "0.2.1"
704
705
706
707
708
  :author "Joe User <joe@@example.com>"
  :licence "Public Domain"
  :components ((:file "packages")
               (:file "macros" :depends-on ("packages"))
               (:file "hello" :depends-on ("macros"))))
709
710
711
712
713
@end lisp

Some notes about this example:

@itemize
714
715

@item
716
717
718
719
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}.
720

721
@item
722
723
724
725
726
727
728
729
730
731
732
733
734
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
735
736

@item
737
738
739
The @code{defsystem} form defines a system named @code{hello-lisp}
that contains three source files:
@file{packages}, @file{macros} and @file{hello}.
740

741
742
743
744
745
746
747
@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}.
748
749

@item
750
751
752
753
754
755
756
757
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.
758

759
760
761
762
763
764
765
766
767
768
769
770
771
@c FIXME: Should have cross-reference to "Version specifiers" in the
@c defsystem grammar, but the cross-referencing is so broken by
@c insufficient node breakdown that I have not put one in.
@item
Make sure you know how the @code{:version} numbers will be parsed!  They
are parsed as period-separated lists of integers.  I.e., in the example,
@code{0.2.1} is to be interpreted, roughly speaking, as @code{(0 2 1)}.
In particular, version @code{0.2.1} is interpreted the same as
@code{0.0002.1} and is strictly version-less-than version @code{0.20.1},
even though the two are the same when interpreted as decimal fractions.
@cindex version specifiers
@cindex :version

772
773
774
775
776
777
778
779
780
781
782
@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"
783
  :version "1.0.0"
784
785
786
787
788
789
790
791
792
  :components ((:module "mod"
                            :components ((:file "bar")
                                                  (:file"baz")
                                                  (:file "quux"))
                            :perform (compile-op :after (op c)
                                                  (do-something c))
                            :explain (compile-op :after (op c)
                                            (explain-something c)))
                         (:file "blah")))
793
794
@end lisp

795
796
797
798
799
800
801
The @code{:module} component named @code{"mod"} is a collection of three files,
which will be located in a subdirectory of the main code directory named
@file{mod} (this location can be overridden; see the discussion of the
@code{:pathname} option in @ref{The defsystem grammar}).

The method-form tokens provide a shorthand for defining methods on
particular components.  This part
802
803

@lisp
804
805
806
807
                :perform (compile-op :after (op c)
                          (do-something c))
                :explain (compile-op :after (op c)
                          (explain-something c))
808
809
810
811
812
813
@end lisp

has the effect of

@lisp
(defmethod perform :after ((op compile-op) (c (eql ...)))
814
           (do-something c))
815
(defmethod explain :after ((op compile-op) (c (eql ...)))
816
           (explain-something c))
817
818
@end lisp

819
where @code{...} is the component in question.
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
820
In this case @code{...} would expand to something like
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837

@lisp
(find-component (find-system "foo") "mod")
@end lisp

For more details on the syntax of such forms, see @ref{The defsystem
grammar}.
For more details on what these methods do, @pxref{Operations} in
@ref{The object model of ASDF}.

@c The following plunge into the weeds is not appropriate in this
@c location. [2010/10/03:rpg]
@c note that although this also supports @code{:before} methods,
@c they may not do what you want them to ---
@c a @code{:before} method on perform @code{((op compile-op) (c (eql ...)))}
@c will run after all the dependencies and sub-components have been processed,
@c but before the component in question has been compiled.
838

839
@node  The defsystem grammar, Other code in .asd files, A more involved example, Defining systems with defsystem
840
841
842
@comment  node-name,  next,  previous,  up
@section The defsystem grammar

843
844
845
@c FIXME: @var typesetting not consistently used here.  We should either expand
@c its use to everywhere, or we should kill it everywhere.

846

847
@example
848
849
850
851
852
853
854
855
system-definition := ( defsystem system-designator @var{system-option}* )

system-option := :defsystem-depends-on system-list
                 | module-option
                 | option

module-option := :components component-list
                 | :serial [ t | nil ]
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
856
                 | :if-component-dep-fails component-dep-fail-option
857

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
858
option :=
859
        | :pathname pathname-specifier
860
        | :default-component-class class-name
861
        | :perform method-form
862
        | :explain method-form
863
        | :output-files method-form
864
        | :operation-done-p method-form
865
866
        | :depends-on ( @var{dependency-def}* )
        | :in-order-to ( @var{dependency}+ )
867

868

869
870
system-list := ( @var{simple-component-name}* )

871
component-list := ( @var{component-def}* )
872

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

875
component-type := :system | :module | :file | :static-file | other-component-type
876

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

Gary King's avatar
Gary King committed
879
880
881
882
dependency-def := simple-component-name
               | ( :feature name )
               | ( :version simple-component-name version-specifier)

883
884
dependency := (dependent-op @var{requirement}+)
requirement := (required-op @var{required-component}+)
885
886
887
             | (feature feature-name)
dependent-op := operation-name
required-op := operation-name | feature
Gary King's avatar
Gary King committed
888
889
890

simple-component-name := string
                      |  symbol
891

892
893
pathname-specifier := pathname | string | symbol

894
method-form := (operation-name qual lambda-list @&rest body)
895
qual := method qualifier
896
897

component-dep-fail-option := :fail | :try-next | :ignore
898
@end example
899

900

901
902
@subsection Component names

903
904
Component names (@code{simple-component-name})
may be either strings or symbols.
905

906
@subsection Component types
907
908
909
910
911
912
913

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

914
915
916
917
918
919
920
921
@subsection Defsystem depends on

The @code{:defsystem-depends-on} option to @code{defsystem} allows the
programmer to specify another ASDF-defined system or set of systems that
must be loaded @emph{before} the system definition is processed.
Typically this is used to load an ASDF extension that is used in the
system definition.

922
@subsection Pathname specifiers
923
@cindex pathname specifiers
924

925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
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"}.

956
957
958
959
960
961
962
963
ASDF does not interpret the string @code{".."} to designate the parent
directory.  This string will be passed through to the underlying
operating system for interpretation.  We @emph{believe} that this will
work on all platforms where ASDF is deployed, but do not guarantee this
behavior.  A pathname object with a relative directory component of
@code{:up} or @code{:back} is the only guaranteed way to specify a
parent directory.

964
965
966
967
968
969
970
971
972
973
974
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.

975
Pathname objects may be given to override the path for a component.
976
977
Such objects are typically specified using reader macros such as @code{#p}
or @code{#.(make-pathname ...)}.
978
979
980
981
Note however, that @code{#p...} is a shorthand for @code{#.(parse-namestring ...)}
and that the behavior of @code{parse-namestring} is completely non-portable,
unless you are using Common Lisp @code{logical-pathname}s
(@pxref{The defsystem grammar,,Warning about logical pathnames}, below).
982
983
984
985
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.
986
Therefore, pathname objects should only rarely be used.
987
Unhappily, ASDF 1 didn't properly support
988
989
parsing component names as strings specifying paths with directories,
and the cumbersome @code{#.(make-pathname ...)} syntax had to be used.
990

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
991
Note that when specifying pathname objects,
992
993
994
ASDF does not do any special interpretation of the pathname
influenced by the component type, unlike the procedure for
pathname-specifying strings.
995
996
997
998
999
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.
1000

1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
@subsection Version specifiers
@cindex version specifiers
@cindex :version

Version specifiers are parsed as period-separated lists of integers.  I.e., in the example,
@code{0.2.1} is to be interpreted, roughly speaking, as @code{(0 2 1)}.
In particular, version @code{0.2.1} is interpreted the same as
@code{0.0002.1} and is strictly version-less-than version @code{0.20.1},
even though the two are the same when interpreted as decimal fractions.

System definers are encouraged to use version identifiers of the form
@var{x}.@var{y}.@var{z} for major version, minor version (compatible
API) and patch level.

@xref{Common attributes of components}.

1017
1018

@subsection Warning about logical pathnames
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
1019
@cindex logical pathnames
1020

1021
1022
1023
We recommend that you not use logical pathnames
in your asdf system definitions at this point,
but logical pathnames @emph{are} supported.
1024

1025
1026
1027
1028
1029
1030
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
1031
1032
1033
some top-level component.  Sub-components' relative pathnames, specified
using the string syntax
for names, will be properly merged with the pathnames of their parents.
1034
1035
1036
The specification of a logical pathname host however is @emph{not}
otherwise directly supported in the ASDF syntax
for pathname specifiers as strings.
1037

1038
1039
1040
The @code{asdf-output-translation} layer will
avoid trying to resolve and translate logical-pathnames.
The advantage of this is that you can define yourself what translations you want to use
1041
with the logical pathname facility.
1042
The disadvantage is that if you do not define such translations, any
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
1043
system that uses logical pathnames will behave differently under
1044
asdf-output-translations than other systems you use.
1045

1046
If you wish to use logical pathnames you will have to configure the
1047
1048
1049
translations yourself before they may be used.
ASDF currently provides no specific support
for defining logical pathname translations.
1050
1051


1052
@subsection Serial dependencies
1053
@cindex serial dependencies
1054

1055
If the @code{:serial t} option is specified for a module,
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
1056
ASDF will add dependencies for each child component,
1057
1058
on all the children textually preceding it.
This is done as if by @code{:depends-on}.
1059
1060
1061

@lisp
:serial t
1062
:components ((:file "a") (:file "b") (:file "c"))
1063
1064
1065
1066
1067
@end lisp

is equivalent to

@lisp
1068
:components ((:file "a")
1069
1070
             (:file "b" :depends-on ("a"))
             (:file "c" :depends-on ("a" "b")))
1071
1072
1073
1074
1075
1076
@end lisp


@subsection Source location

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

1080
Instead, ASDF follows a hairy set of rules that are designed so that
1081
@enumerate
1082
@item
Francois-Rene Rideau's avatar
1.647:    
Francois-Rene Rideau committed
1083
1084
@code{find-system}
will load a system from disk
1085
1086
1087
1088
1089
1090
1091
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.
1092
1093
@end enumerate

1094
1095
If a system is being loaded for the first time,
its top-level pathname will be set to:
1096
1097

@itemize
1098
1099
1100
1101
1102
@item
The host/device/directory parts of @code{*load-truename*},
if it is bound.
@item
@code{*default-pathname-defaults*}, otherwise.
1103
1104
1105
1106
1107
1108
@end itemize

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

@itemize
@item
1109
1110
changed, if explicitly supplied or obtained from @code{*load-truename*}
(so that an updated source location is reflected in the system definition)
1111
@item
1112
changed if it had previously been set from @code{*default-pathname-defaults*}
1113
@item
1114
1115
1116
1117
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)
1118
1119
@end itemize

1120
1121
1122
1123
1124
1125
1126
@subsection if-component-dep-fails option

This option is only appropriate for module components (including
systems), not individual source files.

For more information about this option, @pxref{Pre-defined subclasses of component}.

1127
@node Other code in .asd files,  , The defsystem grammar, Defining systems with defsystem
1128
1129
@section Other code in .asd files

1130
1131
1132
1133
1134
1135
1136
1137
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:
1138
1139
1140

@itemize
@item
1141
1142
1143
1144
1145
1146
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.
1147
@end itemize
1148
1149


1150
@node The object model of ASDF, Controlling where ASDF searches for systems, Defining systems with defsystem, Top
1151
@comment  node-name,  next,  previous,  up
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
@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.
1165
1166
1167
1168



@menu
1169
1170
* Operations::
* Components::
1171
1172
@end menu

1173
@node  Operations, Components, The object model of ASDF, The object model of ASDF
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
@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

1187
1188
1189
1190
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
1191
1192
that actually do the grunt work.

1193
1194
1195
1196
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.
1197
1198

Operations are invoked on systems via @code{operate}.
1199
@anchor{operate}
1200
1201
@deffn {Generic function} @code{operate} @var{operation} @var{system} @&rest @var{initargs}
@deffnx {Generic function} @code{oos} @var{operation} @var{system} @&rest @var{initargs}
1202
1203
@code{operate} invokes @var{operation} on @var{system}.
@code{oos} is a synonym for @code{operate}.
1204
1205
1206
1207
1208

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

1209
1210
1211
1212
1213
1214
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.
1215
1216
1217
1218

@end deffn

@menu
1219
1220
* Predefined operations of ASDF::
* Creating new operations::
1221
1222
@end menu

1223
@node Predefined operations of ASDF, Creating new operations, Operations, Operations
1224
@comment  node-name,  next,  previous,  up
1225
@subsection Predefined operations of ASDF
1226

1227
1228
All the operations described in this section are in the @code{asdf} package.
They are invoked via the @code{operate} generic function.
1229
1230

@lisp
1231
(asdf:operate 'asdf:@var{operation-name} :@var{system-name} @{@var{operation-options ...}@})
1232
1233
@end lisp

1234
@deffn Operation @code{compile-op} @&key @code{proclamations}
1235

1236
1237
1238
This operation compiles the specified component.
If proclamations are supplied, they will be proclaimed.
This is a good place to specify optimization settings.
1239

1240
1241
When creating a new component type,
you should provide methods for @code{compile-op}.
1242

1243
1244
1245
1246
1247
1248
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.
1249
1250
@end deffn

1251
@deffn Operation @code{load-op} @&key @code{proclamations}
1252
1253
1254
1255

This operation loads a system.

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

1259
@deffn Operation @code{load-source-op}
1260

1261
1262
1263
1264
1265
1266
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.
1267

1268
1269
If you are creating a component type,
you need to implement this operation --- at least, where meaningful.
1270
1271
@end deffn

1272
@anchor{test-op}
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
@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
1289
1290
@end deffn

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
1291
@c @deffn Operation test-system-version @&key minimum
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303

@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)
1304
1305
1306
1307
1308
@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))))))
1309
@c     (and (= (car x) (car y))
1310
@c       (or (not (cdr y)) (bigger (cdr x) (cdr y))))))
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
@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