asdf.texinfo 186 KB
Newer Older
1
2
3
4
5
6
7
8
\input texinfo          @c -*- texinfo -*-
@c %**start of header
@setfilename asdf.info
@settitle ASDF Manual
@c %**end of header

@c We use @&key, etc to escape & from TeX in lambda lists --
@c so we need to define them for info as well.
9
@macro AallowOtherKeys
10
11
&allow-other-keys
@end macro
12
@macro Aoptional
13
14
&optional
@end macro
15
@macro Arest
16
17
&rest
@end macro
18
@macro Akey
19
20
&key
@end macro
21
@macro Abody
22
23
24
25
26
27
28
29
30
31
32
33
34
&body
@end macro

@c for install-info
@dircategory Software development
@direntry
* asdf: (asdf).           Another System Definition Facility (for Common Lisp)
@end direntry

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

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-2014 Daniel Barlow and contributors.
39

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

42
This manual revised @copyright{} 2009-2014 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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120

@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@c Output the table of contents at the beginning.
@contents

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

@ifnottex

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

@insertcopying

@menu
* Introduction::
* Loading ASDF::
* Configuring ASDF::
* Using ASDF::
* Defining systems with defsystem::
* The object model of ASDF::
* Controlling where ASDF searches for systems::
* Controlling where ASDF saves compiled files::
* Error handling::
* Miscellaneous additional functionality::
* Getting the latest version::
* FAQ::
* TODO list::
* Inspiration::
* Concept Index::
* Function and Class Index::
* Variable Index::

@c @detailmenu
@c  --- The Detailed Node Listing ---

@c Defining systems with defsystem

@c * The defsystem form::
@c * A more involved example::
@c * The defsystem grammar::
@c * Other code in .asd files::

@c The object model of ASDF

@c * Operations::
@c * Components::
121
@c * Functions::
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154

@c Operations

@c * Predefined operations of ASDF::
@c * Creating new operations::

@c Components

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

@c properties

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

@c @end detailmenu
@end menu

@end ifnottex

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

@node Introduction, Loading ASDF, Top, Top
@comment  node-name,  next,  previous,  up
@chapter Introduction
@cindex ASDF-related features
@vindex *features*
@cindex Testing for ASDF
@cindex ASDF versions
@cindex :asdf
@cindex :asdf2
155
@cindex :asdf3
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174

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.
@xref{Using ASDF,,Loading a system},
to learn how to use ASDF to load a system.
@xref{Defining systems with defsystem},
to learn how to define a system of your own.
@xref{The object model of ASDF}, for a description of
the ASDF internals and how to extend ASDF.

@emph{Nota Bene}:
175
We have released ASDF 2.000 on May 31st 2010,
176
and ASDF 3.0.0 on May 15th 2013.
177
Releases of ASDF 2 and later have since then been included
178
179
180
in all actively maintained CL implementations that used to bundle ASDF 1,
plus some implementations that didn't use to,
and has been made to work with all actively used CL implementations and a few more.
181
@xref{FAQ,,``What has changed between ASDF 1 and ASDF 2?''}.
182
183
184
185
Furthermore, it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly.
For this reason, we have stopped supporting ASDF 1 and ASDF 2.
If you are using ASDF 1 or ASDF 2 and are experiencing any kind of issues or limitations,
we recommend you upgrade to ASDF 3
186
187
188
189
190
191
192
193
194
--- and we explain how to do that. @xref{Loading ASDF}.

Also note that ASDF is not to be confused with ASDF-Install.
ASDF-Install is not part of ASDF, but a separate piece of software.
ASDF-Install is also unmaintained and obsolete.
We recommend you use Quicklisp instead,
which works great and is being actively maintained.
If you want to download software from version control instead of tarballs,
so you may more easily modify it, we recommend clbuild.
195
196
197
198
199
200
201
202


@node Loading ASDF, Configuring ASDF, Introduction, Top
@comment  node-name,  next,  previous,  up
@chapter Loading ASDF
@vindex *central-registry*
@cindex link farm
@findex load-system
203
@findex require-system
204
205
206
207
208
209
210
211
212
213
214
215
216
@findex compile-system
@findex test-system
@cindex system directory designator
@findex operate
@findex oos

@c @menu
@c * Installing ASDF::
@c @end menu


@section Loading a pre-installed ASDF

217
Most recent Lisp implementations include a copy of ASDF 2, and soon ASDF 3.
218
219
220
You can usually load this copy using Common Lisp's @code{require} function:

@lisp
221
(require "asdf")
222
223
@end lisp

224
225
As of the writing of this manual,
the following implementations provide ASDF 2 this way:
226
abcl allegro ccl clisp cmucl ecl lispworks mkcl sbcl xcl.
227
The following implementation doesn't provide it yet but will in an upcoming release:
228
229
230
scl.
The following implementations are obsolete, not actively maintained,
and most probably will never bundle it:
231
cormanlisp gcl genera mcl.
232

