asdf.texinfo 261 KB
Newer Older
1 2
\input texinfo          @c -*- texinfo -*-
@c %**start of header
@settitle ASDF Manual
@syncodeindex tp fn
6 7
@c %**end of header

8 9
@c We use @&key, etc to escape & from TeX in lambda lists --
@c so we need to define them for info as well.
@macro AallowOtherKeys
11 12
@end macro
@macro Aoptional
14 15
@end macro
@macro Arest
17 18
@end macro
@macro Akey
20 21
@end macro
@macro Abody
23 24 25
@end macro

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

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

You can find the latest version of this manual at

ASDF Copyright @copyright{} 2001-2016 Daniel Barlow and contributors.

This manual Copyright @copyright{} 2001-2016 Daniel Barlow and contributors.

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

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.


@end copying

@title ASDF: Another System Definition Facility
@subtitle Manual for Version 3.3.0
69 70 71 72 73
@c The following two commands start the copyright page.
@vskip 0pt plus 1filll
@end titlepage

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

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


@node Top, Introduction, (dir), (dir)
@top ASDF: Another System Definition Facility
Manual for Version 3.3.0
86 87
@end ifnottex


89 90 91

* Introduction::
* Quick start summary::
* Loading ASDF::
95 96
* Configuring ASDF::
* Using ASDF::
97 98
* Defining systems with defsystem::
* The object model of ASDF::
* Controlling where ASDF searches for systems::
100 101 102 103 104
* Controlling where ASDF saves compiled files::
* Error handling::
* Miscellaneous additional functionality::
* Getting the latest version::
* FAQ::
105 106
* Ongoing Work::
* Bibliography::
107 108
* Concept Index::
* Function and Class Index::
* Variable Index::              @c @detailmenu
111 112 113 114 115 116 117 118 119

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

123 124 125
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::

130 131 132
Using ASDF

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

136 137 138 139 140 141
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

146 147
* Operations::
* Components::
* Dependencies::
* Functions::


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


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


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

167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186
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::
188 189 190 191 192 193 194 195


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

Controlling where ASDF saves compiled files

196 197 198 199 200
* Output Configurations::
* Output Backward Compatibility::
* Output Configuration DSL::
* Output Configuration Directories::
* Output Shell-friendly syntax for configuration::
* Semantics of Output Translations::
* Output Caching Results::
203 204 205 206 207 208
* Output location API::
* Credits for output translations::

Miscellaneous additional functionality

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


* Where do I report a bug?::
* Mailing list::
* What has changed between ASDF 1 ASDF 2 and ASDF 3?::
218 219 220 221
* 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?::
227 228 229 230 231 232 233 234 235
* 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::
238 239 240 241 242

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?::
* After upgrading ASDF, ASDF (and Quicklisp) can't find my systems: After upgrading ASDF.
244 245 246 247 248 249 250 251 252 253 254 255 256

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?::
* How can I capture ASDF's output?::
* LOAD-PATHNAME has a weird value::
261 262 263

ASDF development FAQs

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
* How do I run the tests interactively in a REPL?::
265 266

@end detailmenu
267 268 269 270 271 272
@end menu

@end ifnottex

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

@node Introduction, Quick start summary, Top, Top
274 275
@comment  node-name,  next,  previous,  up
@chapter Introduction
276 277 278 279 280 281
@cindex ASDF-related features
@vindex *features*
@cindex Testing for ASDF
@cindex ASDF versions
@cindex :asdf
@cindex :asdf2
@cindex :asdf3

