asdf.info 274 KB
Newer Older
1
This is asdf.info, produced by makeinfo version 6.3 from asdf.texinfo.
Raymond Toy's avatar
Raymond Toy committed
2

3
4
This manual describes ASDF, a system definition facility for Common Lisp
programs and libraries.
Raymond Toy's avatar
Raymond Toy committed
5
6

   You can find the latest version of this manual at
7
<https://common-lisp.net/project/asdf/asdf.html>.
Raymond Toy's avatar
Raymond Toy committed
8

Raymond Toy's avatar
Raymond Toy committed
9
   ASDF Copyright (C) 2001-2016 Daniel Barlow and contributors.
Raymond Toy's avatar
Raymond Toy committed
10

Raymond Toy's avatar
Raymond Toy committed
11
   This manual Copyright (C) 2001-2016 Daniel Barlow and contributors.
Raymond Toy's avatar
Raymond Toy committed
12

Raymond Toy's avatar
Raymond Toy committed
13
   This manual revised (C) 2009-2016 Robert P. Goldman and Francois-Rene
14
Rideau.
Raymond Toy's avatar
Raymond Toy committed
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

   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.

35
36
37
38
39
INFO-DIR-SECTION Software development
START-INFO-DIR-ENTRY
* asdf: (asdf).           Another System Definition Facility (for Common Lisp)
END-INFO-DIR-ENTRY

Raymond Toy's avatar
Raymond Toy committed
40
41
42

File: asdf.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)

43
ASDF: Another System Definition Facility
Raymond Toy's avatar
Raymond Toy committed
44
45
****************************************

46
Manual for Version 3.2.1
47
48

   This manual describes ASDF, a system definition facility for Common
Raymond Toy's avatar
Raymond Toy committed
49
50
51
Lisp programs and libraries.

   You can find the latest version of this manual at
52
<https://common-lisp.net/project/asdf/asdf.html>.
Raymond Toy's avatar
Raymond Toy committed
53

Raymond Toy's avatar
Raymond Toy committed
54
   ASDF Copyright (C) 2001-2016 Daniel Barlow and contributors.
Raymond Toy's avatar
Raymond Toy committed
55

Raymond Toy's avatar
Raymond Toy committed
56
   This manual Copyright (C) 2001-2016 Daniel Barlow and contributors.
Raymond Toy's avatar
Raymond Toy committed
57

Raymond Toy's avatar
Raymond Toy committed
58
   This manual revised (C) 2009-2016 Robert P. Goldman and Francois-Rene
59
Rideau.
Raymond Toy's avatar
Raymond Toy committed
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

   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.

* Menu:

* Introduction::
83
* Quick start summary::
Raymond Toy's avatar
Raymond Toy committed
84
85
86
87
88
89
90
91
92
93
94
* 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::
95
96
* Ongoing Work::
* Bibliography::
Raymond Toy's avatar
Raymond Toy committed
97
98
* Concept Index::
* Function and Class Index::
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
* Variable Index::              

 -- The Detailed Node Listing --

Loading ASDF

* Loading a pre-installed ASDF::
* Checking whether ASDF is loaded::
* Upgrading ASDF::
* Replacing your implementation's ASDF::
* Loading ASDF from source::

Configuring ASDF

* Configuring ASDF to find your systems::
* Configuring ASDF to find your systems --- old style::
* Configuring where ASDF stores object files::
* Resetting the ASDF configuration::

Using ASDF

* Loading a system::
* Convenience Functions::
* Moving on::

Defining systems with defsystem

* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
* The package-inferred-system extension::

The Object model of ASDF

* Operations::
* Components::
* Dependencies::
* Functions::

Operations

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

Components

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

properties

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

Controlling where ASDF searches for systems

* Configurations::
* Truenames and other dangers::
* XDG base directory::
* Backward Compatibility::
* Configuration DSL::
* Configuration Directories::
* Shell-friendly syntax for configuration::
* Search Algorithm::
* Caching Results::
* Configuration API::
* Introspection::
* Status::
* Rejected ideas::
* TODO::
* Credits for the source-registry::

Configuration Directories

* The here directive::

Introspection

* *source-registry-parameter* variable::
* Information about system dependencies::

Controlling where ASDF saves compiled files

* Output Configurations::
* Output Backward Compatibility::
* Output Configuration DSL::
* Output Configuration Directories::
* Output Shell-friendly syntax for configuration::
* Semantics of Output Translations::
* Output Caching Results::
* Output location API::
* Credits for output translations::

Miscellaneous additional functionality

* Controlling file compilation::
* Controlling source file character encoding::
* Miscellaneous Functions::
* Some Utility Functions::

FAQ

* Where do I report a bug?::
* Mailing list::
* What has changed between ASDF 1 ASDF 2 and ASDF 3?::
* Issues with installing the proper version of ASDF::
* Issues with configuring ASDF::
* Issues with using and extending ASDF to define systems::
* ASDF development FAQs::

"What has changed between ASDF 1, ASDF 2, and ASDF 3?"

* What are ASDF 1 2 3?::
* How do I detect the ASDF version?::
* ASDF can portably name files in subdirectories::
* Output translations::
* Source Registry Configuration::
* Usual operations are made easier to the user::
* Many bugs have been fixed::
* ASDF itself is versioned::
* ASDF can be upgraded::
* Decoupled release cycle::
* Pitfalls of the transition to ASDF 2::
* Pitfalls of the upgrade to ASDF 3::
* What happened to the bundle operations::

Issues with installing the proper version of ASDF

* My Common Lisp implementation comes with an outdated version of ASDF. What to do?::
* I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?::

Issues with configuring ASDF

* How can I customize where fasl files are stored?::
* How can I wholly disable the compiler output cache?::

Issues with using and extending ASDF to define systems

* How can I cater for unit-testing in my system?::
* How can I cater for documentation generation in my system?::
* How can I maintain non-Lisp (e.g. C) source files?::
* I want to put my module's files at the top level.  How do I do this?::
* How do I create a system definition where all the source files have a .cl extension?::
* How do I mark a source file to be loaded only and not compiled?::
* How do I work with readtables?::
Raymond Toy's avatar
Raymond Toy committed
246
* How can I capture ASDF's output?::
Raymond Toy's avatar
Raymond Toy committed
247
* LOAD-PATHNAME has a weird value::
248
249
250
251
252

ASDF development FAQs

* How do I run the tests interactively in a REPL?::

Raymond Toy's avatar
Raymond Toy committed
253
254


255
File: asdf.info,  Node: Introduction,  Next: Quick start summary,  Prev: Top,  Up: Top
Raymond Toy's avatar
Raymond Toy committed
256
257
258
259
260

1 Introduction
**************

ASDF is Another System Definition Facility: a tool for specifying how
261
262
263
264
systems of Common Lisp software are made up 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.  If you are new to ASDF,
*note the quick start guide: Quick start summary.
Raymond Toy's avatar
Raymond Toy committed
265
266
267

   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
268
software who want to specify how to build their systems, and one for
Raymond Toy's avatar
Raymond Toy committed
269
implementers of Common Lisp extensions who want to extend the build
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
system.  For more specifics, *note Using ASDF::, to learn how to use
ASDF to load a system.  *Note Defining systems with defsystem::, to
learn how to define a system of your own.  *Note The object model of
ASDF::, for a description of the ASDF internals and how to extend ASDF.

   Note that ASDF is _not_ a tool for library and system _installation_;