233
If the implementation you are using doesn't provide ASDF 2 or ASDF 3,
234
235
236
237
238
239
240
241
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.

NB: all implementations except clisp also accept
@code{(require "ASDF")}, @code{(require 'asdf)} and @code{(require :asdf)}.
For portability's sake, you probably want to use @code{(require "asdf")}.
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266


@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
267
268
269
270
271
272
273
274
(when (find-package :asdf)
  (let ((ver (symbol-value (or (find-symbol (string :*asdf-version*) :asdf)
                               (find-symbol (string :*asdf-revision*) :asdf)))))
    (etypecase ver
      (string ver)
      (cons (with-output-to-string (s)
              (loop for (n . m) on ver do (princ n s) (when m (princ "." s)))))
      (null "1.0"))))
275
276
@end lisp

277
If it returns @code{nil} then ASDF is not installed.
278
279
280
Otherwise it should return a string.
If it returns @code{"1.0"}, then it can actually be
any version before 1.77 or so, or some buggy variant of 1.x.
281

282
283
284
285
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.
286
287
288
289


@section Upgrading ASDF

290
If your implementation provides ASDF 3 or later,
291
292
293
294
295
you only need to @code{(require "asdf")}:
ASDF will automatically look whether an updated version of itself is available
amongst the regularly configured systems, before it compiles anything else.
See @pxref{Configuring ASDF} below.

296
If your implementation does provide ASDF 2 or later,
297
but not ASDF 3 or later,
298
and you want to upgrade to a more recent version,
299
300
301
you need to install and configure your ASDF as above,
and additionally, you need to explicitly tell ASDF to load itself,
right after you require your implementation's old ASDF 2:
302
303

@lisp
304
(require "asdf")
305
306
307
308
(asdf:load-system :asdf)
@end lisp

If on the other hand, your implementation only provides an old ASDF,
309
310
311
you will require a special configuration step and an old-style loading.
Take special attention to not omit the trailing directory separator
@code{/} at the end of your pathname:
312
313

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

319
Note that ASDF 1 won't redirect its output files,
320
321
322
323
324
325
326
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.
327
328
329
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.
330

331
332
333
334
335
Finally, if you are using an unmaintained implementation
that does not provide ASDF at all,
see @pxref{Loading ASDF,,Loading an otherwise installed ASDF} below.

Note that there are some limitations to upgrading ASDF:
336
337
@itemize
@item
338
Previously loaded ASDF extension becomes invalid, and will need to be reloaded.
339
This applies to e.g. CFFI-Grovel, or to hacks used by ironclad, etc.
340
341
Since it isn't possible to automatically detect what extensions are present
that need to be invalidated,
342
ASDF will actually invalidate all previously loaded systems
343
344
345
when it is loaded on top of a different ASDF version,
starting with ASDF 2.014.8 (as far as releases go, 2.015);
and it will automatically attempt this self-upgrade as its very first step
346
starting with ASDF 3.
347

348
@item
349
350
351
For this an many other reasons,
it important reason to load, configure and upgrade ASDF (if needed)
as one of the very first things done by your build and startup scripts.
352
Until all implementations provide ASDF 3 or later,
353
it is safer if you upgrade ASDF and its extensions as a special step
354
at the very beginning of whatever script you are running,
355
356
357
358
before you start using ASDF to load anything else;
even afterwards, it is still a good idea, to avoid having to
load and reload code twice as it gets invalidated.

359
@item
360
Until all implementations provide ASDF 3 or later,
361
362
363
364
365
366
367
368
369
370
371
372
373
374
it is unsafe to upgrade ASDF as part of loading a system
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.
In the meantime, 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
375
@item
376
Until all implementations provide ASDF 3 or later,
377
378
379
380
381
it is unsafe for a system to transitively depend on ASDF
and not directly depend on ASDF;
if any of the system you use either depends-on asdf,
system-depends-on asdf, or transitively does,
you should also do as well.
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
@end itemize


@section Loading an otherwise installed ASDF

If your implementation doesn't include ASDF,
if for some reason the upgrade somehow fails,
does not or cannot apply to your case,
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

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

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


@node Configuring ASDF, Using ASDF, Loading ASDF, Top
@comment  node-name,  next,  previous,  up

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

Since ASDF 2, the preferred way to configure where ASDF finds your systems is
the @code{source-registry} facility,
fully described in its own chapter of this manual.
@xref{Controlling where ASDF searches for systems}.

The default location for a user to install Common Lisp software is under
@file{~/.local/share/common-lisp/source/}.
428
429
If you install software there (it can be a symlink),
you don't need further configuration.
430
431
If you're installing software yourself at a location that isn't standard,
you have to tell ASDF where you installed it. See below.
432
If you're using some tool to install software (e.g. Quicklisp),
433
434
435
the authors of that tool should already have configured ASDF.

The simplest way to add a path to your search path,
436
say @file{/home/luser/.asd-link-farm/}
437
438
is to create the directory
@file{~/.config/common-lisp/source-registry.conf.d/}
439
440
and there create a file with any name of your choice,
and with the type @file{conf},
441
for instance @file{42-asd-link-farm.conf}
442
443
containing the line:

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

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

449
@kbd{(:tree "/home/luser/lisp/")}
450
451
452
453

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

454
455
456
457
458
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
459
460
461
462
463
464
465
466
467
468
469
470
471
472
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:

@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.
473
474
Actually, you should use @code{(asdf:clear-configuration)}
before you dump your Lisp image, which includes the above.
475
476


477
@section Configuring ASDF to find your systems --- old style
478
479
480
481
482
483
484
485
486
487
488
489

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

490
The @code{asdf:*central-registry*} is empty by default in ASDF 2 or ASDF 3,
491
492
493
494
495
496
497
498
499
500
501
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
502
could after it loads ASDF with @code{(require "asdf")}
503
504
505
506
507
508
509
510
511
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{
512
513
ASDF will indeed call @code{eval} on each entry.
It will also skip entries that evaluate to @code{nil}.
514
515

Strings and pathname objects are self-evaluating,
516
in which case the @code{eval} step does nothing;
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
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
544
545
(on Windows, you can use Windows shortcuts instead of POSIX symlinks;
if you try aliases under MacOS, we are curious to hear about your experience).
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562

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

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.


@section Configuring where ASDF stores object files
563
@findex clear-output-translations
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585

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.

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

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/}
586
and there create a file with any name of your choice and the type @file{conf},
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
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{(t t)}

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

611
612
613
614
615
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
616
617
618
619
620
621
622
623
624
625
626
627
628
629
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:

@lisp
(asdf:clear-output-translations)
@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.
630
631
(Once again, you should use @code{(asdf:clear-configuration)}
before you dump your Lisp image, which includes the above.)
632
633
634
635
636
637

Finally note that before ASDF 2,
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.
638
cl-launch 3.000 and common-lisp-controller 7.2 have been updated
639
640
641
642
643
to just delegate this functionality to ASDF.

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

644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670

@section Resetting Configuration

When you dump and restore an image, or when you tweak your configuration,
you may want to reset the ASDF configuration.
For that you may use the following function:

@defun clear-configuration
   undoes any ASDF configuration,
   regarding source-registry or output-translations.
@end defun

If you use SBCL, CMUCL or SCL, you may use this snippet
so that the ASDF configuration be cleared automatically as you dump an image:

@example
#+(or cmu sbcl scl)
(pushnew 'clear-configuration
         #+(or cmu scl) ext:*before-save-initializations*
         #+sbcl sb-ext:*save-hooks*)
@end example

For compatibility with all Lisp implementations, however,
you might want instead your build script to explicitly call
@code{(asdf:clear-configuration)} at an appropriate moment before dumping.


671
672
673
674
675
676
677
678
679
680
681
@chapter Using ASDF

@section Loading a system

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

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

682
On some implementations (namely recent versions of
683
684
ABCL, Allegro CL, Clozure CL, CMUCL, ECL, GNU CLISP,
LispWorks, MKCL, SBCL and XCL),
685
686
687
688
689
690
691
692
693
694
ASDF hooks into the @code{CL:REQUIRE} facility
and you can just use:

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

In older versions of ASDF, you needed to use
@code{(asdf:oos 'asdf:load-op :@var{foo})}.
If your ASDF is too old to provide @code{asdf:load-system} though
695
we recommend that you upgrade to ASDF 3.
696
697
@xref{Loading ASDF,,Loading an otherwise installed ASDF}.

698
699
700
701
702
703
704
705
706
707
708
709
710
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

711
712
713
714
715

@section Other Operations

ASDF provides three commands for the most common system operations:
@code{load-system}, @code{compile-system} or @code{test-system}.
716
717
It also provides @code{require-system}, a version of @code{load-system}
that skips trying to update systems that are already loaded.
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734

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.

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.

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

735
736
@findex already-loaded-systems

737
738
For the advanced users, note that
@code{require-system} calls @code{load-system}
739
740
with keyword arguments @code{:force-not (already-loaded-systems)}.
@code{already-loaded-systems} returns a list of the names of loaded systems.
741
742
743
@code{load-system} applies @code{operate} with the operation from
@code{*load-system-operation*}, which by default is @code{load-op},
the system, and any provided keyword arguments.
744
745
746
747
748
749
750
751

@section Summary

To use ASDF:

@itemize
@item
Load ASDF itself into your Lisp image, either through
752
@code{(require "asdf")} or else through
753
754
755
756
757
758
759
@code{(load "/path/to/asdf.lisp")}.

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

@item
760
Load a system with @code{(asdf:load-system :my-system)}
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
or use some other operation on some system of your choice.

@end itemize

@section Moving on

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.


@node Defining systems with defsystem, The object model of ASDF, Using ASDF, Top
@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
* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
786
* The package-system extension::
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
@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

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

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

@lisp
(in-package :asdf)

(defsystem "hello-lisp"
  :description "hello-lisp: a sample Lisp system."
809
  :version "0.2.1"
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
  :author "Joe User <joe@@example.com>"
  :licence "Public Domain"
  :components ((:file "packages")
               (:file "macros" :depends-on ("packages"))
               (:file "hello" :depends-on ("macros"))))
@end lisp

Some notes about this example:

@itemize

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

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

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

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

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

865
866
867
868
@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
869
870
871
872
873
874
875
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},
876
even though the two are the same when interpreted as decimal fractions.
877
878
879
880
881
Instead of a string representing the version,
the @code{:version} argument can be an expression that is resolved to
such a string using the following trivial domain-specific language:
in addition to being a literal string, it can be an expression of the form
@code{(:read-file-form <pathname-or-string> :at <access-at-specifier>)},
882
which will be resolved by reading a form in the specified pathname
883
(read as a subpathname of the current system if relative or a unix-namestring).
884
885
886
You may use a @code{uiop:access-at} specifier
with the (optional) @code{:at} keyword,
by default the specifier is @code{0}, meaning the first form is returned.
887

888
889
@cindex :version

890
891
892
893
894
895
896
897
898
899
900
@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"
901
  :version "1.0.0"
902
903
904
905
906
907
908
909
910
  :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")))
911
912
@end lisp

913
914
915
916
917
918
919
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
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936

@lisp
                :perform (compile-op :after (op c)
                          (do-something c))
                :explain (compile-op :after (op c)
                          (explain-something c))
@end lisp

has the effect of

@lisp
(defmethod perform :after ((op compile-op) (c (eql ...)))
           (do-something c))
(defmethod explain :after ((op compile-op) (c (eql ...)))
           (explain-something c))
@end lisp

937
938
939
940
where @code{...} is the component in question.
In this case @code{...} would expand to something like

@lisp
941
(find-component "foo" "mod")
942
943
944
945
946
947
948
949
950
951
952
953
954
955
@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.
956
957
958
959
960

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

961
962
963
964
@c FIXME: @var typesetting not consistently used here.  We should either expand
@c its use to everywhere, or we should kill it everywhere.


965
@example
966
system-definition := ( defsystem system-designator @var{system-option}* )
967

968
969
system-option := :defsystem-depends-on system-list
                 | :weakly-depends-on @var{system-list}
970
                 | :class class-name (see discussion below)
971
972
973
974
975
976
977
                 | module-option
                 | option

module-option := :components component-list
                 | :serial [ t | nil ]

option :=
978
        | :pathname pathname-specifier
979
        | :default-component-class class-name
980
981
982
983
        | :perform method-form
        | :explain method-form
        | :output-files method-form
        | :operation-done-p method-form
984
        | :if-feature feature-expression
985
986
987
        | :depends-on ( @var{dependency-def}* )
        | :in-order-to ( @var{dependency}+ )

988
989
990

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

991
992
993
994
component-list := ( @var{component-def}* )

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

995
component-type := :module | :file | :static-file | other-component-type
996
997
998

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

999
1000
# This is used in :depends-on, as opposed to ``dependency,''
# which is used in :in-order-to
1001
dependency-def := simple-component-name
1002
               | (feature @var{feature-name})
1003
1004
               | ( :version simple-component-name version-specifier)

1005
1006
# ``dependency'' is used in :in-order-to, as opposed to
# ``dependency-def''
1007
1008
dependency := (dependent-op @var{requirement}+)
requirement := (required-op @var{required-component}+)
1009
             | (:feature @var{feature-name})
1010
dependent-op := operation-name
1011
required-op := operation-name
1012
1013
1014
1015
1016
1017

simple-component-name := string
                      |  symbol

pathname-specifier := pathname | string | symbol

1018
method-form := (operation-name qual lambda-list @Arest body)
1019
qual := method qualifier
1020
1021

component-dep-fail-option := :fail | :try-next | :ignore
1022
1023
1024

feature-expression := keyword | (:and @var{feature-expression}*)
                      | (:or @var{feature-expression}*) | (:not @var{feature-expression})
1025
1026
@end example

1027

1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
@subsection Component names

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

@subsection Component types

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

1041
1042
1043
@code{system} and its subclasses are @emph{not}
allowed as component types for such children components.

1044
1045
@subsection System class names

1046
1047
1048
1049
A system class name will be looked up
in the same way as a Component type (see above),
except that only @code{system} and its subclasses are allowed.
Typically, one will not need to specify a system
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
class name, unless using a non-standard system class defined in some
ASDF extension, typically loaded through @code{DEFSYSTEM-DEPENDS-ON},
see below.  For such class names in the ASDF package, we recommend that
the @code{:class} option be specified using a keyword symbol, such as

@example
:class :MY-NEW-SYSTEM-SUBCLASS
@end example

This practice will ensure that package name conflicts are avoided.
Otherwise, the symbol @code{MY-NEW-SYSTEM-SUBCLASS} will be read into
the current package @emph{before} it has been exported from the ASDF
extension loaded by @code{:defsystem-depends-on}, causing a name
conflict in the current package.

1065
@subsection Defsystem depends on
1066
@cindex :defsystem-depends-on
1067
1068
1069
1070
1071
1072
1073

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.

1074
@subsection Weakly depends on
1075
1076
@cindex :weakly-depends-on

1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
We do @emph{NOT} recommend you use this feature.
If you are tempted to write a system @var{foo}
that weakly-depends-on a system @var{bar},
we recommend that you should instead
write system @var{foo} in a parametric way,
and offer some special variable and/or some hook to specialize its behavior;
then you should write a system @var{foo+bar}
that does the hooking of things together.

The (deprecated) @code{:weakly-depends-on} option to @code{defsystem}
allows the programmer to specify another ASDF-defined system or set of systems
that ASDF should @emph{try} to load,
but need not load in order to be successful.
Typically this is used if there are a number of systems
that, if present, could provide additional functionality,
but which are not necessary for basic function.

Currently, although it is specified to be an option only to @code{defsystem},
this option is accepted at any component, but it probably
only makes sense at the @code{defsystem} level.
Programmers are cautioned not
1098
1099
1100
to use this component option except at the @code{defsystem} level, as
this anomalous behavior may be removed without warning.

1101
1102
1103
1104
1105
1106
1107
1108
Finally, you might look into the @code{asdf-system-connections} extension,
that will let you define additional code to be loaded
when two systems are simultaneously loaded.
It may or may not be considered good style, but at least it can be used
in a way that has deterministic behavior independent of load order,
unlike @code{weakly-depends-on}.


1109
@subsection Pathname specifiers
1110
@cindex pathname specifiers
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142

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

1143
1144
1145
1146
1147
1148
1149
1150
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.

1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
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.

1162
Pathname objects may be given to override the path for a component.
1163
1164
Such objects are typically specified using reader macros such as @code{#p}
or @code{#.(make-pathname ...)}.
1165
1166
Note however, that @code{#p...} is
a shorthand for @code{#.(parse-namestring ...)}
1167
and that the behavior of @code{parse-namestring} is completely non-portable,
1168
1169
unless you are using Common Lisp @code{logical-pathname}s,
which themselves involve other non-portable behavior
1170
(@pxref{The defsystem grammar,,Using logical pathnames}, below).
1171
1172
1173
1174
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.
1175
Therefore, pathname objects should only rarely be used.
1176
1177
1178
Unhappily, ASDF 1 didn't properly support
parsing component names as strings specifying paths with directories,
and the cumbersome @code{#.(make-pathname ...)} syntax had to be used.
1179
1180
An alternative to @code{#.} read-time evaluation is to use
@code{(eval `(defsystem ... ,pathname ...))}.
1181

1182
Note that when specifying pathname objects,
1183
1184
1185
ASDF does not do any special interpretation of the pathname
influenced by the component type, unlike the procedure for
pathname-specifying strings.
1186
1187
1188
1189
1190
1191
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.

1192
1193
1194
1195
@subsection Version specifiers
@cindex version specifiers
@cindex :version

1196
1197
1198
1199
1200
1201
1202
1203
Version specifiers are strings to be 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"},
though the latter is not canonical and may lead to a warning being issued.
Also, @code{"1.3"} and @code{"1.4"} are both strictly @code{uiop:version<} to @code{"1.30"},
quite unlike what would have happened
had the version strings been interpreted as decimal fractions.
1204
1205

System definers are encouraged to use version identifiers of the form
1206
1207
1208
@var{x}.@var{y}.@var{z} for
major version, minor version and patch level,
where significant API incompatibilities are signaled by an increased major number.
1209
1210
1211

@xref{Common attributes of components}.

1212

1213
@subsection Using logical pathnames
1214
@cindex logical pathnames
1215

1216
1217
1218
1219
We do not generally recommend the use of logical pathnames,
especially not so to newcomers to Common Lisp.
However, we do support the use of logical pathnames by old timers,
when such is their preference.
1220
1221
1222
1223
1224
1225

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

1226
1227
1228
1229
1230
You only have to specify such logical pathname
for your system or 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.
1231
1232
1233
1234
The specification of a logical pathname host however is @emph{not}
otherwise directly supported in the ASDF syntax
for pathname specifiers as strings.

1235
The @code{asdf-output-translation} layer will
1236
1237
1238
avoid trying to resolve and translate logical pathnames.
The advantage of this is that
you can define yourself what translations you want to use
1239
with the logical pathname facility.
1240
1241
The disadvantage is that if you do not define such translations,
any system that uses logical pathnames will behave differently under
1242
asdf-output-translations than other systems you use.
1243

1244
1245
1246
1247
If you wish to use logical pathnames you will have to configure the
translations yourself before they may be used.
ASDF currently provides no specific support
for defining logical pathname translations.
1248

1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
Note that the reasons we do not recommend logical pathnames are that
(1) there is no portable way to set up logical pathnames before they are used,
(2) logical pathnames are limited to only portably use
a single character case, digits and hyphens.
While you can solve the first issue on your own,
describing how to do it on each of fifteen implementations supported by ASDF
is more than we can document.
As for the second issue, mind that the limitation is notably enforced on SBCL,
and that you therefore can't portably violate the limitations
but must instead define some encoding of your own and add individual mappings
to name physical pathnames that do not fit the restrictions.
This can notably be a problem when your Lisp files are part of a larger project
in which it is common to name files or directories in a way that
includes the version numbers of supported protocols,
or in which files are shared with software written
in different programming languages where conventions include the use of
underscores, dots or CamelCase in pathnames.

1267
1268

@subsection Serial dependencies
1269
@cindex serial dependencies
1270
1271

If the @code{:serial t} option is specified for a module,
1272
ASDF will add dependencies for each child component,
1273
1274
1275
1276
1277
on all the children textually preceding it.
This is done as if by @code{:depends-on}.

@lisp
:serial t
1278
:components ((:file "a") (:file "b") (:file "c"))
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
@end lisp

is equivalent to

@lisp
:components ((:file "a")
             (:file "b" :depends-on ("a"))
             (:file "c" :depends-on ("a" "b")))
@end lisp


@subsection Source location

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

Instead, ASDF follows a hairy set of rules that are designed so that
@enumerate
@item
@code{find-system}
will load a system from disk
and have its pathname default to the right place.
1302

1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
@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.
@end enumerate

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

@itemize
@item
The host/device/directory parts of @code{*load-truename*},
if it is bound.
@item
@code{*default-pathname-defaults*}, otherwise.
@end itemize

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

@itemize
@item
changed, if explicitly supplied or obtained from @code{*load-truename*}
(so that an updated source location is reflected in the system definition)
1328

1329
1330
@item
changed if it had previously been set from @code{*default-pathname-defaults*}
1331

1332
1333
1334
1335
1336
1337
1338
@item
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)
@end itemize

1339
1340
1341
1342
1343
1344
1345
1346
@subsection if-feature option
This option allows you to specify a feature expression to be evaluated
as if by @code{#+} to conditionally include a component in your build.
If the expression is false, the component is dropped
as well as any dependency pointing to it.
As compared to using @code{#+} which is expanded at read-time,
this allows you to have an object in your component hierarchy
that can be used for manipulations beside building your project.
1347
This option was added in ASDF 3.
1348

1349
@subsection if-component-dep-fails option
1350
This option was removed in ASDF 3.
1351
1352
1353
Its semantics was limited in purpose and dubious to explain,
and its implementation was breaking a hole into the ASDF object model.
Please use the @code{if-feature} option instead.
1354

1355
@node Other code in .asd files, The package-system extension, The defsystem grammar, Defining systems with defsystem
1356
1357
1358
1359
@section Other code in .asd files

Files containing @code{defsystem} forms
are regular Lisp files that are executed by @code{load}.
1360
1361
1362
1363
1364
1365
1366
1367
1368
Consequently, you can put whatever Lisp code you like into these files.
However, it is recommended to keep such forms to a minimal,
and to instead define @code{defsystem} extensions
that you use with @code{:defsystem-depends-on}.

If however, you might insist on including code in the @code{.asd} file itself,
e.g., to examine and adjust the compile-time environment,
possibly adding appropriate features to @code{*features*}.
If so, here are some conventions we recommend you follow,
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
so that users can control certain details of execution
of the Lisp in @file{.asd} files:

@itemize
@item
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.
@end itemize


1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
@node The package-system extension,  , Other code in .asd files, Defining systems with defsystem
@section The package-system extension

Starting with ASDF 3.0.3,
ASDF supports a one-package-per-file style of programming,
whereby each file is its own system,
and dependencies are deduced from the @code{defpackage} form.

In this style, packages referring to a same-named system (downcased);
and if a system is defined with @code{:class package-system},
then system names that start with that name
(using the slash @code{/} separator)
refer to files under the filesystem hierarchy where the system is defined.
For instance, if system @code{my-lib} is defined in
@file{/foo/bar/my-lib/my-lib.asd}, then system @code{my-lib/src/utility}
will be found in file @file{/foo/bar/my-lib/src/utility.lisp}.

This style was made popular by @code{faslpath} and @code{quick-build} before,
and at the cost of a stricter package discipline,
seems to make for more maintainable code.
It is used by ASDF itself (starting with ASDF 3) and by @code{lisp-interface-library}.

To use this style, choose a toplevel system name, e.g. @code{my-lib},
and create a file @file{my-lib.asd}
with the @code{:class :package-system} option in its @code{defsystem}.
For instance:
@example
#-asdf (error "my-lib requires ASDF 3")
(defsystem my-lib
  :class :package-system
  :defsystem-depends-on (:asdf-package-system)
  :depends-on (:my-lib/src/all)
  :in-order-to ((test-op (load-op :my-lib/test/all)))
  :perform (test-op (o c) (symbol-call :my-lib/test/all :test-suite)))
(register-system-packages :closer-mop
 '(:c2mop :closer-common-lisp :c2cl :closer-common-lisp-user :c2cl-user))
@end example

In the code above, the
@code{:defsystem-depends-on (:asdf-package-system)} is
for compatibility with older versions of ASDF 3 (ASDF 2 not supported),
and requires the @code{asdf-package-system} library to be present
(it is implicitly provided by ASDF starting with ASDF 3.0.3).

The function @code{register-system-packages} has to be called to register
packages used or provided by your system and its components
where the name of the system that provides the package
is not the downcase of the package name.

File @file{my-lib/src/utility.lisp} might start with:

@example
(defpackage :my-lib/src/utility
  (:use :closer-common-lisp :my-lib/src/macros :my-lib/src/variables)
  (:import-from :cl-ppcre #:register-groups-bind)
  (:export #:foo #:bar))
@end example

And from the @code{:use} and @code{:import-from} clauses,
ASDF could tell that you depend on systems @code{closer-mop} (registered above),
@code{cl-ppcre} (package and system names match), and
@code{my-lib/src/macros} and @code{my-lib/src/variables}
(package and system names match, and they will be looked up hierarchically).

The form @code{uiop:define-package} is supported as well as @code{defpackage},
and has many options that prove useful in this context,
such as @code{:use-reexport} and @code{:mix-reexport}
that allow for ``inheritance'' of symbols being exported.

1452
1453
1454
1455
1456
1457
@node The object model of ASDF, Controlling where ASDF searches for systems, Defining systems with defsystem, Top
@comment  node-name,  next,  previous,  up
@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
1458
follow a extensible protocol.
1459

1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
This allows the addition of behaviours:
for example, @code{cffi} adds support of special FFI description files
to interface with C libraries and of wrapper files to embed C code in Lisp;
@code{abcl-jar} supports creating Java JAR archives in ABCL;
and @code{poiu} supports for compiling code in parallel using background processes.

This chapter deals with @code{component}s and @code{operation}s.

A @code{component} represents an individual source file or a group of source files,
and the things that get transformed into.
A @code{system} is a component at the top level of the component hierarchy.
A @code{source-file} is a component representing a single source-file
and the successive output files into which it is transformed.
A @code{module} is an intermediate component itself grouping several other components,
themselves source-files or further modules.

An @code{Operation} represents a transformation that can be performed on a component,
turning them from source files to intermediate results to final outputs.

A pair of an @code{operation} and a @code{component} is called an @code{action}.
An @code{action} represents a particular build step to be @code{perform}ed,
after all its dependencies have been fulfilled.
In the ASDF model, actions depend on other actions.
The term @emph{action} itself was used by Kent Pitman in his old article,
but was only used by ASDF hackers starting with the ASDF 2;
but the concept is ubiquitous since the very beginning of ASDF 1,
though previously implicit.

Then, there are many @emph{functions} available
to users, extenders and implementers of ASDF
to use, define or implement the activities
that are part of building your software.
Though they manipulate @code{action}s,
most of these functions do not take as an argument
1494
a reified pair (a @code{cons} cell) of an operation and a component;
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
instead, they usually take two separate arguments,
which allows to take advantage of the power CLOS-style multiple dispatch
for fun and profit.

There are many @emph{hooks} in which to add functionality,
by customizing the behavior of existing @emph{functions}.

Last but not least is the notion of @emph{dependency} between two actions.
The structure of dependencies between actions is
a directed @emph{dependency graph}.
ASDF is invoked by being told to @emph{operate}
with some @emph{operation} on some toplevel @emph{system};
it will then @emph{traverse} the graph and build a @emph{plan}
that follows its structure.
To be successfully buildable, this graph of actions but be acyclic.
If, as a user, extender or implementer of ASDF, you fail
to keep the dependency graph without cycles,
ASDF will fail loudly as it eventually finds one.
To clearly distinguish the direction of dependencies,
1514
ASDF 3 uses the words @emph{requiring} and @emph{required}
1515
as applied to an action depending on the other:
1516
the requiring action @code{depends-on} the completion of all required actions
1517
1518
before it may itself be @code{perform}ed.

1519
Using the @code{defsystem} syntax, users may easily express
1520
1521
1522
1523
direct dependencies along the graph of the object hierarchy:
between a component and its parent, its children, and its siblings.
By defining custom CLOS methods, you can express more elaborate dependencies as you wish.
Most common operations, such as @code{load-op}, @code{compile-op} or @code{load-source-op}
1524
are automatically propagate ``downward'' the component hierarchy and are ``covariant'' with it:
1525
1526
to act the operation on the parent module, you must first act it on all the children components,
with the action on the parent being parent of the action on each child.
1527
1528
1529
1530
1531
1532
Other operations, such as @code{prepare-op} and @code{prepare-source-op}
(introduced in ASDF 3) are automatically propagated ``upward'' the component hierarchy
and are ``contravariant'' with it:
to perform the operation of preparing for compilation of a child component,
you must perform the operation of preparing for compilation of its parent component, and so on,
ensuring that all the parent's dependencies are (compiled and) loaded
1533
1534
before the child component may be compiled and loaded.
Yet other operations, such as @code{test-op} or @code{load-fasl-op}
1535
1536
remain at the system level, and are not propagated along the hierarchy,
but instead do something global on the system.
1537
1538
1539
1540

@menu
* Operations::
* Components::
1541
* Functions::
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
@end menu

@node  Operations, Components, The object model of ASDF, The object model of ASDF
@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

Operations can be invoked directly, or examined
to see what their effects would be without performing them.
There are a bunch of methods specialised on operation and component type
that actually do the grunt work.

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.

Operations are invoked on systems via @code{operate}.
@anchor{operate}
1570
1571
@deffn {Generic function} @code{operate} @var{operation} @var{system} @Arest @var{initargs} @Akey @code{force} @code{force-not} @code{verbose} @AallowOtherKeys
@deffnx {Generic function} @code{oos} @var{operation} @var{system} @Arest @var{initargs} @Akey @AallowOtherKeys
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
@code{operate} invokes @var{operation} on @var{system}.
@code{oos} is a synonym for @code{operate}.

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

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.

1586
If @var{force} is @code{:all}, then all systems
1587
are forced to be recompiled even if not modified since last compilation.
1588
1589
1590
If @var{force} is @code{t}, then only the system being loaded
is forced to be recompiled even if not modified since last compilation,
but other systems are not affected.
1591
1592
If @var{force} is a list, then it specifies a list of systems that
are forced to be recompiled even if not modified since last compilation.
1593
If @var{force-not} is @code{:all}, then all systems
1594
are forced not to be recompiled even if modified since last compilation.
1595
1596
1597
If @var{force-not} is @code{t}, then only the system being loaded
is forced not to be recompiled even if modified since last compilation,
but other systems are not affected.
1598
1599
1600
1601
If @var{force-not} is a list, then it specifies a list of systems that
are forced not to be recompiled even if modified since last compilation.
@var{force} takes precedences over @var{force-not};
both of them apply to systems that are dependencies and were already compiled.
1602
1603
1604

To see what @code{operate} would do, you can use:
@example
1605
(asdf:traverse operation-class system-name)
1606
1607
@end example

1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
@end deffn

@menu
* Predefined operations of ASDF::
* Creating new operations::
@end menu

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

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

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

1626
@deffn Operation @code{compile-op}
1627
1628

This operation compiles the specified component.
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
A @code{cl-source-file} will be @code{compile-file}'d.
All the children and dependencies of a system or module
will be recursively compiled by @code{compile-op}.

@code{compile-op} depends on @code{prepare-op} which
itself depends on a @code{load-op} of all of a component's dependencies,
as well as of its parent's dependencies.
When @code{operate} is called on @code{compile-op},
all these dependencies will be loaded as well as compiled;
yet, some parts of the system main remain unloaded,
because nothing depends on them.
Use @code{load-op} to load a system.
1641
1642
@end deffn

1643
@deffn Operation @code{load-op}
1644

1645
1646
1647
1648
1649
This operation loads the compiled code for a specified component.
A @code{cl-source-file} will have its compiled fasl @code{load}ed,
which fasl is the output of @code{compile-op} that @code{load-op} depends on.
All the children and dependencies of a system or module
will be recursively loaded by @code{load-op}.
1650

1651
1652
1653
@code{load-op} depends on @code{prepare-op} which
itself depends on a @code{load-op} of all of a component's dependencies,
as well as of its parent's dependencies.
1654
1655
@end deffn

1656
@deffn Operation @code{prepare-op}
1657

1658
1659
1660
1661
This operation ensures that the dependencies of a component
and its recursive parents are loaded (as per @code{load-op}),
as a prerequisite before @code{compile-op} and @code{load-op} operations
may be performed on a given component.
1662
1663
@end deffn