284 285
ASDF is Another System Definition Facility:
a tool for specifying how systems of Common Lisp software
are made up of components (sub-systems and files),
287 288
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, @pxref{Quick start summary,,the quick start
291 292 293 294

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,
295 296
and one for implementers of Common Lisp extensions who want to extend
the build system.
For more specifics,
@pxref{Using ASDF},
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.

Note that
306 307 308 309
ASDF is @emph{not} a tool for library and system @emph{installation};
it plays a role like @code{make} or @code{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.
310 311
Despite what the name might suggest,
ASDF-Install was never a part of ASDF, it was a separate piece of software.
ASDF-Install is also unmaintained and obsolete.
We recommend you use Quicklisp
(@uref{}) 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,
317 318 319 320 321 322
so you may more easily modify it,
we recommend clbuild (@uref{}).
As for where on your filesystem to install Common Lisp software,
we recommend subdirectories of @file{~/common-lisp/}:
starting with ASDF 3.1.2 (2014), this hierarchy is included
in the default source-registry configuration.

324 325
Finally, note that this manual is incomplete.
All the bases are covered,
326 327
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,
330 331 332
and the mailing-list the best place to ask for help.

333 334
@node  Quick start summary, Loading ASDF, Introduction, Top
@chapter Quick start summary

337 338 339 340 341

@item To load an ASDF system:

342 343 344 345
Load ASDF itself into your Lisp image, using
@code{(require "asdf")}.
Check that you have a recent version using @code{(asdf:asdf-version)}.
For more details, or if any of the above fails, @pxref{Loading ASDF}.
346 347

348 349
Make sure software is installed where ASDF can find it.
The simplest way is to put all your Lisp code in subdirectories of
@file{~/common-lisp/} (starting with ASDF 3.1.2),
351 352
or @file{~/.local/share/common-lisp/source/}
(for ASDF 2 and later, or if you want to keep source in a hidden directory).
For more details, @pxref{Configuring ASDF to find your systems}.
354 355

356 357
Load your system with @code{(asdf:load-system "@var{my-system}")}.
@xref{Using ASDF}.
358 359 360 361 362 363 364 365 366 367

@end itemize

@item To make your own ASDF system:

As above, load and configure ASDF.

368 369
Make a new directory for your system, @code{@var{my-system}/},
again in a location where ASDF can find it.
370 371
All else being equal, the easiest location is probably
@xref{Configuring ASDF to find your systems}.

374 375

376 377
Create an ASDF system definition listing the dependencies of
your system, its components, and their interdependencies,
378 379
and put it in @file{@var{my-system}.asd}.
This file must have the same name as your system, all lowercase.
@xref{Defining systems with defsystem}.
381 382

Use @code{(asdf:load-system "@var{my-system}")}
to make sure it's all working properly. @xref{Using ASDF}.
385 386 387 388

@end itemize
@end itemize

389 390
@c FIXME: (1) add a sample project that the user can cut and paste to
@c get started.  (2) discuss the option of starting with Quicklisp.
391 392 393 394 395 396

@node Loading ASDF, Configuring ASDF, Quick start summary, Top
@comment  node-name,  next,  previous,  up
@chapter Loading ASDF

400 401 402 403
* Loading a pre-installed ASDF::
* Checking whether ASDF is loaded::
* Upgrading ASDF::
* Replacing your implementation's ASDF::
* Loading ASDF from source::
@end menu

@node  Loading a pre-installed ASDF, Checking whether ASDF is loaded, Loading ASDF, Loading ASDF
409 410
@section Loading a pre-installed ASDF

411 412 413 414 415 416 417
The recommended way to load ASDF is via:
(require "asdf")
@end lisp

All actively maintained Lisp implementations now include a copy of ASDF 3
that you can load this way using Common Lisp's @code{require} function.@footnote{
418 419
NB: all implementations except GNU CLISP also accept
@code{(require "ASDF")}, @code{(require 'asdf)} and @code{(require :asdf)}.
For portability's sake, you should use @code{(require "asdf")}.

If the implementation you are using doesn't provide a recent ASDF 3,
424 425 426 427 428 429
we recommend you upgrade it.
If for some reason you would rather not upgrade it,
we recommend you replace your implementation's ASDF.
@xref{Replacing your implementation's ASDF}.
If all else fails, see @pxref{Loading ASDF from source} below.

430 431
If you use an actively maintained implementation that fails to provide
an up-to-date enough stable release of ASDF,
432 433 434
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.

435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450
As of the writing of this manual,
the following implementations 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:
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 @code{slime-asdf} contrib that makes life easier with ASDF.


@node Checking whether ASDF is loaded, Upgrading ASDF, Loading a pre-installed ASDF, Loading ASDF
453 454
@section Checking whether ASDF is loaded

To check that ASDF is properly loaded, you can run this form:
456 457 458 459 460 461 462

@end lisp

If it returns a string,
that is the version of ASDF that is currently installed.
463 464
If that version is suitably recent (say, 3.1.2 or later),
then you can skip directly to next chapter: @xref{Configuring ASDF}.
465 466 467

If it raises an error,
then either ASDF is not loaded, or
468 469
you are using a very old version of ASDF,
and need to install ASDF 3.

471 472
For more precision in detecting versions old and new,
@pxref{How do I detect the ASDF version?}.

474 475 476 477
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.

@node  Upgrading ASDF, Replacing your implementation's ASDF, Checking whether ASDF is loaded, Loading ASDF
@section Upgrading ASDF
481 482 483
@c FIXME: tighten this up a bit -- there's a lot of stuff here that
@c doesn't matter to almost anyone.  Move discussion of updating antique
@c versions of ASDF down, or encapsulate it.

If your implementation already provides ASDF 3 or later (and it should),
486 487 488
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.
489 490
We recommend you download an official tarball or checkout a release from git into
491 492
(@pxref{Configuring ASDF to find your systems}).

Once the source code for ASDF is installed,
you don't need any extra step to load it beyond the usual @code{(require "asdf")}:
ASDF 3 will automatically look whether an updated version of itself is available
496 497
amongst the regularly configured systems, before it compiles anything else.

498 499
If your implementation fails to provide ASDF 3 or later,
@pxref{Replacing your implementation's ASDF}.


502 503
@node Replacing your implementation's ASDF, Loading ASDF from source, Upgrading ASDF, Loading ASDF
@section Replacing your implementation's ASDF
504 505

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

508 509
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.
513 514
This requires proper write permissions and
may necessitate execution as a system administrator.

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

This script works on
524 525 526 527 528
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.


@node Loading ASDF from source,  , Replacing your implementation's ASDF, Loading ASDF
@section Loading ASDF from source

535 536 537
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 @file{asdf.lisp}
538 539 540 541 542
somewhere and load it with:

(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{,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.
550 551
@xref{Getting the latest version}.

552 553 554 555
For scripts that try to use ASDF simply via @code{require} at first, and
make heroic attempts to load it the hard way if at first they don't succeed,
see @file{tools/load-asdf.lisp} distributed with the ASDF source repository,
or the code of @url{,@code{cl-launch}}.


558 559
@node Configuring ASDF, Using ASDF, Loading ASDF, Top
@comment  node-name,  next,  previous,  up
560 561
@chapter Configuring ASDF

562 563 564 565 566 567
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 @xref{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.
Robert P. Goldman's avatar
Robert P. Goldman committed
568 569 570

* Configuring ASDF to find your systems::
* Configuring ASDF to find your systems --- old style::
* Configuring where ASDF stores object files::
* Resetting the ASDF configuration::
Robert P. Goldman's avatar
Robert P. Goldman committed
575 576
@end menu

@node Configuring ASDF to find your systems, Configuring ASDF to find your systems --- old style, Configuring ASDF, Configuring ASDF
578 579
@section Configuring ASDF to find your systems

Robert P. Goldman's avatar
Robert P. Goldman committed
In order to compile and load your systems, ASDF must be configured to find
581 582
the @file{.asd} files that contain system definitions.

Robert P. Goldman's avatar
Robert P. Goldman committed
583 584 585 586
There are a number of different techniques for setting yourself up with
ASDF, starting from easiest to the most complex:

@itemize @bullet

589 590
Put all of your systems in one of the standard locations,
subdirectories of
@file{~/common-lisp/} or
@end itemize
If you install software there, you don't need further
598 599 600 601 602 603 604 605
  @file{~/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.
You can then skip to the next section. @xref{Loading a system}.
Robert P. Goldman's avatar
Robert P. Goldman committed

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

Robert P. Goldman's avatar
Robert P. Goldman committed
613 614 615 616
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 @code{source-registry} facility,
fully described in its own chapter of this manual.
617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646
@xref{Controlling where ASDF searches for systems}.
Here is a quick recipe for getting started.

First create the directory
  For Windows users, and starting with ASDF 3.1.5, start from your
  @file{%LOCALAPPDATA%}, which is usually @file{~/AppData/Local/}
  (but you can ask in a @code{CMD.EXE} terminal
  @code{echo %LOCALAPPDATA%} to make sure)
  and underneath create a subpath
there create a file with any name of your choice
but with the type @file{conf}@footnote{
  By requiring the @file{.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.

  ASDF will also ignore files whose names start with a @file{.} character.

  It is customary to start the filename with two digits, to control the
  sorting of the @code{conf} files in the source registry directory, and
  thus the order in which the directories will be scanned.
for instance @file{50-luser-lisp.conf};
in this file, add the following line
to tell ASDF to recursively scan all the subdirectories under @file{/home/luser/lisp/}
for @file{.asd} files:
@kbd{(:tree "/home/luser/lisp/")}

648 649 650 651 652 653
That's enough. You may replace @file{/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 @file{~/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 @kbd{(:tree (:home "common-lisp/"))} for bootstrap purposes,
then install a recent source tree of ASDF under @file{~/common-lisp/asdf/}.

655 656 657 658
If you prefer to use a ``link farm'', which is faster to use but costlier to manage than a recursive traversal,
say at @file{/home/luser/.asd-link-farm/}, then
you may instead (or additionally) create a file @file{42-asd-link-farm.conf}, containing the line:
@kbd{(:directory "/home/luser/.asd-link-farm/")}
659 660 661

ASDF will automatically read your configuration
the first time you try to find a system.
Robert P. Goldman's avatar
Robert P. Goldman committed
If necessary, you can reset the source-registry configuration with:

664 665 666 667
@end lisp

Robert P. Goldman's avatar
Robert P. Goldman committed
668 669
In earlier versions of ASDF, the system source registry was configured
670 671 672 673
using a global variable, @code{asdf:*central-registry*}.
For more details about this, see the following section,
@ref{Configuring ASDF to find your systems --- old style}.
Unless you need to understand this,
Robert P. Goldman's avatar
Robert P. Goldman committed
skip directly to @ref{Configuring where ASDF stores object files}.

Robert P. Goldman's avatar
Robert P. Goldman committed
676 677 678 679 680 681 682
@end itemize

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

@node Configuring ASDF to find your systems --- old style, Configuring where ASDF stores object files, Configuring ASDF to find your systems, Configuring ASDF
684 685
@section Configuring ASDF to find your systems --- old style

686 687 688

@c FIXME: this section should be moved elsewhere.  The novice user
@c should not be burdened with it. [2014/02/27:rpg]

Novices may skip this section.
691 692
Please @emph{do not} use the central-registry if you are a novice,
and @emph{do not} instruct novices to use the central-registry.
693 694 695 696
@c ``Experts may read it then proceed to ...''
@c some better section explaining
@c *central-registry* vs source-registry vs *system-definition-search-functions*,
@c and .../asdf/tools/cl-source-registry-cache.lisp
697 698 699 700 701

The old way to configure ASDF to find your systems is by
@code{push}ing directory pathnames onto the variable

702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722
You @emph{must} configure this variable @emph{after} you load ASDF 3 or later,
yet @emph{before} the first time you try to use it.
This loading and configuring of ASDF must happen
as part of some initialization script:
typically, either a script you maintain that builds your project,
or your implementation's initialization script
(e.g. @file{~/.sbclrc} for SBCL).

Also, if you are using an ancient ASDF 2 or earlier to load ASDF 3 or later,
then after it loads the ancient ASDF, your script @emph{must} configure
the central-registry a first time to tell ASDF 1 or 2 where to find ASDF 3,
then load ASDF 3 with e.g. @code{(asdf:operate 'asdf:load-op "asdf")},
then configure the central-registry again, because
ASDF 3 will not preserve the central-registry from ASDF 2 when upgrading.
You should probably be using the source-registry instead, which will be preserved
(unless you manually called @code{asdf:initialize-source-registry} with an argument,
in which case you will have to do it again indeed).
However, if you are using an ancient ASDF 2 or earlier,
we @emph{strongly} recommend that you should instead upgrade your implementation,
or overwrite the ancient ASDF installation with a more recent one:
@xref{Replacing your implementation's ASDF}.

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

734 735
For example, let's say you want ASDF to find the @file{.asd} file
In your Lisp initialization file, you could have the following:
737 738

(require "asdf")
740 741 742 743 744
(push "/home/me/src/foo/" asdf:*central-registry*)
@end lisp

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

Strings and pathname objects are self-evaluating,
in which case the @code{eval} step does nothing;
751 752 753
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
754 755 756 757 758 759
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 (or @code{nil}).
761 762
By ``directory'', we mean
``designator for a pathname with a non-empty DIRECTORY component''.
The trailing directory name separator
is necessary to tell Lisp that you're discussing a directory
766 767 768
rather than a file.  If you leave it out, ASDF is likely to look in
@code{/home/me/src/} instead of @code{/home/me/src/foo/} as you
intended, and fail to find your system definition.
769 770
Modern versions of ASDF will issue an error and offer you to
remove such entries from the central-registry.

772 773 774
Typically there are a lot of @file{.asd} files, and
a common idiom was to put
@emph{symbolic links} to all of one's @file{.asd} files
775 776
in a common directory
and push @emph{that} directory (the ``link farm'')
777 778 779 780 781 782
instead of pushing each individual system directory.

ASDF knows to follow @emph{symlinks}
to the actual location of the systems.@footnote{
783 784 785
  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.

For example, if @code{#p"/home/me/cl/systems/"}
788 789
is an element of @code{*central-registry*}, you could set up the
system @var{foo} as follows:
790 791 792 793 794 795

$ 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,
797 798
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.


@node Configuring where ASDF stores object files, Resetting the ASDF configuration, Configuring ASDF to find your systems --- old style, Configuring ASDF
@section Configuring where ASDF stores object files
@findex clear-output-translations
804 805 806 807 808

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 to be shared
between several versions of several Common Lisp implementations,
811 812 813 814
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.

Starting with ASDF 2, the @code{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,
@ref{Controlling where ASDF saves compiled files}.

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
@c FIXME: possibly this should be moved elsewhere.  It's redundant here,
@c and makes this section of the manual too long and daunting for the
@c new user. [2014/02/27:rpg]
@c The simplest way to add a translation to your search path,
@c say from @file{/foo/bar/baz/quux/}
@c to @file{/where/i/want/my/fasls/}
@c is to create the directory
@c @file{~/.config/common-lisp/asdf-output-translations.conf.d/}
@c and there create a file with any name of your choice and the type @file{conf},
@c for instance @file{42-bazquux.conf}
@c containing the line:

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

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

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

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

@c @kbd{(t t)}

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

@c The required @file{.conf} extension allows you to have disabled files
@c or editor backups (ending in @file{~}), and works portably
@c (for instance, it is a pain to allow both empty and non-empty extension on CLISP).
@c Excluded are files the name of which start with a @file{.} character.
@c It is customary to start the filename with two digits
@c that specify the order in which the directories will be scanned.

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

@c @lisp
@c (asdf:clear-output-translations)
@c @end lisp

869 870 871 872 873 874
@c And you probably should do so before you dump your Lisp image,
@c if the configuration may change
@c between the machine where you save it at the time you save it
@c and the machine you resume it at the time you resume it.
@c (Once again, you should use @code{(asdf:clear-configuration)}
@c before you dump your Lisp image, which includes the above.)

Note that before ASDF 2,
877 878 879 880
other ASDF add-ons offered the same functionality,
each in subtly different and incompatible ways:
ASDF-Binary-Locations, cl-launch, common-lisp-controller.
ASDF-Binary-Locations is now not needed anymore and should not be used.
cl-launch 3.000 and common-lisp-controller 7.2 have been updated
to delegate object file placement to ASDF.

@node Resetting the ASDF configuration,  , Configuring where ASDF stores object files, Configuring ASDF
885 886
@section Resetting the ASDF configuration

887 888
@c FIXME: this should probably be moved out of the "quickstart" part of
@c the manual. [2014/02/27:rpg]

890 891 892 893 894 895

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
897 898 899
   regarding source-registry or output-translations.
@end defun

@vindex *image-dump-hook*
901 902 903 904 905 906 907 908 909
This function is pushed onto the @code{uiop:*image-dump-hook*} by default,
which means that if you save an image using @code{uiop:dump-image},
or via @code{asdf:image-op} and @code{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 @code{clear-configuration} manually,
or push it into your implementation's equivalent of @code{uiop:*image-dump-hook*},
e.g. @code{sb-ext:*save-hooks*} on SBCL, or @code{ext:*before-save-initializations*}
on CMUCL and SCL, etc.

@node  Using ASDF, Defining systems with defsystem, Configuring ASDF, Top
912 913
@chapter Using ASDF

Robert P. Goldman's avatar
Robert P. Goldman committed
914 915
* Loading a system::
* Convenience Functions::
Robert P. Goldman's avatar
Robert P. Goldman committed
917 918 919
* Moving on::
@end menu

@node Loading a system, Convenience Functions, Using ASDF, Using ASDF
921 922 923 924
@section Loading a system

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

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

930 931
On some implementations (@pxref{Convenience Functions}),
ASDF hooks into the @code{cl:require} facility and you can just use:
Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
932 933 934 935 936

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

937 938 939
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 @code{symbol-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.

943 944
The lower-casing-symbols behaviour is unconventional,
but was selected after some consideration.
945 946 947 948 949
The type of systems we want to support
either have lowercase as customary case (Unix, Mac, Windows)
or silently convert lowercase to uppercase (lpns).
@c so this makes more sense than attempting to use @code{:case :common},
@c which is reported not to work on some implementations


952 953
@node Convenience Functions, Moving on, Loading a system, Using ASDF
@section Convenience Functions
Robert Goldman's avatar
Robert Goldman committed

955 956 957 958 959 960 961
@c I believe thes are all unnecessary because of the function macros
@c below [2016/01/30:rpg]
@c @findex load-system
@c @findex compile-system
@c @findex test-system
@c @findex require-system
@c @findex make

ASDF provides three commands for the most common system operations:
@code{load-system}, @code{compile-system}, and @code{test-system}.
965 966 967 968 969 970 971 972 973 974 975 976

ASDF also provides @code{require-system}, a variant of @code{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 @code{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 @code{make},
instead of loading.  If the system developer doesn't specify in the
system definition, the default operation will be loading.

978 979
@c FIXME: We seem to export @findex bundle-system also, that some ECL users seem to rely on.
@c But it's probably better that bundle operations have their own manual chapter at some point.

981 982 983 984

@c FIXME: There should be a @defun for OPERATE, but there isn't.  Not
@c sure where it belongs...  The discussion here is just confusing if
@c the reader doesn't understand how ASDF works. [2016/01/30:rpg]
985 986 987
@findex operate
@findex oos

988 989
Because ASDF is an extensible system
for defining @emph{operations} on @emph{components},
990 991
it also provides a generic function @code{operate},
so you may arbitrarily operate on your systems beyond the default operations.
992 993 994
(At the interactive REPL, users often use its shorter alias @code{oos},
which stands for operate-on-system, a name inherited from @code{mk-defsystem}.)
You'll use @code{operate} whenever you want to do something beyond
compiling, loading and testing.

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

1001 1002
@c FIXME: the following is too complicated for here, especially since
@c :force hasn't been defined yet.  Move it. [2014/02/27:rpg]

@vindex *load-system-operation*
@findex already-loaded-systems
1006 1007 1008

@defun load-system system @Arest{} keys @Akey{} force force-not verbose version @AallowOtherKeys{}
Apply @code{operate} with the operation from
the @var{system}, and any provided keyword arguments.
@code{*load-system-operation*} by default is @code{load-op};
1012 1013 1014 1015 1016
it would be @code{load-bundle-op} by default on ECL,
if only an implementation bug were fixed.
Calling @code{load-system} is the regular, recommended way
to load a system into the current image.
@end defun

1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040
@defun compile-system system @Arest{} keys @Akey{} force force-not verbose version @AallowOtherKeys{}
Apply @code{operate} with the operation @code{compile-op},
the @var{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 @emph{not} load all compiled files in the current image.
This function exists for symmetry with @code{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 @code{program-op} rather than @code{compile-op}.
@end defun

@defun test-system system @Arest{} keys @Akey{} force force-not verbose version @AallowOtherKeys{}
Apply @code{operate} with the operation @code{test-op},
the @var{system}, and any provided keyword arguments.
@end defun

@defun make system @Arest{} keys @Akey{} @AallowOtherKeys{}
Do ``The Right Thing'' with your system.
Starting with ASDF 3.1, this function @code{make} is also available.
The default behaviour is to load the system as if by @code{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,
1041 1042 1043 1044
with a @code{:build-operation} option in the @code{defsystem} form
(@pxref{The defsystem grammar, build-operation}),
and an intended output pathname for that operation with
1045 1046
@c Document :build-operation in the defsystem section.
@c Document in the extension section that for richer programmatic access, you may instead use an overriding
1047 1048 1049
@c @code{(defmethod component-depends-on ((o build-op) (s system))
@c ...)}.
This function is experimental and largely untested.  Use at your own risk.
@end defun
@cindex build-operation

@defun require-system system @Arest{} keys @Akey{} @AallowOtherKeys{}
@code{require-system} skips any update to systems that have already been loaded,
in the spirit of @code{cl:require}.
1056 1057
It does it by calling @code{load-system} with a keyword option
excluding already loaded systems.@footnote{
1058 1059
  For the curious, the option is @code{:force-not (already-loaded-systems)}.
1060 1061 1062 1063 1064
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, @code{cl:require} too can load ASDF systems,
by falling back on @code{require-system}
for module names not recognized by the implementation.
1065 1066
(Note however that @code{require-system} does @emph{not} fall back on @code{cl:require};
that would introduce an ``interesting'' potential infinite loop to break somehow.)

@code{cl:require} and @code{require-system} are appropriate to load code
that is not being modified during the current programming session.
1070 1071 1072 1073 1074 1075 1076 1077
@code{cl:require} will notably load the implementation-provided extension modules;
@code{require-system} won't, unless they are also defined as systems somehow,
which SBCL and MKCL do.
@code{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;
@code{cl:require} on the above-mentioned implementations will delegate to @code{require-system}
and may load them as well.
But for code that you are actively developing, debugging, or otherwise modifying,
you should use @code{load-system}, so ASDF will pick on your modifications
1080 1081 1082 1083
and transitively re-build the modified files and everything that depends on them
(that the requested @var{system} itself depends on ---
ASDF itself never builds anything unless
it's an explicitly requested system or the dependencies thereof).
1084 1085
@end defun

1086 1087

@node Moving on,  , Convenience Functions, Using ASDF
@section Moving on

1090 1091 1092 1093 1094
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
1097 1098 1099
@comment  node-name,  next,  previous,  up
@chapter Defining systems with defsystem

This chapter describes how to use ASDF to define systems and develop
1101 1102 1103 1104

1105 1106 1107 1108
* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
* The package-inferred-system extension::
1110 1111 1112 1113 1114
@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
@findex defsystem
1116 1117
@cindex asdf-user
@findex load-asd

1119 1120
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.
1123 1124
This is a complete file that should be saved as @file{hello-lisp.asd}
(in order that ASDF can find it
1125 1126
when ordered to operate on the system named @code{"hello-lisp"}).

;; Usual Lisp comments are allowed here

(defsystem "hello-lisp"
  :description "hello-lisp: a sample Lisp system."
  :version "0.0.1"
1133 1134
  :author "Joe User <>"
  :licence "Public Domain"
  :depends-on ("optima.ppcre" "command-line-arguments")
1136 1137 1138
  :components ((:file "packages")
               (:file "macros" :depends-on ("packages"))
               (:file "hello" :depends-on ("macros"))))
1139 1140 1141 1142 1143
@end lisp

Some notes about this example:


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

1151 1152
The @file{.lisp} suffix is implicit for Lisp source files.
The source files are located in the same directory
1153 1154 1155 1156 1157 1158 1159 1160 1161
as the @code{.asd} file with the system definition.
@c FIXME: the following should live somewhere, but not in the quickstart
@c page. [2014/05/03:rpg]
@c ASDF resolves symbolic links (or Windows shortcuts)
@c before loading the system definition file and
@c stores its location in the resulting system@footnote{
@c It is possible, though almost never necessary, to override this behaviour.}.
@c This is a good thing because the user can move the system sources
@c without having to edit the system definition.

1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186
@c FIXME: The first example system should probably use just :serial T.
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} then @file{macros}
before starting the compilation of file @file{hello}.

This example system has external dependencies on two other systems,
@code{optima.ppcre} (that provides a friendly interface to matching regular expressions),
and @code{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 @code{hello-lisp}.

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

1187 1188 1189
@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.
@c FIXME: this is way too detailed for the first example!
@c move it!
Make sure you know how the @code{:version} numbers will be parsed!
Only period-separated non-negative integers are accepted at present.
See below Version specifiers in @ref{The defsystem grammar}.
1196 1197

Francois-Rene Rideau's avatar
Francois-Rene Rideau committed
1198 1199 1200 1201
This file contains a single form, the @code{defsystem} declaration.
No @code{in-package} form, no @code{asdf:} package prefix, no nothing.
Just the one naked @code{defsystem} form.
This is what we recommend.
1202 1203 1204 1205
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.

1206 1207
@cindex :version

1208 1209
@end itemize

1210 1211 1212 1213 1214 1215
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.
@c FIXME: divide the next example into many examples, to introduce fewer concepts at once.

1216 1217 1218
@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
@findex defsystem
1220 1221 1222 1223 1224

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

1225 1226
(in-package :asdf-user)

(defsystem "foo"
1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248
  :version (:read-file-form "variables" :at (3 2))
  ((: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)
         :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")
1249 1250
@end lisp

1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272
Here are some notes about this example:


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

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

Note that the @code{: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
@file{mod/} (this location could have been overridden to be
in the same directory, or in a different subdirectory;
see the discussion of the @code{:pathname} option in @ref{The defsystem grammar}).

1274 1275 1276 1277 1278 1279 1280 1281
The @code{:serial t} says that each sub-component of @code{mod} depends on the previous components,
so that @file{cooker.lisp} depends-on @file{utils.lisp}, which depends-on @file{reader.lisp}.
Also @file{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.

1282 1283
The method-form tokens provide a shorthand for defining methods on
particular components.  This part
1284 1285

1286 1287 1288 1289 1290
     :output-files (compile-op (o c) (list "data.cooked"))
     :perform (compile-op :after (o c)
         :in (component-pathname (find-component c "data.raw"))
         :out (first (output-files o c))))
1291 1292 1293 1294 1295
@end lisp

has the effect of

1296 1297 1298 1299 1300 1301
(defmethod output-files ((o compile-op) (c (eql ...)))
  (list "data.cooked"))
(defmethod perform :after ((o compile-op) (c (eql ...)))
   :in (component-pathname (find-component c "data.raw"))
   :out (first (output-files o c))))
1302 1303
@end lisp

where @code{...} is the component in question.
In this case @code{...} would expand to something like
1306 1307

(find-component "foo" "mod")
1309 1310
@end lisp

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

1316 1317 1318 1319 1320 1321
There is an additional @code{defmethod} with a similar effect,
because ASDF (as of ASDF 3.1.5)
fails to accept inline-methods as above for @code{action-description},
instead only supporting the deprecated @code{explain} interface.

@c FIXME: The following plunge into detail weeds is not appropriate in this
1323 1324 1325 1326 1327 1328
@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.

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

1334 1335 1336 1337 1338 1339
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.

1341 1342
@c FIXME: move most of this package discussion to its own section,
@c and leave only a reference here.

1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 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
The file starts with a form @code{(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 @code{in-package} form.

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

You shouldn't use an @code{in-package} form
if you're keeping things simple.
You should only use @code{in-package} (and before it, a @code{defpackage})
when you're going to define new classes, functions, variables, macros, etc.,
in the @code{.asd} file, and want to thereby avoid name clashes.
Manuals for old versions of ASDF recommended use of such an idiom in @file{.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 @code{:defsystem-depends-on}.
@xref{The defsystem grammar}.

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

@code{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@footnote{
  ASDF 1 and 2 (up until 2.26)
  used to dynamically create and delete temporary packages @code{asdf@emph{N}},
  one for each @file{.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 @code{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 @code{asdf-user} package also uses @code{uiop/common-lisp},
  a variant of the @code{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.
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, @code{asdf-user} uses @code{uiop},
whereas in earlier variants of ASDF 3 it only used @code{uiop/package}.
We recommend you either prefix use of UIOP functions with the package prefix @code{uiop:},
or make sure your system @code{:depends-on ((:version "asdf" "3.1.2"))}
or has a @code{#-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 @code{(defparameter *foo-version* "5.6.7")}.

@end itemize
1414 1415

@node  The defsystem grammar, Other code in .asd files, A more involved example, Defining systems with defsystem
1417 1418
@comment  node-name,  next,  previous,  up
@section The defsystem grammar
1419 1420
@findex defsystem
@cindex DEFSYSTEM grammar

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


1427 1428
system-definition := ( defsystem system-designator @var{system-option}* )

1429 1430
system-option := :defsystem-depends-on system-list
                 | :weakly-depends-on @var{system-list}
                 | :class class-name (see discussion below)
                 | :build-operation @var{operation-name}
                 | system-option
1434 1435 1436
                 | module-option
                 | option

# These are only available since ASDF 3 (actually its alpha release 2.27)
1438 1439 1440 1441 1442
system-option := :homepage string
                 | :bug-tracker string
                 | :mailto string
                 | :long-name string
                 | :source-control source-control
                 | :version version-specifier
1444 1445 1446

source-control := (keyword string)

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

option :=
        | :pathname pathname-specifier