it plays a role like 'make' or 'ant', not like a package manager.  In
particular, ASDF should not to be confused with Quicklisp or
ASDF-Install, that attempt to find and download ASDF systems for you.
Despite what the name might suggest, 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 (<http://www.quicklisp.org/>)
instead, a Common Lisp package manager which works well 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 (<http://common-lisp.net/project/clbuild/>).  We
recommend '~/common-lisp/' as a place into which to install Common Lisp
software; starting with ASDF 3.1.2, it is included in the default
source-registry configuration.

   Finally, note that this manual is incomplete.  All the bases are
covered, but many advanced topics are only barely alluded to, and there
is not much in terms of examples.  The source code remains the ultimate
source of information, free software systems in Quicklisp remain the
best source of examples, and the mailing-list the best place to ask for
help.
Raymond Toy's avatar
Raymond Toy committed
296
297


298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
File: asdf.info,  Node: Quick start summary,  Next: Loading ASDF,  Prev: Introduction,  Up: Top

2 Quick start summary
*********************

   * To load an ASDF system:

        * Load ASDF itself into your Lisp image, using '(require
          "asdf")'.  Check that you have a recent version using
          '(asdf:asdf-version)'.  For more details, or if any of the
          above fails, *note Loading ASDF::.

        * Make sure software is installed where ASDF can find it.  The
          simplest way is to put all your Lisp code in subdirectories of
          '~/common-lisp/' (starting with ASDF 3.1.2), or
          '~/.local/share/common-lisp/source/' (for ASDF 2 and later, or
          if you want to keep source in a hidden directory).  For more
          details, *note Configuring ASDF to find your systems::.
Raymond Toy's avatar
Raymond Toy committed
316

317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
        * Load your system with '(asdf:load-system "MY-SYSTEM")'.  *Note
          Using ASDF::.

   * To make your own ASDF system:

        * As above, load and configure ASDF.

        * Make a new directory for your system, 'MY-SYSTEM/', again in a
          location where ASDF can find it.  All else being equal, the
          easiest location is probably '~/common-lisp/my-system/'.
          *Note Configuring ASDF to find your systems::.

        * Create an ASDF system definition listing the dependencies of
          your system, its components, and their interdependencies, and
          put it in 'MY-SYSTEM.asd'.  This file must have the same name
          as your system, all lowercase.  *Note Defining systems with
          defsystem::.

        * Use '(asdf:load-system "MY-SYSTEM")' to make sure it's all
          working properly.  *Note Using ASDF::.


File: asdf.info,  Node: Loading ASDF,  Next: Configuring ASDF,  Prev: Quick start summary,  Up: Top

3 Loading ASDF
Raymond Toy's avatar
Raymond Toy committed
342
343
**************

344
345
346
347
348
349
350
* Menu:

* Loading a pre-installed ASDF::
* Checking whether ASDF is loaded::
* Upgrading ASDF::
* Replacing your implementation's ASDF::
* Loading ASDF from source::
Raymond Toy's avatar
Raymond Toy committed
351

352
353

File: asdf.info,  Node: Loading a pre-installed ASDF,  Next: Checking whether ASDF is loaded,  Prev: Loading ASDF,  Up: Loading ASDF
Raymond Toy's avatar
Raymond Toy committed
354

355
356
357
358
3.1 Loading a pre-installed ASDF
================================

The recommended way to load ASDF is via:
Raymond Toy's avatar
Raymond Toy committed
359
360
     (require "asdf")

361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
   All actively maintained Lisp implementations now include a copy of
ASDF 3 that you can load this way using Common Lisp's 'require'
function.(1)

   If the implementation you are using doesn't provide a recent ASDF 3,
we recommend you upgrade it.  If for some reason you would rather not
upgrade it, we recommend you replace your implementation's ASDF. *Note
Replacing your implementation's ASDF::.  If all else fails, see *note
Loading ASDF from source:: below.

   If you use an actively maintained implementation that fails to
provide an up-to-date enough stable release of ASDF, you may also send a
bug report to your Lisp vendor and complain about it -- or you may fix
the issue yourself if it's free software.

Raymond Toy's avatar
Raymond Toy committed
376
   As of the writing of this manual, the following implementations
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
provide ASDF 3 this way: ABCL, Allegro CL, CLASP, Clozure CL, CMUCL,
ECL, GNU CLISP, LispWorks, MKCL, SBCL. The following implementations
only provide ASDF 2: MOCL, XCL. The following implementations don't
provide ASDF: Corman CL, GCL, Genera, MCL, SCL. The latter
implementations are not actively maintained (except maybe GCL); if some
of them are ever released again, they probably will include ASDF 3.

   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.  SLIME notably sports a
'slime-asdf' contrib that makes life easier with ASDF.

   ---------- Footnotes ----------

   (1) NB: all implementations except GNU CLISP also accept '(require
"ASDF")', '(require 'asdf)' and '(require :asdf)'.  For portability's
sake, you should use '(require "asdf")'.


File: asdf.info,  Node: Checking whether ASDF is loaded,  Next: Upgrading ASDF,  Prev: Loading a pre-installed ASDF,  Up: Loading ASDF

3.2 Checking whether ASDF is loaded
Raymond Toy's avatar
Raymond Toy committed
400
401
===================================

402
To check that ASDF is properly loaded, you can run this form:
Raymond Toy's avatar
Raymond Toy committed
403
404
405

     (asdf:asdf-version)

406
407
408
   If it returns a string, that is the version of ASDF that is currently
installed.  If that version is suitably recent (say, 3.1.2 or later),
then you can skip directly to next chapter: *Note Configuring ASDF::.
Raymond Toy's avatar
Raymond Toy committed
409
410

   If it raises an error, then either ASDF is not loaded, or you are
411
using a very old version of ASDF, and need to install ASDF 3.
Raymond Toy's avatar
Raymond Toy committed
412

413
414
   For more precision in detecting versions old and new, *note How do I
detect the ASDF version?::.
Raymond Toy's avatar
Raymond Toy committed
415
416
417
418
419

   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.

420
421
422
423

File: asdf.info,  Node: Upgrading ASDF,  Next: Replacing your implementation's ASDF,  Prev: Checking whether ASDF is loaded,  Up: Loading ASDF

3.3 Upgrading ASDF
Raymond Toy's avatar
Raymond Toy committed
424
425
==================

426
427
428
429
430
431
If your implementation already provides ASDF 3 or later (and it should),
but you want a more recent ASDF version than your implementation
provides, then you just need to ensure the more recent ASDF is installed
in a configured path, like any other system.  We recommend you download
an official tarball or checkout a release from git into
'~/common-lisp/asdf/'.  (*note Configuring ASDF to find your systems::).
Raymond Toy's avatar
Raymond Toy committed
432

433
434
435
436
437
   Once the source code for ASDF is installed, you don't need any extra
step to load it beyond the usual '(require "asdf")': ASDF 3 will
automatically look whether an updated version of itself is available
amongst the regularly configured systems, before it compiles anything
else.
Raymond Toy's avatar
Raymond Toy committed
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
   If your implementation fails to provide ASDF 3 or later, *note
Replacing your implementation's ASDF::.


File: asdf.info,  Node: Replacing your implementation's ASDF,  Next: Loading ASDF from source,  Prev: Upgrading ASDF,  Up: Loading ASDF

3.4 Replacing your implementation's ASDF
========================================

All maintained implementations now provide ASDF 3 in their latest
release.  If your doesn't, we recommend you upgrade it.

   Now, if you insist on using an old implementation that didn't provide
ASDF or provided an old version, we recommend installing a recent ASDF,
as explained below, into your implementation's installation directory.
Thus your modified implementation will now provide ASDF 3.  This
requires proper write permissions and may necessitate execution as a
system administrator.

   The ASDF source repository contains a tool to help you upgrade your
implementation's ASDF. You can invoke it from the shell command-line as
'tools/asdf-tools install-asdf lispworks' (where you can replace
'lispworks' by the name of the relevant implementation), or you can
'(load "tools/install-asdf.lisp")' from your Lisp REPL.

   This script works on Allegro CL, Clozure CL, CMU CL, ECL, GCL, GNU
CLISP, LispWorks, MKCL, SBCL, SCL, XCL. It doesn't work on ABCL, Corman
CL, Genera, MCL, MOCL. Happily, ABCL is usually pretty up to date and
shouldn't need that script.  GCL requires a very recent version, and
hasn't been tested much.  Corman CL, Genera, MCL are obsolete anyway.
MOCL is incomplete.
Raymond Toy's avatar
Raymond Toy committed
470

471
472

File: asdf.info,  Node: Loading ASDF from source,  Prev: Replacing your implementation's ASDF,  Up: Loading ASDF
Raymond Toy's avatar
Raymond Toy committed
473

474
475
476
477
478
479
480
3.5 Loading ASDF from source
============================

If you write build scripts that must remain portable to old machines
with old implementations that you cannot ensure have been upgraded or
modified to provide a recent ASDF, you may have to install the file
'asdf.lisp' somewhere and load it with:
Raymond Toy's avatar
Raymond Toy committed
481
482
483

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

484
   The single file 'asdf.lisp' is all you normally need to use ASDF.
Raymond Toy's avatar
Raymond Toy committed
485
486

   You can extract this file from latest release tarball on the ASDF
487
website (https://common-lisp.net/project/asdf/).  If you are daring and
Raymond Toy's avatar
Raymond Toy committed
488
489
490
willing to report bugs, you can get the latest and greatest version of
ASDF from its git repository.  *Note Getting the latest version::.

491
492
493
494
   For scripts that try to use ASDF simply via 'require' at first, and
make heroic attempts to load it the hard way if at first they don't
succeed, see 'tools/load-asdf.lisp' distributed with the ASDF source
repository, or the code of 'cl-launch' (https://cliki.net/cl-launch).
Raymond Toy's avatar
Raymond Toy committed
495
496
497
498


File: asdf.info,  Node: Configuring ASDF,  Next: Using ASDF,  Prev: Loading ASDF,  Up: Top

499
4 Configuring ASDF
Raymond Toy's avatar
Raymond Toy committed
500
501
******************

502
503
504
505
506
507
508
For standard use cases, ASDF should work pretty much out of the box.  We
recommend you skim the sections on configuring ASDF to find your systems
and choose the method of installing Lisp software that works best for
you.  Then skip directly to *Note Using ASDF::.  That will probably be
enough.  You are unlikely to have to worry about the way ASDF stores
object files, and resetting the ASDF configuration is usually only
needed in corner cases.
Raymond Toy's avatar
Raymond Toy committed
509

510
* Menu:
Raymond Toy's avatar
Raymond Toy committed
511

512
513
514
515
* Configuring ASDF to find your systems::
* Configuring ASDF to find your systems --- old style::
* Configuring where ASDF stores object files::
* Resetting the ASDF configuration::
Raymond Toy's avatar
Raymond Toy committed
516

517
518

File: asdf.info,  Node: Configuring ASDF to find your systems,  Next: Configuring ASDF to find your systems --- old style,  Prev: Configuring ASDF,  Up: Configuring ASDF
Raymond Toy's avatar
Raymond Toy committed
519

520
521
4.1 Configuring ASDF to find your systems
=========================================
Raymond Toy's avatar
Raymond Toy committed
522

523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
In order to compile and load your systems, ASDF must be configured to
find the '.asd' files that contain system definitions.

   There are a number of different techniques for setting yourself up
with ASDF, starting from easiest to the most complex:

   * Put all of your systems in one of the standard locations,
     subdirectories of
        * '~/common-lisp/' or
        * '~/.local/share/common-lisp/source/'.
     If you install software there, you don't need further
     configuration.(1)  You can then skip to the next section.  *Note
     Loading a system::.

   * If you're using some tool to install software (e.g.  Quicklisp),
     the authors of that tool should already have configured ASDF.

   * If you have more specific desires about how to lay out your
     software on disk, the preferred way to configure where ASDF finds
     your systems is the 'source-registry' facility, fully described in
     its own chapter of this manual.  *Note Controlling where ASDF
     searches for systems::.  Here is a quick recipe for getting
     started.

     First create the directory
     '~/.config/common-lisp/source-registry.conf.d/'(2); there create a
     file with any name of your choice but with the type 'conf'(3), for
     instance '50-luser-lisp.conf'; in this file, add the following line
     to tell ASDF to recursively scan all the subdirectories under
     '/home/luser/lisp/' for '.asd' files: '(:tree "/home/luser/lisp/")'

     That's enough.  You may replace '/home/luser/lisp/' by wherever you
     want to install your source code.  You don't actually need to
     specify anything if you use the default '~/common-lisp/' as above
     and your implementation provides ASDF 3.1.2 or later.  If your
     implementation provides an earlier variant of ASDF 3, you might
     want to specify '(:tree (:home "common-lisp/"))' for bootstrap
     purposes, then install a recent source tree of ASDF under
     '~/common-lisp/asdf/'.

     If you prefer to use a "link farm", which is faster to use but
     costlier to manage than a recursive traversal, say at
     '/home/luser/.asd-link-farm/', then you may instead (or
     additionally) create a file '42-asd-link-farm.conf', containing the
     line: '(:directory "/home/luser/.asd-link-farm/")'

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

          (asdf:clear-source-registry)

   * In earlier versions of ASDF, the system source registry was
     configured using a global variable, 'asdf:*central-registry*'.  For
     more details about this, see the following section, *note
     Configuring ASDF to find your systems --- old style::.  Unless you
     need to understand this, skip directly to *note Configuring where
     ASDF stores object files::.
Raymond Toy's avatar
Raymond Toy committed
581
582
583
584
585

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

586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
   ---------- Footnotes ----------

   (1) '~/common-lisp/' is only included in the default configuration
starting with ASDF 3.1.2 or later.  If your implementation provides an
earlier variant of ASDF, you may need to explicitly configure it to use
this path, as further explained.

   (2) For Windows users, and starting with ASDF 3.1.5, start from your
'%LOCALAPPDATA%', which is usually '~/AppData/Local/' (but you can ask
in a 'CMD.EXE' terminal 'echo %LOCALAPPDATA%' to make sure) and
underneath create a subpath
'config/common-lisp/source-registry.conf.d/'.

   (3) By requiring the '.conf' extension, and ignoring other files,
ASDF allows you to have disabled files, editor backups, etc.  in the
same directory with your active configuration files.
Raymond Toy's avatar
Raymond Toy committed
602

603
   ASDF will also ignore files whose names start with a '.' character.
Raymond Toy's avatar
Raymond Toy committed
604

605
606
607
   It is customary to start the filename with two digits, to control the
sorting of the 'conf' files in the source registry directory, and thus
the order in which the directories will be scanned.
Raymond Toy's avatar
Raymond Toy committed
608

609
610

File: asdf.info,  Node: Configuring ASDF to find your systems --- old style,  Next: Configuring where ASDF stores object files,  Prev: Configuring ASDF to find your systems,  Up: Configuring ASDF
Raymond Toy's avatar
Raymond Toy committed
611

612
4.2 Configuring ASDF to find your systems -- old style
Raymond Toy's avatar
Raymond Toy committed
613
614
======================================================

Raymond Toy's avatar
Raymond Toy committed
615
616
617
Novices may skip this section.

   The old way to configure ASDF to find your systems is by 'push'ing
618
directory pathnames onto the variable 'asdf:*central-registry*'.
Raymond Toy's avatar
Raymond Toy committed
619
620
621
622

   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
623
624
starts your Common Lisp software system.  (For instance, some SBCL users
used to put it in their '~/.sbclrc'.)
Raymond Toy's avatar
Raymond Toy committed
625

626
   The 'asdf:*central-registry*' is empty by default in ASDF 2 or ASDF
Raymond Toy's avatar
Raymond Toy committed
627
3, but is still supported for compatibility with ASDF 1.  When used, it
628
takes precedence over the above source-registry.(1)
Raymond Toy's avatar
Raymond Toy committed
629

630
   For example, let's say you want ASDF to find the '.asd' file
Raymond Toy's avatar
Raymond Toy committed
631
'/home/me/src/foo/foo.asd'.  In your Lisp initialization file, you could
632
have the following:
Raymond Toy's avatar
Raymond Toy committed
633

634
     (require "asdf")
Raymond Toy's avatar
Raymond Toy committed
635
636
637
638
     (push "/home/me/src/foo/" asdf:*central-registry*)

   Note the trailing slash: when searching for a system, ASDF will
evaluate each entry of the central registry and coerce the result to a
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
pathname.(2)  The trailing directory name separator is necessary to tell
Lisp that you're discussing a directory rather than a file.  If you
leave it out, ASDF is likely to look in '/home/me/src/' instead of
'/home/me/src/foo/' as you intended, and fail to find your system
definition.

   Typically there are a lot of '.asd' files, and a common idiom was to
put _symbolic links_ to all of one's '.asd' files in a common directory
and push _that_ directory (the "link farm") onto
'asdf:*central-registry*', instead of pushing each individual system
directory.

   ASDF knows to follow _symlinks_ to the actual location of the
systems.(3)

   For example, if '#p"/home/me/cl/systems/"' is an element of
'*central-registry*', you could set up the system FOO as follows:
Raymond Toy's avatar
Raymond Toy committed
656
657
658
659
660

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

   This old style for configuring ASDF is not recommended for new users,
661
662
663
but it is supported for old users, and for users who want a simple way
to programmatically control what directories are added to the ASDF
search path.
Raymond Toy's avatar
Raymond Toy committed
664

665
   ---------- Footnotes ----------
Raymond Toy's avatar
Raymond Toy committed
666

667
668
669
670
   (1) It is possible to further customize the system definition file
search.  That's considered advanced use, and covered later: search
forward for '*system-definition-search-functions*'.  *Note Defining
systems with defsystem::.
Raymond Toy's avatar
Raymond Toy committed
671

672
673
   (2) ASDF will indeed call 'eval' on each entry.  It will skip entries
that evaluate to 'nil'.
Raymond Toy's avatar
Raymond Toy committed
674

675
676
677
678
679
   Strings and pathname objects are self-evaluating, in which case the
'eval' step does nothing; but you may push arbitrary s-expressions onto
the central registry.  These s-expressions may be evaluated to compute
context-dependent entries, e.g.  things that depend on the value of
shell variables or the identity of the user.
Raymond Toy's avatar
Raymond Toy committed
680

681
682
683
   The variable 'asdf:*central-registry*' is thus a list of "system
directory designators".  A "system directory designator" is a form which
will be evaluated whenever a system is to be found, and must evaluate to
Raymond Toy's avatar
Raymond Toy committed
684
a directory to look in (or 'nil').  By "directory", we mean "designator
685
for a pathname with a non-empty DIRECTORY component".
Raymond Toy's avatar
Raymond Toy committed
686

687
688
689
   (3) 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.
Raymond Toy's avatar
Raymond Toy committed
690

691
692

File: asdf.info,  Node: Configuring where ASDF stores object files,  Next: Resetting the ASDF configuration,  Prev: Configuring ASDF to find your systems --- old style,  Up: Configuring ASDF
Raymond Toy's avatar
Raymond Toy committed
693

694
695
4.3 Configuring where ASDF stores object files
==============================================
Raymond Toy's avatar
Raymond Toy committed
696

697
698
ASDF lets you configure where object files will be stored.  Sensible
defaults are provided and you shouldn't normally have to worry about it.
Raymond Toy's avatar
Raymond Toy committed
699

700
701
702
703
704
   This allows the same source code repository to be shared between
several versions of several Common Lisp implementations, between several
users using different compilation options, with users who lack write
privileges on shared source directories, etc.  This also keeps source
directories from being cluttered with object/fasl files.
Raymond Toy's avatar
Raymond Toy committed
705

706
707
708
709
710
711
   Starting with ASDF 2, the 'asdf-output-translations' facility was
added to ASDF itself.  This facility controls where object files will be
stored.  This facility is fully described in a chapter of this manual,
*note Controlling where ASDF saves compiled files::.

   Note that before ASDF 2, other ASDF add-ons offered the same
Raymond Toy's avatar
Raymond Toy committed
712
713
714
715
functionality, each in subtly different and incompatible ways:
ASDF-Binary-Locations, cl-launch, common-lisp-controller.
ASDF-Binary-Locations is now not needed anymore and should not be used.
cl-launch 3.000 and common-lisp-controller 7.2 have been updated to
716
delegate object file placement to ASDF.
Raymond Toy's avatar
Raymond Toy committed
717
718


719
File: asdf.info,  Node: Resetting the ASDF configuration,  Prev: Configuring where ASDF stores object files,  Up: Configuring ASDF
Raymond Toy's avatar
Raymond Toy committed
720

721
722
4.4 Resetting the ASDF configuration
====================================
Raymond Toy's avatar
Raymond Toy committed
723
724
725
726
727
728

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:

 -- Function: clear-configuration
729
     Undoes any ASDF configuration regarding source-registry or
Raymond Toy's avatar
Raymond Toy committed
730
731
     output-translations.

732
733
734
735
736
737
738
739
   This function is pushed onto the 'uiop:*image-dump-hook*' by default,
which means that if you save an image using 'uiop:dump-image', or via
'asdf:image-op' and 'asdf:program-op', it will be automatically called
to clear your configuration.  If for some reason you prefer to call your
implementation's underlying functionality, be sure to call
'clear-configuration' manually, or push it into your implementation's
equivalent of 'uiop:*image-dump-hook*', e.g.  'sb-ext:*save-hooks*' on
SBCL, or 'ext:*before-save-initializations*' on CMUCL and SCL, etc.
Raymond Toy's avatar
Raymond Toy committed
740

741
742

File: asdf.info,  Node: Using ASDF,  Next: Defining systems with defsystem,  Prev: Configuring ASDF,  Up: Top
Raymond Toy's avatar
Raymond Toy committed
743

744
5 Using ASDF
Raymond Toy's avatar
Raymond Toy committed
745
746
************

747
748
749
750
751
752
753
754
755
756
* Menu:

* Loading a system::
* Convenience Functions::
* Moving on::


File: asdf.info,  Node: Loading a system,  Next: Convenience Functions,  Prev: Using ASDF,  Up: Using ASDF

5.1 Loading a system
Raymond Toy's avatar
Raymond Toy committed
757
758
759
760
761
762
763
====================

The system FOO is loaded (and compiled, if necessary) by evaluating the
following Lisp form:

     (asdf:load-system :FOO)

764
765
   On some implementations (*note Convenience Functions::), ASDF hooks
into the 'cl:require' facility and you can just use:
Raymond Toy's avatar
Raymond Toy committed
766
767
768

     (require :FOO)

769
770
771
772
773
   Note that the canonical name of a system is a string, conventionally
lowercase.  A system name can also be specified as a symbol (including a
keyword), in which case its 'symbol-name' is taken and lowercased.  The
name must be a suitable value for the ':name' initarg to 'make-pathname'
in whatever filesystem the system is to be found.
Raymond Toy's avatar
Raymond Toy committed
774

775
776
777
778
   The lower-casing-symbols behaviour is unconventional, but was
selected after some consideration.  The type of systems we want to
support either have lowercase as customary case (Unix, Mac, Windows) or
silently convert lowercase to uppercase (lpns).
Raymond Toy's avatar
Raymond Toy committed
779

780
781

File: asdf.info,  Node: Convenience Functions,  Next: Moving on,  Prev: Loading a system,  Up: Using ASDF
Raymond Toy's avatar
Raymond Toy committed
782

783
784
785
786
5.2 Convenience Functions
=========================

ASDF provides three commands for the most common system operations:
Raymond Toy's avatar
Raymond Toy committed
787
788
789
790
791
792
793
794
795
796
797
798
799
'load-system', 'compile-system', and 'test-system'.

   ASDF also provides 'require-system', a variant of 'load-system' that
skips loading systems that are already loaded.  This is sometimes
useful, for example, in order to avoid re-loading libraries that come
pre-loaded into your lisp implementation.

   ASDF also provides 'make', a way of allowing system developers to
choose a default operation for their systems.  For example, a developer
who has created a system intended to format a specific document, might
make document-formatting the default operation invoked by 'make',
instead of loading.  If the system developer doesn't specify in the
system definition, the default operation will be loading.
Raymond Toy's avatar
Raymond Toy committed
800

801
802
803
804
805
806
807
808
   Because ASDF is an extensible system for defining _operations_ on
_components_, it also provides a generic function 'operate', so you may
arbitrarily operate on your systems beyond the default operations.  (At
the interactive REPL, users often use its shorter alias 'oos', which
stands for operate-on-system, a name inherited from 'mk-defsystem'.)
You'll use 'operate' whenever you want to do something beyond compiling,
loading and testing.

Raymond Toy's avatar
Raymond Toy committed
809
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
865
866
867
868
869
870
871
872
873
 -- Function: load-system system &rest keys &key force force-not verbose
          version &allow-other-keys
     Apply 'operate' with the operation from '*load-system-operation*'
     the SYSTEM, and any provided keyword arguments.
     '*load-system-operation*' by default is 'load-op'; it would be
     'load-bundle-op' by default on ECL, if only an implementation bug
     were fixed.  Calling 'load-system' is the regular, recommended way
     to load a system into the current image.

 -- Function: compile-system system &rest keys &key force force-not
          verbose version &allow-other-keys
     Apply 'operate' with the operation 'compile-op', the SYSTEM, and
     any provided keyword arguments.  This will make sure all the files
     in the system are compiled, but not necessarily load any of them in
     the current image; on most systems, it will _not_ load all compiled
     files in the current image.  This function exists for symmetry with
     'load-system' but is not recommended unless you are writing build
     scripts and know what you're doing.  But then, you might be
     interested in 'program-op' rather than 'compile-op'.

 -- Function: test-system system &rest keys &key force force-not verbose
          version &allow-other-keys
     Apply 'operate' with the operation 'test-op', the SYSTEM, and any
     provided keyword arguments.  *Note test-op::.

 -- Function: make system &rest keys &key &allow-other-keys
     Do "The Right Thing" with your system.  Starting with ASDF 3.1,
     this function 'make' is also available.  The default behaviour is
     to load the system as if by 'load-system'; but system authors can
     override this default in their system definition they may specify
     an alternate operation as the intended use of their system, with a
     ':build-operation' option in the 'defsystem' form (*note
     build-operation: The defsystem grammar.), and an intended output
     pathname for that operation with ':build-pathname'.  This function
     is experimental and largely untested.  Use at your own risk.

 -- Function: require-system system &rest keys &key &allow-other-keys
     'require-system' skips any update to systems that have already been
     loaded, in the spirit of 'cl:require'.  It does it by calling
     'load-system' with a keyword option excluding already loaded
     systems.(1).  On actively maintained free software implementations
     (namely recent versions of ABCL, Clozure CL, CMUCL, ECL, GNU CLISP,
     MKCL and SBCL), once ASDF itself is loaded, 'cl:require' too can
     load ASDF systems, by falling back on 'require-system' for module
     names not recognized by the implementation.  (Note however that
     'require-system' does _not_ fall back on 'cl:require'; that would
     introduce an "interesting" potential infinite loop to break
     somehow.)

     'cl:require' and 'require-system' are appropriate to load code that
     is not being modified during the current programming session.
     'cl:require' will notably load the implementation-provided
     extension modules; 'require-system' won't, unless they are also
     defined as systems somehow, which SBCL and MKCL do.
     'require-system' may also be used to load any number of ASDF
     systems that the user isn't either developing or debugging, for
     which a previously installed version is deemed to be satisfactory;
     'cl:require' on the above-mentioned implementations will delegate
     to 'require-system' and may load them as well.  But for code that
     you are actively developing, debugging, or otherwise modifying, you
     should use 'load-system', so ASDF will pick on your modifications
     and transitively re-build the modified files and everything that
     depends on them (that the requested SYSTEM itself depends on --
     ASDF itself never builds anything unless it's an explicitly
     requested system or the dependencies thereof).
Raymond Toy's avatar
Raymond Toy committed
874

875
   ---------- Footnotes ----------
Raymond Toy's avatar
Raymond Toy committed
876

877
878
   (1) For the curious, the option is ':force-not
(already-loaded-systems)'.
Raymond Toy's avatar
Raymond Toy committed
879

880
881

File: asdf.info,  Node: Moving on,  Prev: Convenience Functions,  Up: Using ASDF
Raymond Toy's avatar
Raymond Toy committed
882

883
5.3 Moving on
Raymond Toy's avatar
Raymond Toy committed
884
885
886
887
888
889
890
891
892
893
=============

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.


File: asdf.info,  Node: Defining systems with defsystem,  Next: The object model of ASDF,  Prev: Using ASDF,  Up: Top

894
6 Defining systems with defsystem
Raymond Toy's avatar
Raymond Toy committed
895
896
*********************************

897
This chapter describes how to use ASDF to define systems and develop
Raymond Toy's avatar
Raymond Toy committed
898
899
900
901
902
903
904
905
software.

* Menu:

* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
906
* The package-inferred-system extension::
Raymond Toy's avatar
Raymond Toy committed
907
908
909
910


File: asdf.info,  Node: The defsystem form,  Next: A more involved example,  Prev: Defining systems with defsystem,  Up: Defining systems with defsystem

911
6.1 The defsystem form
Raymond Toy's avatar
Raymond Toy committed
912
913
======================

914
915
This section begins with an example of a system definition, then gives
the full grammar of 'defsystem'.
Raymond Toy's avatar
Raymond Toy committed
916

917
918
919
   Let's look at a simple system.  This is a complete file that should
be saved as 'hello-lisp.asd' (in order that ASDF can find it when
ordered to operate on the system named '"hello-lisp"').
Raymond Toy's avatar
Raymond Toy committed
920

921
     ;; Usual Lisp comments are allowed here
Raymond Toy's avatar
Raymond Toy committed
922
923
924

     (defsystem "hello-lisp"
       :description "hello-lisp: a sample Lisp system."
925
       :version "0.0.1"
Raymond Toy's avatar
Raymond Toy committed
926
927
       :author "Joe User <joe@example.com>"
       :licence "Public Domain"
928
       :depends-on ("optima.ppcre" "command-line-arguments")
Raymond Toy's avatar
Raymond Toy committed
929
930
931
932
933
934
       :components ((:file "packages")
                    (:file "macros" :depends-on ("packages"))
                    (:file "hello" :depends-on ("macros"))))

   Some notes about this example:

935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
   * The 'defsystem' form defines a system named 'hello-lisp' that
     contains three source files: 'packages.lisp', 'macros.lisp' and
     'hello.lisp'.

   * The '.lisp' suffix is implicit for Lisp source files.  The source
     files are located in the same directory as the '.asd' file with the
     system definition.

   * The file 'macros' depends on 'packages' (presumably because the
     package it's in is defined in 'packages'), and the file 'hello'
     depends on 'macros' (and hence, transitively on 'packages').  This
     means that ASDF will compile and load 'packages' then 'macros'
     before starting the compilation of file 'hello'.

   * This example system has external dependencies on two other systems,
     'optima.ppcre' (that provides a friendly interface to matching
     regular expressions), and 'command-line-arguments' (that provides a
     way to parse arguments passed from the shell command line).  To use
     this system, ASDF must be configured to find installed copies of
     these systems; it will load them before it tries to compile and
     load 'hello-lisp'.

   * This system also defines a bunch of metadata.  While it is optional
     to define these fields (and other fields like ':bug-tracker',
     ':mailto', ':long-name', ':long-description', ':source-control'),
     it is strongly recommended to define the fields ':description',
     ':version', ':author', and ':licence', especially if you intend
     your software to be eventually included in Quicklisp.

   * Make sure you know how the ':version' numbers will be parsed!  Only
     period-separated non-negative integers are accepted at present.
     See below Version specifiers in *note The defsystem grammar::.

   * This file contains a single form, the 'defsystem' declaration.  No
     'in-package' form, no 'asdf:' package prefix, no nothing.  Just the
     one naked 'defsystem' form.  This is what we recommend.  More
     complex system definition files are possible with arbitrary Lisp
     code, but we recommend that you keep it simple if you can.  This
     will make your system definitions more robust and more
     future-proof.

   This is all you need to know to define simple systems.  The next
example is much more involved, to give you a glimpse of how you can do
more complex things.  However, since it's ultimately arbitrary Lisp
code, there is no bottom to the rabbit hole.
Raymond Toy's avatar
Raymond Toy committed
980
981
982
983


File: asdf.info,  Node: A more involved example,  Next: The defsystem grammar,  Prev: The defsystem form,  Up: Defining systems with defsystem

984
6.2 A more involved example
Raymond Toy's avatar
Raymond Toy committed
985
986
===========================

987
Let's illustrate some more involved uses of 'defsystem' via a slightly
Raymond Toy's avatar
Raymond Toy committed
988
989
convoluted example:

990
991
     (in-package :asdf-user)

Raymond Toy's avatar
Raymond Toy committed
992
     (defsystem "foo"
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
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
1143
       :version (:read-file-form "variables" :at (3 2))
       :components
       ((:file "package")
        (:file "variables" :depends-on ("package"))
        (:module "mod"
          :depends-on ("package")
          :serial t
          :components ((:file "utils")
                       (:file "reader")
                       (:file "cooker")
                       (:static-file "data.raw"))
          :output-files (compile-op (o c) (list "data.cooked"))
          :perform (compile-op :after (o c)
             (cook-data
              :in (component-pathname (find-component c "data.raw"))
              :out (first (output-files o c)))))
        (:file "foo" :depends-on ("mod"))))

     (defmethod action-description
         ((o compile-op) (c (eql (find-component "foo" "mod"))))
       "cooking data")

   Here are some notes about this example:

   * The main thing this file does is define a system 'foo'.  It also
     contains other Lisp forms, which we'll examine below.

   * Besides Lisp source files, this system contains a ':module'
     component named '"mod"', which is a collection of three Lisp source
     files 'utils.lisp', 'reader.lisp', 'cooker.lisp' and 'data.raw'

   * Note that the ':static-file' does not have an implicit file type,
     unlike the Lisp source files.

   * This files will be located in a subdirectory of the main code
     directory named 'mod/' (this location could have been overridden to
     be in the same directory, or in a different subdirectory; see the
     discussion of the ':pathname' option in *note The defsystem
     grammar::).

   * The ':serial t' says that each sub-component of 'mod' depends on
     the previous components, so that 'cooker.lisp' depends-on
     'utils.lisp', which depends-on 'reader.lisp'.  Also 'data.raw'
     depends on all of them, but that doesn't matter since it's a static
     file; on the other hand, if it appeared first, then all the Lisp
     files would be recompiled when the data is modified, which is
     probably not what is desired in this case.

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

               :output-files (compile-op (o c) (list "data.cooked"))
               :perform (compile-op :after (o c)
                  (cook-data
                   :in (component-pathname (find-component c "data.raw"))
                   :out (first (output-files o c))))

     has the effect of

          (defmethod output-files ((o compile-op) (c (eql ...)))
            (list "data.cooked"))
          (defmethod perform :after ((o compile-op) (c (eql ...)))
            (cook-data
             :in (component-pathname (find-component c "data.raw"))
             :out (first (output-files o c))))

     where '...' is the component in question.  In this case '...' would
     expand to something like

          (find-component "foo" "mod")

     For more details on the syntax of such forms, *note The defsystem
     grammar::.  For more details on what these methods do, *note
     Operations:: in *note The object model of ASDF::.

   * There is an additional 'defmethod' with a similar effect, because
     ASDF (as of ASDF 3.1.5) fails to accept inline-methods as above for
     'action-description', instead only supporting the deprecated
     'explain' interface.

   * In this case, these methods describe how this module defines code
     that it then uses to cook some data.

   * Importantly, ASDF is told about the input and output files used by
     the data cooker, and to make sure everyone agrees, the cooking
     function explicitly uses ASDF to access pathnames to the input and
     output data.

   * The file starts with a form '(in-package :asdf-user)', but it is
     actually redundant, not necessary and not recommended.  But yet
     more complex cases (also not recommended) may usefully use an
     'in-package' form.

   * Indeed, ASDF does not load '.asd' files simply with 'cl:load', and
     neither should you.  You should let ASDF find and load them when
     you operate on systems.  If you somehow _must_ load a '.asd' file,
     use the same function 'asdf:load-asd' that ASDF uses.  Among other
     things, it already binds the '*package*' to 'asdf-user'.  Recent
     versions of SLIME (2013-02 and later) know to do that when you 'C-c
     C-k' when you use the 'slime-asdf' contrib.

   * You shouldn't use an 'in-package' form if you're keeping things
     simple.  You should only use 'in-package' (and before it, a
     'defpackage') when you're going to define new classes, functions,
     variables, macros, etc., in the '.asd' file, and want to thereby
     avoid name clashes.  Manuals for old versions of ASDF recommended
     use of such an idiom in '.asd' files, but as of ASDF 3, we
     recommend that you don't do that anymore, and instead define any
     ASDF extensions in their own system, on which you can then declare
     a dependency using ':defsystem-depends-on'.  *Note The defsystem
     grammar::.

   * More generally, you can always rely on symbols from packages
     'asdf', 'common-lisp' and 'uiop' being available in '.asd' files --
     most importantly including 'defsystem'.  It is therefore redundant
     and in bad taste to use a package-prefixed 'asdf:defsystem' symbol
     in a '.asd' file.  Just use '(defsystem ...)'.  Only package-prefix
     it when somehow dynamically generating system definitions from a
     package that doesn't already use the ASDF package.

   * 'asdf-user' is actually only available starting since ASDF 3, but
     then again, ASDF 1 and 2 did crazy things with packages that ASDF 3
     has stopped doing(1), and since all implementations provide ASDF 3,
     you shouldn't care about compatibility with ASDF 2.  We do not
     support ASDF 2 anymore, and we recommend that neither should you.

   * Starting with ASDF 3.1, 'asdf-user' uses 'uiop', whereas in earlier
     variants of ASDF 3 it only used 'uiop/package'.  We recommend you
     either prefix use of UIOP functions with the package prefix
     'uiop:', or make sure your system ':depends-on ((:version "asdf"
     "3.1.2"))' or has a '#-asdf3.1 (error "MY-SYSTEM requires ASDF
     3.1.2")'.

   * Finally, we elided most metadata, but showed how you can have ASDF
     automatically extract the system's version from a source file.  In
     this case, the 3rd subform of the 4th form (note that Lisp uses
     0-based indexing, English uses 1-based indexing).  Presumably, the
     4th form looks like '(defparameter *foo-version* "5.6.7")'.

   ---------- Footnotes ----------

   (1) ASDF 1 and 2 (up until 2.26) used to dynamically create and
delete temporary packages 'asdf_N_', one for each '.asd' file, in a
misguided attempt to thereby reduce name clashes; but it failed at that
goal and only made things more complex.  ASDF 3 just uses a shared
package 'asdf-user' instead, and relies on the usual Common Lisp
conventions to avoid clashes.  As far as package oddities go, you may
just notice that the 'asdf-user' package also uses 'uiop/common-lisp', a
variant of the 'common-lisp' package that papers over deficiencies in
more obscure Common Lisp implementations; but unless you care about
Corman Lisp, GCL, Genera or MCL, you shouldn't be concerned.
Raymond Toy's avatar
Raymond Toy committed
1144
1145
1146
1147


File: asdf.info,  Node: The defsystem grammar,  Next: Other code in .asd files,  Prev: A more involved example,  Up: Defining systems with defsystem

1148
6.3 The defsystem grammar
Raymond Toy's avatar
Raymond Toy committed
1149
1150
1151
1152
1153
1154
1155
=========================

     system-definition := ( defsystem system-designator SYSTEM-OPTION* )

     system-option := :defsystem-depends-on system-list
                      | :weakly-depends-on SYSTEM-LIST
                      | :class class-name (see discussion below)
Raymond Toy's avatar
Raymond Toy committed
1156
                      | :build-operation OPERATION-NAME
1157
                      | system-option
Raymond Toy's avatar
Raymond Toy committed
1158
1159
1160
                      | module-option
                      | option

1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
     # These are only available since ASDF 3 (actually its alpha release 2.27)
     system-option := :homepage string
                      | :bug-tracker string
                      | :mailto string
                      | :long-name string
                      | :source-control source-control
                      | :version version-specifier

     source-control := (keyword string)

Raymond Toy's avatar
Raymond Toy committed
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
     module-option := :components component-list
                      | :serial [ t | nil ]

     option :=
             | :pathname pathname-specifier
             | :default-component-class class-name
             | :perform method-form
             | :explain method-form
             | :output-files method-form
             | :operation-done-p method-form
             | :if-feature feature-expression
             | :depends-on ( DEPENDENCY-DEF* )
             | :in-order-to ( DEPENDENCY+ )


     system-list := ( SIMPLE-COMPONENT-NAME* )

     component-list := ( COMPONENT-DEF* )

     component-def  := ( component-type simple-component-name OPTION* )

     component-type := :module | :file | :static-file | other-component-type

1194
1195
     other-component-type := symbol-by-name
                             (*note Component types: The defsystem grammar.)
Raymond Toy's avatar
Raymond Toy committed
1196
1197
1198
1199

     # This is used in :depends-on, as opposed to ``dependency,''
     # which is used in :in-order-to
     dependency-def := simple-component-name
1200
                    | ( :feature FEATURE-EXPRESSION dependency-def )
Raymond Toy's avatar
Raymond Toy committed
1201
                      # (*note Feature dependencies: The defsystem grammar.)
1202
1203
                    | ( :version simple-component-name version-specifier )
                    | ( :require module-name )
Raymond Toy's avatar
Raymond Toy committed
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217

     # ``dependency'' is used in :in-order-to, as opposed to
     # ``dependency-def''
     dependency := (dependent-op REQUIREMENT+)
     requirement := (required-op REQUIRED-COMPONENT+)
     dependent-op := operation-name
     required-op := operation-name

     simple-component-name := string
                           |  symbol

     pathname-specifier := pathname | string | symbol

     method-form := (operation-name qual lambda-list &rest body)
1218
     qual := method qualifier?
Raymond Toy's avatar
Raymond Toy committed
1219

1220
1221
1222
1223
     feature-expression := keyword
                           | (:and FEATURE-EXPRESSION*)
                           | (:or FEATURE-EXPRESSION*)
                           | (:not FEATURE-EXPRESSION)
Raymond Toy's avatar
Raymond Toy committed
1224

1225
6.3.1 Component names
Raymond Toy's avatar
Raymond Toy committed
1226
1227
---------------------

1228
Component names ('simple-component-name') may be either strings or
Raymond Toy's avatar
Raymond Toy committed
1229
1230
symbols.

1231
6.3.2 Component types
Raymond Toy's avatar
Raymond Toy committed
1232
1233
1234
1235
---------------------

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
1236
1237
1238
the current package.  So a component type 'my-component-type', in the
current package 'my-system-asd' can be specified as
':my-component-type', or 'my-component-type'.
Raymond Toy's avatar
Raymond Toy committed
1239

1240
   'system' and its subclasses are _not_ allowed as component types for
Raymond Toy's avatar
Raymond Toy committed
1241
1242
such children components.

1243
6.3.3 System class names
Raymond Toy's avatar
Raymond Toy committed
1244
1245
1246
------------------------

A system class name will be looked up in the same way as a Component
1247
type (see above), except that only 'system' and its subclasses are
Raymond Toy's avatar
Raymond Toy committed
1248
allowed.  Typically, one will not need to specify a system class name,
1249
1250
1251
1252
unless using a non-standard system class defined in some ASDF extension,
typically loaded through 'DEFSYSTEM-DEPENDS-ON', see below.  For such
class names in the ASDF package, we recommend that the ':class' option
be specified using a keyword symbol, such as
Raymond Toy's avatar
Raymond Toy committed
1253
1254
1255
1256

     :class :MY-NEW-SYSTEM-SUBCLASS

   This practice will ensure that package name conflicts are avoided.
1257
Otherwise, the symbol 'MY-NEW-SYSTEM-SUBCLASS' will be read into the
Raymond Toy's avatar
Raymond Toy committed
1258
current package _before_ it has been exported from the ASDF extension
1259
loaded by ':defsystem-depends-on', causing a name conflict in the
Raymond Toy's avatar
Raymond Toy committed
1260
1261
current package.

1262
6.3.4 Defsystem depends on
Raymond Toy's avatar
Raymond Toy committed
1263
1264
--------------------------

1265
The ':defsystem-depends-on' option to 'defsystem' allows the programmer
Raymond Toy's avatar
Raymond Toy committed
1266
1267
1268
1269
to specify another ASDF-defined system or set of systems that must be
loaded _before_ the system definition is processed.  Typically this is
used to load an ASDF extension that is used in the system definition.

Raymond Toy's avatar
Raymond Toy committed
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
6.3.5 Build-operation
---------------------

The ':build-operation' option to 'defsystem' allows the programmer to
specify an operation that will be applied, in place of 'load-op' when
'make' (*note make: Convenience Functions.) is run on the system.  The
option value should be the name of an operation.  E.g.,
':build-operation doc-op'

   This feature is experimental and largely untested.  Use at your own
risk.

6.3.6 Weakly depends on
Raymond Toy's avatar
Raymond Toy committed
1283
1284
-----------------------

1285
1286
1287
1288
1289
We do _NOT_ recommend you use this feature.  If you are tempted to write
a system FOO that weakly-depends-on a system BAR, we recommend that you
should instead write system FOO in a parametric way, and offer some
special variable and/or some hook to specialize its behaviour; then you
should write a system FOO+BAR that does the hooking of things together.
Raymond Toy's avatar
Raymond Toy committed
1290

1291
   The (deprecated) ':weakly-depends-on' option to 'defsystem' allows
Raymond Toy's avatar
Raymond Toy committed
1292
1293
1294
1295
1296
1297
1298
the programmer to specify another ASDF-defined system or set of systems
that ASDF should _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
1299
1300
1301
1302
1303
'defsystem', this option is accepted at any component, but it probably
only makes sense at the 'defsystem' level.  Programmers are cautioned
not to use this component option except at the 'defsystem' level, as
this anomalous behaviour may be removed without warning.

Raymond Toy's avatar
Raymond Toy committed
1304
6.3.7 Pathname specifiers
Raymond Toy's avatar
Raymond Toy committed
1305
1306
-------------------------

1307
1308
1309
A pathname specifier ('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.
Raymond Toy's avatar
Raymond Toy committed
1310
1311

   If a string is given, which is the usual case, the string will be
1312
interpreted as a Unix-style pathname where '/' characters will be
Raymond Toy's avatar
Raymond Toy committed
1313
interpreted as directory separators.  Usually, Unix-style relative
1314
pathnames are used (i.e.  not starting with '/', as opposed to absolute
Raymond Toy's avatar
Raymond Toy committed
1315
pathnames); they are relative to the path of the parent component.
1316
Finally, depending on the 'component-type', the pathname may be
Raymond Toy's avatar
Raymond Toy committed
1317
interpreted as either a file or a directory, and if it's a file, a file
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
type may be added corresponding to the 'component-type', or else it will
be extracted from the string itself (if applicable).

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

   ASDF interprets the string '".."' as the pathname directory component
word ':back', which when merged, goes back one level in the directory
hierarchy.
Raymond Toy's avatar
Raymond Toy committed
1335
1336
1337
1338
1339
1340

   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
1341
1342
1343
uppercase (lpns), so this makes more sense than attempting to use ':case
:common' as argument to 'make-pathname', which is reported not to work
on some implementations.
Raymond Toy's avatar
Raymond Toy committed
1344
1345

   Pathname objects may be given to override the path for a component.
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
Such objects are typically specified using reader macros such as '#p' or
'#.(make-pathname ...)'.  Note however, that '#p...' is a shorthand for
'#.(parse-namestring ...)' and that the behaviour of 'parse-namestring'
is completely non-portable, unless you are using Common Lisp
'logical-pathname's, which themselves involve other non-portable
behaviour (*note Using logical pathnames: The defsystem grammar, below).
Pathnames made with '#.(make-pathname ...)' can usually be done more
easily with the string syntax above.  The only case that you really need
a pathname object is to override the component-type default file type
for a given component.  Therefore, pathname objects should only rarely
be used.  Unhappily, ASDF 1 used not to properly support parsing
component names as strings specifying paths with directories, and the
cumbersome '#.(make-pathname ...)' syntax had to be used.  An
alternative to '#.' read-time evaluation is to use '(eval `(defsystem
... ,pathname ...))'.
Raymond Toy's avatar
Raymond Toy committed
1361
1362

   Note that when specifying pathname objects, ASDF does not do any
1363
1364
1365
1366
1367
1368
1369
1370
special interpretation of the pathname influenced by the component type,
unlike the procedure for pathname-specifying strings.  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.

Raymond Toy's avatar
Raymond Toy committed
1371
6.3.8 Version specifiers
Raymond Toy's avatar
Raymond Toy committed
1372
1373
------------------------

1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
Version specifiers are strings to be parsed as period-separated lists of
integers.  I.e., in the example, '"0.2.1"' is to be interpreted, roughly
speaking, as '(0 2 1)'.  In particular, version '"0.2.1"' is interpreted
the same as '"0.0002.1"', though the latter is not canonical and may
lead to a warning being issued.  Also, '"1.3"' and '"1.4"' are both
strictly 'uiop:version<' to '"1.30"', quite unlike what would have
happened had the version strings been interpreted as decimal fractions.

   Instead of a string representing the version, the ':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 '(:read-file-form
<pathname-or-string> :at <access-at-specifier>)', which will be resolved
by reading a form in the specified pathname (read as a subpathname of
the current system if relative or a unix-namestring).  You may use a
'uiop:access-at' specifier with the (optional) ':at' keyword, by default
the specifier is '0', meaning the first form is returned; subforms can
also be specified, with e.g.  '(1 2 2)' specifying "the third subform
(index 2) of the third subform (index 2) of the second form (index 1)"
in the file (mind the off-by-one error in the English language).
Raymond Toy's avatar
Raymond Toy committed
1394
1395
1396
1397
1398
1399
1400
1401

   System definers are encouraged to use version identifiers of the form
X.Y.Z for major version, minor version and patch level, where
significant API incompatibilities are signaled by an increased major
number.

   *Note Common attributes of components::.

Raymond Toy's avatar
Raymond Toy committed
1402
6.3.9 Require
1403
1404
1405
1406
1407
1408
1409
1410
1411
-------------

Use the implementation's own 'require' to load the MODULE-NAME.

   It is good taste to use ':if-feature _:implementation-name_' rather
than '#+_implementation-name_' to only depend on the specified module on
the specific implementation that provides it.  *Note
if-feature-option::.

Raymond Toy's avatar
Raymond Toy committed
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
6.3.10 Feature dependencies
---------------------------

A feature dependency is of the form '(:feature FEATURE-EXPRESSION
DEPENDENCY)' If the FEATURE-EXPRESSION is satisfied by the running lisp
at the time the system definition is parsed, then the DEPENDENCY will be
added to the system's dependencies.  If the FEATURE-EXPRESSION is _not_
satisfied, then the feature dependency form is ignored.

   Note that this means that ':feature' *cannot* be used to enforce a
feature dependency for the system in question.  I.e., it cannot be used
to require that a feature hold in order for the system definition to be
loaded.  E.g., one cannot use '(:feature :sbcl)' to require that a
system only be used on SBCL.

   Feature dependencies are not to be confused with the obsolete feature
requirement (*note feature requirement: The defsystem grammar.), or with
'if-feature'.

6.3.11 Using logical pathnames
Raymond Toy's avatar
Raymond Toy committed
1432
------------------------------
Raymond Toy's avatar
Raymond Toy committed
1433
1434
1435
1436
1437
1438

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.

   To use logical pathnames, you will have to provide a pathname object
1439
1440
as a ':pathname' specifier to components that use it, using such syntax
as '#p"LOGICAL-HOST:absolute;path;to;component.lisp"'.
Raymond Toy's avatar
Raymond Toy committed
1441
1442

   You only have to specify such logical pathname for your system or
1443
1444
1445
1446
1447
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.  The specification of a logical pathname
host however is _not_ otherwise directly supported in the ASDF syntax
for pathname specifiers as strings.
Raymond Toy's avatar
Raymond Toy committed
1448

1449
   The 'asdf-output-translation' layer will avoid trying to resolve and
Raymond Toy's avatar
Raymond Toy committed
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
translate logical pathnames.  The advantage of this is that you can
define yourself what translations you want to use with the logical
pathname facility.  The disadvantage is that if you do not define such
translations, any system that uses logical pathnames will behave
differently under asdf-output-translations than other systems you use.

   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.

   Note that the reasons we do not recommend logical pathnames are that
1461
(1) there is no portable way to set up logical pathnames _before_ they
Raymond Toy's avatar
Raymond Toy committed
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
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.

Raymond Toy's avatar
Raymond Toy committed
1477
6.3.12 Serial dependencies
1478
--------------------------
Raymond Toy's avatar
Raymond Toy committed
1479

1480
If the ':serial t' option is specified for a module, ASDF will add