1 \input texinfo @c -*- texinfo -*-
7 @c We use @&key, etc to escape & from TeX in lambda lists --
8 @c so we need to define them for info as well.
9 @macro &allow-other-keys
26 @dircategory Software development
28 * asdf: (asdf). Another System Definition Facility (for Common Lisp)
32 This manual describes ASDF, a system definition facility
33 for Common Lisp programs and libraries.
35 You can find the latest version of this manual at
36 @url{http://common-lisp.net/project/asdf/asdf.html}.
38 ASDF Copyright @copyright{} 2001-2011 Daniel Barlow and contributors.
40 This manual Copyright @copyright{} 2001-2011 Daniel Barlow and contributors.
42 This manual revised @copyright{} 2009-2011 Robert P. Goldman and Francois-Rene Rideau.
44 Permission is hereby granted, free of charge, to any person obtaining
45 a copy of this software and associated documentation files (the
46 ``Software''), to deal in the Software without restriction, including
47 without limitation the rights to use, copy, modify, merge, publish,
48 distribute, sublicense, and/or sell copies of the Software, and to
49 permit persons to whom the Software is furnished to do so, subject to
50 the following conditions:
52 The above copyright notice and this permission notice shall be
53 included in all copies or substantial portions of the Software.
55 THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY KIND,
56 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
57 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
58 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
59 LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
60 OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
61 WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
68 @title ASDF: Another System Definition Facility
70 @c The following two commands start the copyright page.
72 @vskip 0pt plus 1filll
76 @c Output the table of contents at the beginning.
79 @c -------------------
83 @node Top, Introduction, (dir), (dir)
84 @top asdf: another system definition facility
93 * Defining systems with defsystem::
94 * The object model of ASDF::
95 * Controlling where ASDF searches for systems::
96 * Controlling where ASDF saves compiled files::
98 * Miscellaneous additional functionality::
99 * Getting the latest version::
104 * Function and Class Index::
108 @c --- The Detailed Node Listing ---
110 @c Defining systems with defsystem
112 @c * The defsystem form::
113 @c * A more involved example::
114 @c * The defsystem grammar::
115 @c * Other code in .asd files::
117 @c The object model of ASDF
124 @c * Predefined operations of ASDF::
125 @c * Creating new operations::
129 @c * Common attributes of components::
130 @c * Pre-defined subclasses of component::
131 @c * Creating new component types::
135 @c * Pre-defined subclasses of component::
136 @c * Creating new component types::
143 @c -------------------
145 @node Introduction, Loading ASDF, Top, Top
146 @comment node-name, next, previous, up
147 @chapter Introduction
148 @cindex ASDF-related features
150 @cindex Testing for ASDF
151 @cindex ASDF versions
155 ASDF is Another System Definition Facility:
156 a tool for specifying how systems of Common Lisp software
157 are comprised of components (sub-systems and files),
158 and how to operate on these components in the right order
159 so that they can be compiled, loaded, tested, etc.
161 ASDF presents three faces:
162 one for users of Common Lisp software who want to reuse other people's code,
163 one for writers of Common Lisp software who want to specify how to build their systems,
164 one for implementers of Common Lisp extensions who want to extend the build system.
165 @xref{Using ASDF,,Loading a system},
166 to learn how to use ASDF to load a system.
167 @xref{Defining systems with defsystem},
168 to learn how to define a system of your own.
169 @xref{The object model of ASDF}, for a description of
170 the ASDF internals and how to extend ASDF.
173 We have released ASDF 2.000 on May 31st 2010.
174 Subsequent releases of ASDF 2 have since then been included
175 in all actively maintained CL implementations that used to bundle ASDF 1,
176 plus some implementations that didn't use to,
177 and has been made to work with all actively used CL implementations and a few more.
178 @xref{FAQ,,``What has changed between ASDF 1 and ASDF 2?''}.
179 Furthermore, it is possible to upgrade from ASDF 1 to ASDF 2 on the fly.
180 For this reason, we have stopped supporting ASDF 1;
181 if you are using ASDF 1 and are experiencing any kind of issues or limitations,
182 we recommend you upgrade to ASDF 2
183 --- and we explain how to do that. @xref{Loading ASDF}.
185 Also note that ASDF is not to be confused with ASDF-Install.
186 ASDF-Install is not part of ASDF, but a separate piece of software.
187 ASDF-Install is also unmaintained and obsolete.
188 We recommend you use Quicklisp instead,
189 which works great and is being actively maintained.
190 If you want to download software from version control instead of tarballs,
191 so you may more easily modify it, we recommend clbuild.
194 @node Loading ASDF, Configuring ASDF, Introduction, Top
195 @comment node-name, next, previous, up
196 @chapter Loading ASDF
197 @vindex *central-registry*
200 @findex compile-system
202 @cindex system directory designator
207 @c * Installing ASDF::
211 @section Loading a pre-installed ASDF
213 Many Lisp implementations include a copy of ASDF.
214 You can usually load this copy using Common Lisp's @code{require} function:
220 As of the writing of this manual,
221 the following implementations provide ASDF 2 this way:
222 abcl allegro ccl clisp cmucl ecl sbcl xcl.
223 The following implementations don't provide it yet but will in a future release:
225 The following implementations are obsolete and most probably will never bundle it:
226 cormancl gcl genera mcl.
228 If the implementation you are using doesn't provide ASDF 2,
229 see @pxref{Loading ASDF,,Loading an otherwise installed ASDF} below.
230 If that implementation is still actively maintained,
231 you may also send a bug report to your Lisp vendor and complain
232 about their failing to provide ASDF.
234 NB: all implementations except clisp also accept
235 @code{(require "ASDF")}, @code{(require 'asdf)} and @code{(require :asdf)}.
236 For portability's sake, you probably want to use @code{(require "asdf")}.
239 @section Checking whether ASDF is loaded
241 To check whether ASDF is properly loaded in your current Lisp image,
242 you can run this form:
248 If it returns a string,
249 that is the version of ASDF that is currently installed.
251 If it raises an error,
252 then either ASDF is not loaded, or
253 you are using an old version of ASDF.
255 You can check whether an old version is loaded
256 by checking if the ASDF package is present.
257 The form below will allow you to programmatically determine
258 whether a recent version is loaded, an old version is loaded,
262 (or #+asdf2 (asdf:asdf-version) #+asdf :old)
265 If it returns a version number, that's the version of ASDF installed.
266 If it returns the keyword @code{:OLD},
267 then you're using an old version of ASDF (from before 1.635).
268 If it returns @code{NIL} then ASDF is not installed.
270 If you are experiencing problems with ASDF,
271 please try upgrading to the latest released version,
272 using the method below,
273 before you contact us and raise an issue.
276 @section Upgrading ASDF
278 If your implementation does provide ASDF 2 or later,
279 and you want to upgrade to a more recent version,
280 just install ASDF like any other package
281 (see @pxref{Loading ASDF,,Loading an otherwise installed ASDF} below),
282 configure ASDF as usual (see @pxref{Configuring ASDF} below),
287 (asdf:load-system :asdf)
290 If on the other hand, your implementation only provides an old ASDF,
291 you will require a special configuration step and an old-style loading:
295 (push #p"@var{/path/to/new/asdf/}" asdf:*central-registry*)
296 (asdf:oos 'asdf:load-op :asdf)
299 Don't forget the trailing @code{/} at the end of your pathname.
301 Also, note that older versions of ASDF won't redirect their output,
302 or at least won't do it according to your usual ASDF 2 configuration.
303 You therefore need write access on the directory
304 where you install the new ASDF,
305 and make sure you're not using it
306 for multiple mutually incompatible implementations.
307 At worst, you may have to have multiple copies of the new ASDF,
308 e.g. one per implementation installation, to avoid clashes.
309 Note that to our knowledge all implementations that provide ASDF
310 provide ASDF 2 in their latest release, so
311 you may want to upgrade your implementation rather than go through that hoop.
313 Finally, note that there are some limitations to upgrading ASDF:
316 Any ASDF extension becomes invalid, and will need to be reloaded.
317 This applies to e.g. CFFI-Grovel, or to hacks used by ironclad, etc.
318 Starting with ASDF 2.014.8, ASDF will actually invalidate
319 all previously loaded systems when it is loaded on top of
320 a different ASDF version.
322 Until all implementations provide ASDF 2.015 or later,
323 it is safer if you upgrade ASDF and its extensions as a special step
324 at the very beginning of whatever script you are running,
325 before you start using ASDF to load anything else.
327 Until all implementations provide ASDF 2.015 or later,
328 it is unsafe to upgrade ASDF as part of loading a system
329 that depends on a more recent version of ASDF,
330 since the new one might shadow the old one while the old one is running,
331 and the running old one will be confused
332 when extensions are loaded into the new one.
333 In the meantime, we recommend that your systems should @emph{not} specify
334 @code{:depends-on (:asdf)}, or @code{:depends-on ((:version :asdf "2.010"))},
335 but instead that they check that a recent enough ASDF is installed,
338 (unless (or #+asdf2 (asdf:version-satisfies
339 (asdf:asdf-version) *required-asdf-version*))
340 (error "FOO requires ASDF ~A or later." *required-asdf-version*))
345 @section Loading an otherwise installed ASDF
347 If your implementation doesn't include ASDF,
348 if for some reason the upgrade somehow fails,
349 does not or cannot apply to your case,
350 you will have to install the file @file{asdf.lisp}
351 somewhere and load it with:
354 (load "/path/to/your/installed/asdf.lisp")
357 The single file @file{asdf.lisp} is all you normally need to use ASDF.
359 You can extract this file from latest release tarball on the
360 @url{http://common-lisp.net/project/asdf/,ASDF website}.
361 If you are daring and willing to report bugs, you can get
362 the latest and greatest version of ASDF from its git repository.
363 @xref{Getting the latest version}.
365 For maximum convenience you might want to have ASDF loaded
366 whenever you start your Lisp implementation,
367 for example by loading it from the startup script or dumping a custom core
368 --- check your Lisp implementation's manual for details.
371 @node Configuring ASDF, Using ASDF, Loading ASDF, Top
372 @comment node-name, next, previous, up
374 @chapter Configuring ASDF
376 @section Configuring ASDF to find your systems
378 So it may compile and load your systems, ASDF must be configured to find
379 the @file{.asd} files that contain system definitions.
381 Since ASDF 2, the preferred way to configure where ASDF finds your systems is
382 the @code{source-registry} facility,
383 fully described in its own chapter of this manual.
384 @xref{Controlling where ASDF searches for systems}.
386 The default location for a user to install Common Lisp software is under
387 @file{~/.local/share/common-lisp/source/}.
388 If you install software there, you don't need further configuration.
389 If you're installing software yourself at a location that isn't standard,
390 you have to tell ASDF where you installed it. See below.
391 If you're using some tool to install software (e.g. Quicklisp),
392 the authors of that tool should already have configured ASDF.
394 The simplest way to add a path to your search path,
395 say @file{/home/luser/.asd-link-farm/}
396 is to create the directory
397 @file{~/.config/common-lisp/source-registry.conf.d/}
398 and there create a file with any name of your choice,
399 and with the type @file{conf},
400 for instance @file{42-asd-link-farm.conf}
403 @kbd{(:directory "/home/luser/.asd-link-farm/")}
405 If you want all the subdirectories under @file{/home/luser/lisp/}
406 to be recursively scanned for @file{.asd} files, instead use:
408 @kbd{(:tree "/home/luser/lisp/")}
410 Note that your Operating System distribution or your system administrator
411 may already have configured system-managed libraries for you.
413 The required @file{.conf} extension allows you to have disabled files
414 or editor backups (ending in @file{~}), and works portably
415 (for instance, it is a pain to allow both empty and non-empty extension on CLISP).
416 Excluded are files the name of which start with a @file{.} character.
417 It is customary to start the filename with two digits
418 that specify the order in which the directories will be scanned.
420 ASDF will automatically read your configuration
421 the first time you try to find a system.
422 You can reset the source-registry configuration with:
425 (asdf:clear-source-registry)
428 And you probably should do so before you dump your Lisp image,
429 if the configuration may change
430 between the machine where you save it at the time you save it
431 and the machine you resume it at the time you resume it.
434 @section Configuring ASDF to find your systems --- old style
436 The old way to configure ASDF to find your systems is by
437 @code{push}ing directory pathnames onto the variable
438 @code{asdf:*central-registry*}.
440 You must configure this variable between the time you load ASDF
441 and the time you first try to use it.
442 Loading and configuring ASDF presumably happen
443 as part of some initialization script that builds or starts
444 your Common Lisp software system.
445 (For instance, some SBCL users used to put it in their @file{~/.sbclrc}.)
447 The @code{asdf:*central-registry*} is empty by default in ASDF 2,
448 but is still supported for compatibility with ASDF 1.
449 When used, it takes precedence over the above source-registry@footnote{
450 It is possible to further customize
451 the system definition file search.
452 That's considered advanced use, and covered later:
454 @code{*system-definition-search-functions*}.
455 @xref{Defining systems with defsystem}.}.
457 For instance, if you wanted ASDF to find the @file{.asd} file
458 @file{/home/me/src/foo/foo.asd} your initialization script
459 could after it loads ASDF with @code{(require "asdf")}
463 (push "/home/me/src/foo/" asdf:*central-registry*)
466 Note the trailing slash: when searching for a system,
467 ASDF will evaluate each entry of the central registry
468 and coerce the result to a pathname@footnote{
469 ASDF will indeed call @code{EVAL} on each entry.
470 It will also skip entries that evaluate to @code{NIL}.
472 Strings and pathname objects are self-evaluating,
473 in which case the @code{EVAL} step does nothing;
474 but you may push arbitrary SEXP onto the central registry,
475 that will be evaluated to compute e.g. things that depend
476 on the value of shell variables or the identity of the user.
478 The variable @code{asdf:*central-registry*} is thus a list of
479 ``system directory designators''.
480 A @dfn{system directory designator} is a form
481 which will be evaluated whenever a system is to be found,
482 and must evaluate to a directory to look in.
483 By ``directory'' here, we mean
484 ``designator for a pathname with a supplied DIRECTORY component''.
486 at which point the presence of the trailing directory name separator
487 is necessary to tell Lisp that you're discussing a directory
490 Typically, however, there are a lot of @file{.asd} files, and
491 a common idiom was to have to put
492 a bunch of @emph{symbolic links} to @file{.asd} files
493 in a common directory
494 and push @emph{that} directory (the ``link farm'')
496 @code{asdf:*central-registry*}
497 instead of pushing each of the many involved directories
498 to the @code{asdf:*central-registry*}.
499 ASDF knows how to follow such @emph{symlinks}
500 to the actual file location when resolving the paths of system components
501 (on Windows, you can use Windows shortcuts instead of POSIX symlinks;
502 if you try aliases under MacOS, we are curious to hear about your experience).
504 For example, if @code{#p"/home/me/cl/systems/"} (note the trailing slash)
505 is a member of @code{*central-registry*}, you could set up the
506 system @var{foo} for loading with asdf with the following
507 commands at the shell:
510 $ cd /home/me/cl/systems/
511 $ ln -s ~/src/foo/foo.asd .
514 This old style for configuring ASDF is not recommended for new users,
515 but it is supported for old users, and for users who want to programmatically
516 control what directories are added to the ASDF search path.
519 @section Configuring where ASDF stores object files
520 @findex clear-output-translations
522 ASDF lets you configure where object files will be stored.
523 Sensible defaults are provided and
524 you shouldn't normally have to worry about it.
526 This allows the same source code repository may be shared
527 between several versions of several Common Lisp implementations,
528 between several users using different compilation options
529 and without write privileges on shared source directories, etc.
530 This also allows to keep source directories uncluttered
531 by plenty of object files.
533 Starting with ASDF 2, the @code{asdf-output-translations} facility
534 was added to ASDF itself, that controls where object files will be stored.
535 This facility is fully described in a chapter of this manual,
536 @ref{Controlling where ASDF saves compiled files}.
538 The simplest way to add a translation to your search path,
539 say from @file{/foo/bar/baz/quux/}
540 to @file{/where/i/want/my/fasls/}
541 is to create the directory
542 @file{~/.config/common-lisp/asdf-output-translations.conf.d/}
543 and there create a file with any name of your choice and the type @file{conf},
544 for instance @file{42-bazquux.conf}
547 @kbd{("/foo/bar/baz/quux/" "/where/i/want/my/fasls/")}
549 To disable output translations for source under a given directory,
550 say @file{/toto/tata/}
551 you can create a file @file{40-disable-toto.conf}
554 @kbd{("/toto/tata/")}
556 To wholly disable output translations for all directories,
557 you can create a file @file{00-disable.conf}
562 Note that your Operating System distribution or your system administrator
563 may already have configured translations for you.
564 In absence of any configuration, the default is to redirect everything
565 under an implementation-dependent subdirectory of @file{~/.cache/common-lisp/}.
566 @xref{Controlling where ASDF searches for systems}, for full details.
568 The required @file{.conf} extension allows you to have disabled files
569 or editor backups (ending in @file{~}), and works portably
570 (for instance, it is a pain to allow both empty and non-empty extension on CLISP).
571 Excluded are files the name of which start with a @file{.} character.
572 It is customary to start the filename with two digits
573 that specify the order in which the directories will be scanned.
575 ASDF will automatically read your configuration
576 the first time you try to find a system.
577 You can reset the source-registry configuration with:
580 (asdf:clear-output-translations)
583 And you probably should do so before you dump your Lisp image,
584 if the configuration may change
585 between the machine where you save it at the time you save it
586 and the machine you resume it at the time you resume it.
588 Finally note that before ASDF 2,
589 other ASDF add-ons offered the same functionality,
590 each in subtly different and incompatible ways:
591 ASDF-Binary-Locations, cl-launch, common-lisp-controller.
592 ASDF-Binary-Locations is now not needed anymore and should not be used.
593 cl-launch 3.000 and common-lisp-controller 7.2 have been updated
594 to just delegate this functionality to ASDF.
596 @node Using ASDF, Defining systems with defsystem, Configuring ASDF, Top
597 @comment node-name, next, previous, up
600 @section Resetting Configuration
602 When you dump and restore an image, or when you tweak your configuration,
603 you may want to reset the ASDF configuration.
604 For that you may use the following function:
606 @defun clear-configuration
607 undoes any ASDF configuration,
608 regarding source-registry or output-translations.
611 If you use SBCL, CMUCL or SCL, you may use this snippet
612 so that the ASDF configuration be cleared automatically as you dump an image:
616 (pushnew 'clear-configuration
617 #+(or cmu scl) ext:*before-save-initializations*
618 #+sbcl sb-ext:*save-hooks*)
621 For compatibility with all Lisp implementations, however,
622 you might want instead your build script to explicitly call
623 @code{(asdf:clear-configuration)} at an appropriate moment before dumping.
628 @section Loading a system
630 The system @var{foo} is loaded (and compiled, if necessary)
631 by evaluating the following Lisp form:
634 (asdf:load-system :@var{foo})
637 On some implementations (namely recent versions of
638 ABCL, Clozure CL, CLISP, CMUCL, ECL, SBCL and SCL),
639 ASDF hooks into the @code{CL:REQUIRE} facility
640 and you can just use:
646 In older versions of ASDF, you needed to use
647 @code{(asdf:oos 'asdf:load-op :@var{foo})}.
648 If your ASDF is too old to provide @code{asdf:load-system} though
649 we recommend that you upgrade to ASDF 2.
650 @xref{Loading ASDF,,Loading an otherwise installed ASDF}.
652 Note the name of a system is specified as a string or a symbol,
654 If a symbol (including a keyword), its name is taken and lowercased.
655 The name must be a suitable value for the @code{:name} initarg
656 to @code{make-pathname} in whatever filesystem the system is to be found.
657 The lower-casing-symbols behaviour is unconventional,
658 but was selected after some consideration.
659 Observations suggest that the type of systems we want to support
660 either have lowercase as customary case (unix, mac, windows)
661 or silently convert lowercase to uppercase (lpns),
662 so this makes more sense than attempting to use @code{:case :common},
663 which is reported not to work on some implementations
666 @section Other Operations
668 ASDF provides three commands for the most common system operations:
669 @code{load-system}, @code{compile-system} or @code{test-system}.
671 Because ASDF is an extensible system
672 for defining @emph{operations} on @emph{components},
673 it also provides a generic function @code{operate}
674 (which is usually abbreviated by @code{oos}).
675 You'll use @code{oos} whenever you want to do something beyond
676 compiling, loading and testing.
678 Output from ASDF and ASDF extensions are supposed to be sent
679 to the CL stream @code{*standard-output*},
680 and so rebinding that stream around calls to @code{asdf:operate}
681 should redirect all output from ASDF operations.
683 Reminder: before ASDF can operate on a system, however,
684 it must be able to find and load that system's definition.
685 @xref{Configuring ASDF,,Configuring ASDF to find your systems}.
694 Load ASDF itself into your Lisp image, either through
695 @code{(require "asdf")} or else through
696 @code{(load "/path/to/asdf.lisp")}.
699 Make sure ASDF can find system definitions
700 thanks to proper source-registry configuration.
703 Load a system with @code{(load-system :my-system)}
704 or use some other operation on some system of your choice.
710 That's all you need to know to use ASDF to load systems written by others.
711 The rest of this manual deals with writing system definitions
712 for Common Lisp software you write yourself,
713 including how to extend ASDF to define new operation and component types.
716 @node Defining systems with defsystem, The object model of ASDF, Using ASDF, Top
717 @comment node-name, next, previous, up
718 @chapter Defining systems with defsystem
720 This chapter describes how to use asdf to define systems and develop
725 * The defsystem form::
726 * A more involved example::
727 * The defsystem grammar::
728 * Other code in .asd files::
731 @node The defsystem form, A more involved example, Defining systems with defsystem, Defining systems with defsystem
732 @comment node-name, next, previous, up
733 @section The defsystem form
735 Systems can be constructed programmatically
736 by instantiating components using @code{make-instance}.
737 Most of the time, however, it is much more practical to use
738 a static @code{defsystem} form.
739 This section begins with an example of a system definition,
740 then gives the full grammar of @code{defsystem}.
742 Let's look at a simple system.
743 This is a complete file that would
744 usually be saved as @file{hello-lisp.asd}:
749 (defsystem "hello-lisp"
750 :description "hello-lisp: a sample Lisp system."
752 :author "Joe User <joe@@example.com>"
753 :licence "Public Domain"
754 :components ((:file "packages")
755 (:file "macros" :depends-on ("packages"))
756 (:file "hello" :depends-on ("macros"))))
759 Some notes about this example:
764 The file starts with an @code{in-package} form
765 to use package @code{asdf}.
766 You could instead start your definition by using
767 a qualified name @code{asdf:defsystem}.
770 If in addition to simply using @code{defsystem},
771 you are going to define functions,
772 create ASDF extension, globally bind symbols, etc.,
773 it is recommended that to avoid namespace pollution between systems,
774 you should create your own package for that purpose,
775 for instance replacing the above @code{(in-package :asdf)} with:
778 (defpackage :foo-system
781 (in-package :foo-system)
785 The @code{defsystem} form defines a system named @code{hello-lisp}
786 that contains three source files:
787 @file{packages}, @file{macros} and @file{hello}.
790 The file @file{macros} depends on @file{packages}
791 (presumably because the package it's in is defined in @file{packages}),
792 and the file @file{hello} depends on @file{macros}
793 (and hence, transitively on @file{packages}).
794 This means that ASDF will compile and load @file{packages} and @file{macros}
795 before starting the compilation of file @file{hello}.
798 The files are located in the same directory
799 as the file with the system definition.
800 ASDF resolves symbolic links (or Windows shortcuts)
801 before loading the system definition file and
802 stores its location in the resulting system@footnote{
803 It is possible, though almost never necessary, to override this behaviour.}.
804 This is a good thing because the user can move the system sources
805 without having to edit the system definition.
807 @c FIXME: Should have cross-reference to "Version specifiers" in the
808 @c defsystem grammar, but the cross-referencing is so broken by
809 @c insufficient node breakdown that I have not put one in.
811 Make sure you know how the @code{:version} numbers will be parsed! They
812 are parsed as period-separated lists of integers. I.e., in the example,
813 @code{0.2.1} is to be interpreted, roughly speaking, as @code{(0 2 1)}.
814 In particular, version @code{0.2.1} is interpreted the same as
815 @code{0.0002.1} and is strictly version-less-than version @code{0.20.1},
816 even though the two are the same when interpreted as decimal fractions.
817 @cindex version specifiers
822 @node A more involved example, The defsystem grammar, The defsystem form, Defining systems with defsystem
823 @comment node-name, next, previous, up
824 @section A more involved example
826 Let's illustrate some more involved uses of @code{defsystem} via a
827 slightly convoluted example:
832 :components ((:module "mod"
833 :components ((:file "bar")
836 :perform (compile-op :after (op c)
838 :explain (compile-op :after (op c)
839 (explain-something c)))
843 The @code{:module} component named @code{"mod"} is a collection of three files,
844 which will be located in a subdirectory of the main code directory named
845 @file{mod} (this location can be overridden; see the discussion of the
846 @code{:pathname} option in @ref{The defsystem grammar}).
848 The method-form tokens provide a shorthand for defining methods on
849 particular components. This part
852 :perform (compile-op :after (op c)
854 :explain (compile-op :after (op c)
855 (explain-something c))
861 (defmethod perform :after ((op compile-op) (c (eql ...)))
863 (defmethod explain :after ((op compile-op) (c (eql ...)))
864 (explain-something c))
867 where @code{...} is the component in question.
868 In this case @code{...} would expand to something like
871 (find-component (find-system "foo") "mod")
874 For more details on the syntax of such forms, see @ref{The defsystem
876 For more details on what these methods do, @pxref{Operations} in
877 @ref{The object model of ASDF}.
879 @c The following plunge into the weeds is not appropriate in this
880 @c location. [2010/10/03:rpg]
881 @c note that although this also supports @code{:before} methods,
882 @c they may not do what you want them to ---
883 @c a @code{:before} method on perform @code{((op compile-op) (c (eql ...)))}
884 @c will run after all the dependencies and sub-components have been processed,
885 @c but before the component in question has been compiled.
887 @node The defsystem grammar, Other code in .asd files, A more involved example, Defining systems with defsystem
888 @comment node-name, next, previous, up
889 @section The defsystem grammar
891 @c FIXME: @var typesetting not consistently used here. We should either expand
892 @c its use to everywhere, or we should kill it everywhere.
896 system-definition := ( defsystem system-designator @var{system-option}* )
898 system-option := :defsystem-depends-on system-list
899 | :class class-name (see discussion below)
903 module-option := :components component-list
904 | :serial [ t | nil ]
905 | :if-component-dep-fails component-dep-fail-option
908 | :pathname pathname-specifier
909 | :default-component-class class-name
910 | :perform method-form
911 | :explain method-form
912 | :output-files method-form
913 | :operation-done-p method-form
914 | :depends-on ( @var{dependency-def}* )
915 | :in-order-to ( @var{dependency}+ )
918 system-list := ( @var{simple-component-name}* )
920 component-list := ( @var{component-def}* )
922 component-def := ( component-type simple-component-name @var{option}* )
924 component-type := :system | :module | :file | :static-file | other-component-type
926 other-component-type := symbol-by-name (@pxref{The defsystem grammar,,Component types})
928 dependency-def := simple-component-name
930 | ( :version simple-component-name version-specifier)
932 dependency := (dependent-op @var{requirement}+)
933 requirement := (required-op @var{required-component}+)
934 | (feature feature-name)
935 dependent-op := operation-name
936 required-op := operation-name | feature
938 simple-component-name := string
941 pathname-specifier := pathname | string | symbol
943 method-form := (operation-name qual lambda-list @&rest body)
944 qual := method qualifier
946 component-dep-fail-option := :fail | :try-next | :ignore
950 @subsection Component names
952 Component names (@code{simple-component-name})
953 may be either strings or symbols.
955 @subsection Component types
957 Component type names, even if expressed as keywords, will be looked up
958 by name in the current package and in the asdf package, if not found in
959 the current package. So a component type @code{my-component-type}, in
960 the current package @code{my-system-asd} can be specified as
961 @code{:my-component-type}, or @code{my-component-type}.
963 @subsection System class names
965 A system class name will be looked up in the same way as a Component
966 type (see above). Typically, one will not need to specify a system
967 class name, unless using a non-standard system class defined in some
968 ASDF extension, typically loaded through @code{DEFSYSTEM-DEPENDS-ON},
969 see below. For such class names in the ASDF package, we recommend that
970 the @code{:class} option be specified using a keyword symbol, such as
973 :class :MY-NEW-SYSTEM-SUBCLASS
976 This practice will ensure that package name conflicts are avoided.
977 Otherwise, the symbol @code{MY-NEW-SYSTEM-SUBCLASS} will be read into
978 the current package @emph{before} it has been exported from the ASDF
979 extension loaded by @code{:defsystem-depends-on}, causing a name
980 conflict in the current package.
982 @subsection Defsystem depends on
984 The @code{:defsystem-depends-on} option to @code{defsystem} allows the
985 programmer to specify another ASDF-defined system or set of systems that
986 must be loaded @emph{before} the system definition is processed.
987 Typically this is used to load an ASDF extension that is used in the
990 @subsection Pathname specifiers
991 @cindex pathname specifiers
993 A pathname specifier (@code{pathname-specifier})
994 may be a pathname, a string or a symbol.
995 When no pathname specifier is given for a component,
996 which is the usual case, the component name itself is used.
998 If a string is given, which is the usual case,
999 the string will be interpreted as a Unix-style pathname
1000 where @code{/} characters will be interpreted as directory separators.
1001 Usually, Unix-style relative pathnames are used
1002 (i.e. not starting with @code{/}, as opposed to absolute pathnames);
1003 they are relative to the path of the parent component.
1004 Finally, depending on the @code{component-type},
1005 the pathname may be interpreted as either a file or a directory,
1007 a file type may be added corresponding to the @code{component-type},
1008 or else it will be extracted from the string itself (if applicable).
1010 For instance, the @code{component-type} @code{:module}
1011 wants a directory pathname, and so a string @code{"foo/bar"}
1012 will be interpreted as the pathname @file{#p"foo/bar/"}.
1013 On the other hand, the @code{component-type} @code{:file}
1014 wants a file of type @code{lisp}, and so a string @code{"foo/bar"}
1015 will be interpreted as the pathname @file{#p"foo/bar.lisp"},
1016 and a string @code{"foo/bar.quux"}
1017 will be interpreted as the pathname @file{#p"foo/bar.quux.lisp"}.
1018 Finally, the @code{component-type} @code{:static-file}
1019 wants a file without specifying a type, and so a string @code{"foo/bar"}
1020 will be interpreted as the pathname @file{#p"foo/bar"},
1021 and a string @code{"foo/bar.quux"}
1022 will be interpreted as the pathname @file{#p"foo/bar.quux"}.
1024 ASDF does not interpret the string @code{".."} to designate the parent
1025 directory. This string will be passed through to the underlying
1026 operating system for interpretation. We @emph{believe} that this will
1027 work on all platforms where ASDF is deployed, but do not guarantee this
1028 behavior. A pathname object with a relative directory component of
1029 @code{:up} or @code{:back} is the only guaranteed way to specify a
1032 If a symbol is given, it will be translated into a string,
1033 and downcased in the process.
1034 The downcasing of symbols is unconventional,
1035 but was selected after some consideration.
1036 Observations suggest that the type of systems we want to support
1037 either have lowercase as customary case (Unix, Mac, windows)
1038 or silently convert lowercase to uppercase (lpns),
1039 so this makes more sense than attempting to use @code{:case :common}
1040 as argument to @code{make-pathname},
1041 which is reported not to work on some implementations.
1043 Pathname objects may be given to override the path for a component.
1044 Such objects are typically specified using reader macros such as @code{#p}
1045 or @code{#.(make-pathname ...)}.
1046 Note however, that @code{#p...} is a shorthand for @code{#.(parse-namestring ...)}
1047 and that the behavior of @code{parse-namestring} is completely non-portable,
1048 unless you are using Common Lisp @code{logical-pathname}s
1049 (@pxref{The defsystem grammar,,Using logical pathnames}, below).
1050 Pathnames made with @code{#.(make-pathname ...)}
1051 can usually be done more easily with the string syntax above.
1052 The only case that you really need a pathname object is to override
1053 the component-type default file type for a given component.
1054 Therefore, pathname objects should only rarely be used.
1055 Unhappily, ASDF 1 didn't properly support
1056 parsing component names as strings specifying paths with directories,
1057 and the cumbersome @code{#.(make-pathname ...)} syntax had to be used.
1059 Note that when specifying pathname objects,
1060 ASDF does not do any special interpretation of the pathname
1061 influenced by the component type, unlike the procedure for
1062 pathname-specifying strings.
1063 On the one hand, you have to be careful to provide a pathname that correctly
1064 fulfills whatever constraints are required from that component type
1065 (e.g. naming a directory or a file with appropriate type);
1066 on the other hand, you can circumvent the file type that would otherwise
1067 be forced upon you if you were specifying a string.
1069 @subsection Version specifiers
1070 @cindex version specifiers
1073 Version specifiers are parsed as period-separated lists of integers. I.e., in the example,
1074 @code{0.2.1} is to be interpreted, roughly speaking, as @code{(0 2 1)}.
1075 In particular, version @code{0.2.1} is interpreted the same as
1076 @code{0.0002.1} and is strictly version-less-than version @code{0.20.1},
1077 even though the two are the same when interpreted as decimal fractions.
1079 System definers are encouraged to use version identifiers of the form
1080 @var{x}.@var{y}.@var{z} for major version, minor version (compatible
1081 API) and patch level.
1083 @xref{Common attributes of components}.
1086 @subsection Using logical pathnames
1087 @cindex logical pathnames
1089 We do not generally recommend the use of logical pathnames,
1090 especially not so to newcomers to Common Lisp.
1091 However, we do support the use of logical pathnames by old timers,
1092 when such is their preference.
1094 To use logical pathnames,
1095 you will have to provide a pathname object as a @code{:pathname} specifier
1096 to components that use it, using such syntax as
1097 @code{#p"LOGICAL-HOST:absolute;path;to;component.lisp"}.
1099 You only have to specify such logical pathname
1100 for your system or some top-level component.
1101 Sub-components' relative pathnames,
1102 specified using the string syntax for names,
1103 will be properly merged with the pathnames of their parents.
1104 The specification of a logical pathname host however is @emph{not}
1105 otherwise directly supported in the ASDF syntax
1106 for pathname specifiers as strings.
1108 The @code{asdf-output-translation} layer will
1109 avoid trying to resolve and translate logical pathnames.
1110 The advantage of this is that
1111 you can define yourself what translations you want to use
1112 with the logical pathname facility.
1113 The disadvantage is that if you do not define such translations,
1114 any system that uses logical pathnames will behave differently under
1115 asdf-output-translations than other systems you use.
1117 If you wish to use logical pathnames you will have to configure the
1118 translations yourself before they may be used.
1119 ASDF currently provides no specific support
1120 for defining logical pathname translations.
1122 Note that the reasons we do not recommend logical pathnames are that
1123 (1) there is no portable way to set up logical pathnames before they are used,
1124 (2) logical pathnames are limited to only portably use
1125 a single character case, digits and hyphens.
1126 While you can solve the first issue on your own,
1127 describing how to do it on each of fifteen implementations supported by ASDF
1128 is more than we can document.
1129 As for the second issue, mind that the limitation is notably enforced on SBCL,
1130 and that you therefore can't portably violate the limitations
1131 but must instead define some encoding of your own and add individual mappings
1132 to name physical pathnames that do not fit the restrictions.
1133 This can notably be a problem when your Lisp files are part of a larger project
1134 in which it is common to name files or directories in a way that
1135 includes the version numbers of supported protocols,
1136 or in which files are shared with software written
1137 in different programming languages where conventions include the use of
1138 underscores, dots or CamelCase in pathnames.
1141 @subsection Serial dependencies
1142 @cindex serial dependencies
1144 If the @code{:serial t} option is specified for a module,
1145 ASDF will add dependencies for each child component,
1146 on all the children textually preceding it.
1147 This is done as if by @code{:depends-on}.
1151 :components ((:file "a") (:file "b") (:file "c"))
1157 :components ((:file "a")
1158 (:file "b" :depends-on ("a"))
1159 (:file "c" :depends-on ("a" "b")))
1163 @subsection Source location
1165 The @code{:pathname} option is optional in all cases for systems
1166 defined via @code{defsystem},
1167 and in the usual case the user is recommended not to supply it.
1169 Instead, ASDF follows a hairy set of rules that are designed so that
1173 will load a system from disk
1174 and have its pathname default to the right place.
1176 This pathname information will not be overwritten with
1177 @code{*default-pathname-defaults*}
1178 (which could be somewhere else altogether)
1179 if the user loads up the @file{.asd} file into his editor
1180 and interactively re-evaluates that form.
1183 If a system is being loaded for the first time,
1184 its top-level pathname will be set to:
1188 The host/device/directory parts of @code{*load-truename*},
1191 @code{*default-pathname-defaults*}, otherwise.
1194 If a system is being redefined, the top-level pathname will be
1198 changed, if explicitly supplied or obtained from @code{*load-truename*}
1199 (so that an updated source location is reflected in the system definition)
1201 changed if it had previously been set from @code{*default-pathname-defaults*}
1203 left as before, if it had previously been set from @code{*load-truename*}
1204 and @code{*load-truename*} is currently unbound
1205 (so that a developer can evaluate a @code{defsystem} form
1206 from within an editor without clobbering its source location)
1209 @subsection if-component-dep-fails option
1211 This option is only appropriate for module components (including
1212 systems), not individual source files.
1214 For more information about this option, @pxref{Pre-defined subclasses of component}.
1216 @node Other code in .asd files, , The defsystem grammar, Defining systems with defsystem
1217 @section Other code in .asd files
1219 Files containing @code{defsystem} forms
1220 are regular Lisp files that are executed by @code{load}.
1221 Consequently, you can put whatever Lisp code you like into these files
1222 (e.g., code that examines the compile-time environment
1223 and adds appropriate features to @code{*features*}).
1224 However, some conventions should be followed,
1225 so that users can control certain details of execution
1226 of the Lisp in @file{.asd} files:
1230 Any informative output
1231 (other than warnings and errors,
1232 which are the condition system's to dispose of)
1233 should be sent to the standard CL stream @code{*standard-output*},
1234 so that users can easily control the disposition
1235 of output from ASDF operations.
1239 @node The object model of ASDF, Controlling where ASDF searches for systems, Defining systems with defsystem, Top
1240 @comment node-name, next, previous, up
1241 @chapter The object model of ASDF
1243 ASDF is designed in an object-oriented way from the ground up.
1244 Both a system's structure and the operations that can be performed on systems
1246 ASDF is extensible to new operations and to new component types.
1247 This allows the addition of behaviours:
1248 for example, a new component could be added for Java JAR archives,
1249 and methods specialised on @code{compile-op} added for it
1250 that would accomplish the relevant actions.
1252 This chapter deals with @emph{components}, the building blocks of a system,
1253 and @emph{operations}, the actions that can be performed on a system.
1263 @node Operations, Components, The object model of ASDF, The object model of ASDF
1264 @comment node-name, next, previous, up
1268 An @dfn{operation} object of the appropriate type is instantiated
1269 whenever the user wants to do something with a system like
1272 @item compile all its files
1273 @item load the files into a running lisp environment
1274 @item copy its source files somewhere else
1277 Operations can be invoked directly, or examined
1278 to see what their effects would be without performing them.
1279 @emph{FIXME: document how!}
1280 There are a bunch of methods specialised on operation and component type
1281 that actually do the grunt work.
1283 The operation object contains whatever state is relevant for this purpose
1284 (perhaps a list of visited nodes, for example)
1285 but primarily is a nice thing to specialise operation methods on
1286 and easier than having them all be @code{EQL} methods.
1288 Operations are invoked on systems via @code{operate}.
1290 @deffn {Generic function} @code{operate} @var{operation} @var{system} @&rest @var{initargs}
1291 @deffnx {Generic function} @code{oos} @var{operation} @var{system} @&rest @var{initargs}
1292 @code{operate} invokes @var{operation} on @var{system}.
1293 @code{oos} is a synonym for @code{operate}.
1295 @var{operation} is a symbol that is passed, along with the supplied
1296 @var{initargs}, to @code{make-instance} to create the operation object.
1297 @var{system} is a system designator.
1299 The @var{initargs} are passed to the @code{make-instance} call
1300 when creating the operation object.
1301 Note that dependencies may cause the operation
1302 to invoke other operations on the system or its components:
1303 the new operations will be created
1304 with the same @var{initargs} as the original one.
1309 * Predefined operations of ASDF::
1310 * Creating new operations::
1313 @node Predefined operations of ASDF, Creating new operations, Operations, Operations
1314 @comment node-name, next, previous, up
1315 @subsection Predefined operations of ASDF
1317 All the operations described in this section are in the @code{asdf} package.
1318 They are invoked via the @code{operate} generic function.
1321 (asdf:operate 'asdf:@var{operation-name} :@var{system-name} @{@var{operation-options ...}@})
1324 @deffn Operation @code{compile-op} @&key @code{proclamations}
1326 This operation compiles the specified component.
1327 If proclamations are supplied, they will be proclaimed.
1328 This is a good place to specify optimization settings.
1330 When creating a new component type,
1331 you should provide methods for @code{compile-op}.
1333 When @code{compile-op} is invoked,
1334 component dependencies often cause some parts of the system
1335 to be loaded as well as compiled.
1336 Invoking @code{compile-op}
1337 does not necessarily load all the parts of the system, though;
1338 use @code{load-op} to load a system.
1341 @deffn Operation @code{load-op} @&key @code{proclamations}
1343 This operation loads a system.
1345 The default methods for @code{load-op} compile files before loading them.
1346 For parity, your own methods on new component types should probably do so too.
1349 @deffn Operation @code{load-source-op}
1351 This operation will load the source for the files in a module
1352 even if the source files have been compiled.
1353 Systems sometimes have knotty dependencies
1354 which require that sources are loaded
1355 before they can be compiled.
1356 This is how you do that.
1358 If you are creating a component type,
1359 you need to implement this operation --- at least, where meaningful.
1363 @deffn Operation @code{test-op}
1365 This operation will perform some tests on the module.
1366 The default method will do nothing.
1367 The default dependency is to require
1368 @code{load-op} to be performed on the module first.
1369 The default @code{operation-done-p} is that the operation is @emph{never} done
1371 we assume that if you invoke the @code{test-op},
1372 you want to test the system, even if you have already done so.
1374 The results of this operation are not defined by ASDF.
1375 It has proven difficult to define how the test operation
1376 should signal its results to the user
1377 in a way that is compatible with all of the various test libraries
1378 and test techniques in use in the community.
1381 @c @deffn Operation test-system-version @&key minimum
1383 @c Asks the system whether it satisfies a version requirement.
1385 @c The default method accepts a string, which is expected to contain of a
1386 @c number of integers separated by #\. characters. The method is not
1387 @c recursive. The component satisfies the version dependency if it has
1388 @c the same major number as required and each of its sub-versions is
1389 @c greater than or equal to the sub-version number required.
1392 @c (defun version-satisfies (x y)
1393 @c (labels ((bigger (x y)
1394 @c (cond ((not y) t)
1396 @c ((> (car x) (car y)) t)
1397 @c ((= (car x) (car y))
1398 @c (bigger (cdr x) (cdr y))))))
1399 @c (and (= (car x) (car y))
1400 @c (or (not (cdr y)) (bigger (cdr x) (cdr y))))))
1403 @c If that doesn't work for your system, you can override it. I hope
1404 @c you have as much fun writing the new method as @verb{|#lisp|} did
1405 @c reimplementing this one.
1408 @c @deffn Operation feature-dependent-op
1410 @c An instance of @code{feature-dependent-op} will ignore any components
1411 @c which have a @code{features} attribute, unless the feature combination
1412 @c it designates is satisfied by @code{*features*}. This operation is
1413 @c not intended to be instantiated directly, but other operations may
1418 @node Creating new operations, , Predefined operations of ASDF, Operations
1419 @comment node-name, next, previous, up
1420 @subsection Creating new operations
1422 ASDF was designed to be extensible in an object-oriented fashion.
1423 To teach ASDF new tricks, a programmer can implement the behaviour he wants
1424 by creating a subclass of @code{operation}.
1426 ASDF's pre-defined operations are in no way ``privileged'',
1427 but it is requested that developers never use the @code{asdf} package
1428 for operations they develop themselves.
1429 The rationale for this rule is that we don't want to establish a
1430 ``global asdf operation name registry'',
1431 but also want to avoid name clashes.
1433 An operation must provide methods for the following generic functions
1434 when invoked with an object of type @code{source-file}:
1435 @emph{FIXME describe this better}
1439 @item @code{output-files}
1440 The @code{output-files} method determines where the method will put its files.
1441 It returns two values, a list of pathnames, and a boolean.
1442 If the boolean is @code{T} then the pathnames are marked
1443 not be translated by enclosing @code{:around} methods.
1444 If the boolean is @code{NIL} then enclosing @code{:around} methods
1445 may translate these pathnames, e.g. to ensure object files
1446 are somehow stored in some implementation-dependent cache.
1447 @item @code{perform}
1448 The @code{perform} method must call @code{output-files}
1449 to find out where to put its files,
1450 because the user is allowed to override.
1451 @item @code{output-files}
1452 for local policy @code{explain}
1453 @item @code{operation-done-p},
1454 if you don't like the default one
1458 Operations that print output should send that output to the standard
1459 CL stream @code{*standard-output*}, as the Lisp compiler and loader do.
1461 @node Components, Functions, Operations, The object model of ASDF
1462 @comment node-name, next, previous, up
1466 @cindex system designator
1467 @vindex *system-definition-search-functions*
1469 A @dfn{component} represents a source file or
1470 (recursively) a collection of components.
1471 A @dfn{system} is (roughly speaking) a top-level component
1472 that can be found via @code{find-system}.
1474 A @dfn{system designator} is a string or symbol
1475 and behaves just like any other component name
1476 (including with regard to the case conversion rules for component names).
1479 @defun find-system system-designator &optional (error-p t)
1481 Given a system designator, @code{find-system} finds and returns a system.
1482 If no system is found, an error of type
1483 @code{missing-component} is thrown,
1484 or @code{nil} is returned if @code{error-p} is false.
1486 To find and update systems, @code{find-system} funcalls each element
1487 in the @code{*system-definition-search-functions*} list,
1488 expecting a pathname to be returned, or a system object,
1489 from which a pathname may be extracted, and that will be registered.
1490 The resulting pathname (if any) is loaded
1491 if one of the following conditions is true:
1495 there is no system of that name in memory
1497 the pathname is different from that which was previously loaded
1499 the file's @code{last-modified} time exceeds the @code{last-modified} time
1500 of the system in memory
1503 When system definitions are loaded from @file{.asd} files,
1504 a new scratch package is created for them to load into,
1505 so that different systems do not overwrite each others operations.
1506 The user may also wish to (and is recommended to)
1507 include @code{defpackage} and @code{in-package} forms
1508 in his system definition files, however,
1509 so that they can be loaded manually if need be.
1511 The default value of @code{*system-definition-search-functions*}
1512 is a list of two functions.
1513 The first function looks in each of the directories given
1514 by evaluating members of @code{*central-registry*}
1515 for a file whose name is the name of the system and whose type is @file{asd}.
1516 The first such file is returned,
1517 whether or not it turns out to actually define the appropriate system.
1518 The second function does something similar,
1519 for the directories specified in the @code{source-registry}.
1520 Hence, it is strongly advised to define a system
1521 @var{foo} in the corresponding file @var{foo.asd}.
1526 * Common attributes of components::
1527 * Pre-defined subclasses of component::
1528 * Creating new component types::
1531 @node Common attributes of components, Pre-defined subclasses of component, Components, Components
1532 @comment node-name, next, previous, up
1533 @subsection Common attributes of components
1535 All components, regardless of type, have the following attributes.
1536 All attributes except @code{name} are optional.
1540 A component name is a string or a symbol.
1541 If a symbol, its name is taken and lowercased.
1543 Unless overridden by a @code{:pathname} attribute,
1544 the name will be interpreted as a pathname specifier according
1545 to a Unix-style syntax.
1546 @xref{The defsystem grammar,,Pathname specifiers}.
1548 @subsubsection Version identifier
1549 @findex version-satisfies
1552 This optional attribute is used by the generic function
1553 @code{version-satisfies}, which tests to see if @code{:version}
1554 dependencies are satisfied.
1555 the version should be a string of integers separated by dots,
1556 for example @samp{1.0.11}.
1557 For more information on the semantics of version specifiers, see @ref{The defsystem grammar}.
1559 @c This optional attribute is intended to be used by the @code{test-system-version} operation.
1560 @c @xref{Predefined operations of ASDF}.
1561 @c @emph{Nota Bene}:
1562 @c This operation, planned for ASDF 1,
1563 @c is still not implemented yet as of ASDF 2.
1564 @c Don't hold your breath.
1568 @subsubsection Required features
1570 @emph{FIXME: This subsection seems to contradict the
1571 @code{defsystem} grammar subsection,
1572 which doesn't provide any obvious way to specify required features.
1573 Furthermore, in 2009, discussions on the
1574 @url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}
1575 suggested that the specification of required features may be broken,
1576 and that no one may have been using them for a while.
1578 @url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}
1579 if you are interested in getting this features feature fixed.}
1581 Traditionally defsystem users have used reader conditionals
1582 to include or exclude specific per-implementation files.
1583 This means that any single implementation cannot read the entire system,
1584 which becomes a problem if it doesn't wish to compile it,
1585 but instead for example to create an archive file containing all the sources,
1586 as it will omit to process the system-dependent sources for other systems.
1588 Each component in an asdf system may therefore specify features using
1589 the same syntax as @code{#+} does, and it will (somehow) be ignored for
1590 certain operations unless the feature conditional is a member of
1594 @subsubsection Dependencies
1596 This attribute specifies dependencies of the component on its siblings.
1597 It is optional but often necessary.
1599 There is an excitingly complicated relationship between the initarg
1600 and the method that you use to ask about dependencies
1602 Dependencies are between (operation component) pairs.
1603 In your initargs for the component, you can say
1606 :in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))
1607 (load-op (load-op "foo")))
1610 This means the following things:
1613 before performing compile-op on this component, we must perform
1614 load-op on @var{a} and @var{b}, and compile-op on @var{c},
1616 before performing @code{load-op}, we have to load @var{foo}
1619 The syntax is approximately
1622 (this-op {(other-op required-components)}+)
1624 simple-component-name := string
1627 required-components := simple-component-name
1628 | (required-components required-components)
1630 component-name := simple-component-name
1631 | (:version simple-component-name minimum-version-object)
1636 This is on a par with what ACL defsystem does.
1637 mk-defsystem is less general: it has an implied dependency
1640 for all x, (load x) depends on (compile x)
1643 and using a @code{:depends-on} argument to say that @var{b} depends on
1644 @var{a} @emph{actually} means that
1647 (compile b) depends on (load a)
1650 This is insufficient for e.g. the McCLIM system, which requires that
1651 all the files are loaded before any of them can be compiled ]
1655 In ASDF, the dependency information for a given component and operation
1656 can be queried using @code{(component-depends-on operation component)},
1657 which returns a list
1660 ((load-op "a") (load-op "b") (compile-op "c") ...)
1663 @code{component-depends-on} can be subclassed for more specific
1664 component/operation types: these need to @code{(call-next-method)}
1665 and append the answer to their dependency, unless
1666 they have a good reason for completely overriding the default dependencies.
1668 If it weren't for CLISP, we'd be using @code{LIST} method
1669 combination to do this transparently.
1670 But, we need to support CLISP.
1671 If you have the time for some CLISP hacking,
1672 I'm sure they'd welcome your fixes.
1673 @c Doesn't CLISP now support LIST method combination?
1675 See the discussion of the semantics of @code{:version} in the defsystem
1678 @c FIXME: Should have cross-reference to "Version specifiers" in the
1679 @c defsystem grammar, but the cross-referencing is so broken by
1680 @c insufficient node breakdown that I have not put one in.
1683 @subsubsection pathname
1685 This attribute is optional and if absent (which is the usual case),
1686 the component name will be used.
1688 @xref{The defsystem grammar,,Pathname specifiers},
1689 for an explanation of how this attribute is interpreted.
1691 Note that the @code{defsystem} macro (used to create a ``top-level'' system)
1692 does additional processing to set the filesystem location of
1693 the top component in that system.
1694 This is detailed elsewhere. @xref{Defining systems with defsystem}.
1697 @subsubsection properties
1699 This attribute is optional.
1701 Packaging systems often require information about files or systems
1702 in addition to that specified by ASDF's pre-defined component attributes.
1703 Programs that create vendor packages out of ASDF systems therefore
1704 have to create ``placeholder'' information to satisfy these systems.
1705 Sometimes the creator of an ASDF system may know the additional
1706 information and wish to provide it directly.
1708 @code{(component-property component property-name)} and
1709 associated @code{setf} method will allow
1710 the programmatic update of this information.
1711 Property names are compared as if by @code{EQL},
1712 so use symbols or keywords or something.
1715 * Pre-defined subclasses of component::
1716 * Creating new component types::
1719 @node Pre-defined subclasses of component, Creating new component types, Common attributes of components, Components
1720 @comment node-name, next, previous, up
1721 @subsection Pre-defined subclasses of component
1723 @deffn Component source-file
1725 A source file is any file that the system does not know how to
1726 generate from other components of the system.
1728 Note that this is not necessarily the same thing as
1729 ``a file containing data that is typically fed to a compiler''.
1730 If a file is generated by some pre-processor stage
1731 (e.g. a @file{.h} file from @file{.h.in} by autoconf)
1732 then it is not, by this definition, a source file.
1733 Conversely, we might have a graphic file
1734 that cannot be automatically regenerated,
1735 or a proprietary shared library that we received as a binary:
1736 these do count as source files for our purposes.
1738 Subclasses of source-file exist for various languages.
1739 @emph{FIXME: describe these.}
1742 @deffn Component module
1744 A module is a collection of sub-components.
1746 A module component has the following extra initargs:
1750 @code{:components} the components contained in this module
1753 @code{:default-component-class}
1754 All children components which don't specify their class explicitly
1755 are inferred to be of this type.
1758 @code{:if-component-dep-fails}
1759 This attribute takes one of the values
1760 @code{:fail}, @code{:try-next}, @code{:ignore},
1761 its default value is @code{:fail}.
1762 The other values can be used for implementing conditional compilation
1763 based on implementation @code{*features*},
1764 for the case where it is not necessary for all files in a module to be
1766 @emph{FIXME: such conditional compilation has been reported
1767 to be broken in 2009.}
1770 @code{:serial} When this attribute is set,
1771 each subcomponent of this component is assumed to depend on all subcomponents
1772 before it in the list given to @code{:components}, i.e.
1773 all of them are loaded before a compile or load operation is performed on it.
1777 The default operation knows how to traverse a module, so
1778 most operations will not need to provide methods specialised on modules.
1780 @code{module} may be subclassed to represent components such as
1781 foreign-language linked libraries or archive files.
1784 @deffn Component system
1786 @code{system} is a subclass of @code{module}.
1788 A system is a module with a few extra attributes for documentation
1789 purposes; these are given elsewhere.
1790 @xref{The defsystem grammar}.
1792 Users can create new classes for their systems:
1793 the default @code{defsystem} macro takes a @code{:class} keyword argument.
1796 @node Creating new component types, , Pre-defined subclasses of component, Components
1797 @comment node-name, next, previous, up
1798 @subsection Creating new component types
1800 New component types are defined by subclassing one of the existing
1801 component classes and specializing methods on the new component class.
1803 @emph{FIXME: this should perhaps be explained more throughly,
1804 not only by example ...}
1806 As an example, suppose we have some implementation-dependent
1807 functionality that we want to isolate
1808 in one subdirectory per Lisp implementation our system supports.
1809 We create a subclass of
1810 @code{cl-source-file}:
1813 (defclass unportable-cl-source-file (cl-source-file)
1817 Function @code{asdf:implementation-type} (exported since 2.014.14)
1818 gives us the name of the subdirectory.
1819 All that's left is to define how to calculate the pathname
1820 of an @code{unportable-cl-source-file}.
1823 (defmethod component-pathname ((component unportable-cl-source-file))
1825 (coerce-pathname (format nil "~(~A~)/" (asdf:implementation-type)))
1826 (call-next-method)))
1829 The new component type is used in a @code{defsystem} form in this way:
1836 (:unportable-cl-source-file "threads"
1837 :depends-on ("packages" ...))
1842 @node Functions, , Components, The object model of ASDF
1843 @comment node-name, next, previous, up
1845 @findex version-satisfies
1847 @deffn version-satisfies @var{version} @var{version-spec}
1848 Does @var{version} satisfy the @var{version-spec}. A generic function.
1849 ASDF provides built-in methods for @var{version} being a
1850 @code{component} or @code{string}. @var{version-spec} should be a
1853 In the wild, we typically see version numbering only on components of
1856 For more information about how @code{version-satisfies} interprets
1857 version strings and specifications, @pxref{The defsystem grammar} and
1858 @ref{Common attributes of components}.
1861 @node Controlling where ASDF searches for systems, Controlling where ASDF saves compiled files, The object model of ASDF, Top
1862 @comment node-name, next, previous, up
1863 @chapter Controlling where ASDF searches for systems
1865 @section Configurations
1867 Configurations specify paths where to find system files.
1872 The search registry may use some hardcoded wrapping registry specification.
1873 This allows some implementations (notably SBCL) to specify where to find
1874 some special implementation-provided systems that
1875 need to precisely match the version of the implementation itself.
1878 An application may explicitly initialize the source-registry configuration
1879 using the configuration API
1880 (@pxref{Controlling where ASDF searches for systems,Configuration API,Configuration API}, below)
1881 in which case this takes precedence.
1882 It may itself compute this configuration from the command-line,
1883 from a script, from its own configuration file, etc.
1886 The source registry will be configured from
1887 the environment variable @code{CL_SOURCE_REGISTRY} if it exists.
1890 The source registry will be configured from
1891 user configuration file
1892 @file{$XDG_CONFIG_DIRS/common-lisp/source-registry.conf}
1894 @file{~/.config/common-lisp/source-registry.conf})
1898 The source registry will be configured from
1899 user configuration directory
1900 @file{$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/}
1902 @file{~/.config/common-lisp/source-registry.conf.d/})
1906 The source registry will be configured from
1907 system configuration file
1908 @file{/etc/common-lisp/source-registry.conf}
1912 The source registry will be configured from
1913 system configuration directory
1914 @file{/etc/common-lisp/source-registry.conf.d/}
1918 The source registry will be configured from a default configuration.
1919 This configuration may allow for implementation-specific systems
1920 to be found, for systems to be found the current directory
1921 (at the time that the configuration is initialized) as well as
1922 @code{:directory} entries for @file{$XDG_DATA_DIRS/common-lisp/systems/} and
1923 @code{:tree} entries for @file{$XDG_DATA_DIRS/common-lisp/source/}.
1924 For instance, SBCL will include directories for its contribs
1925 when it can find them; it will look for them where SBCL was installed,
1926 or at the location specified by the @code{SBCL_HOME} environment variable.
1930 Each of these configurations is specified as an s-expression
1931 in a trivial domain-specific language (defined below).
1932 Additionally, a more shell-friendly syntax is available
1933 for the environment variable (defined yet below).
1935 Each of these configurations is only used if the previous
1936 configuration explicitly or implicitly specifies that it
1937 includes its inherited configuration.
1939 Additionally, some implementation-specific directories
1940 may be automatically prepended to whatever directories are specified
1941 in configuration files, no matter if the last one inherits or not.
1943 @section XDG base directory
1945 Note that we purport to respect the XDG base directory specification
1946 as to where configuration files are located,
1947 where data files are located,
1948 where output file caches are located.
1949 Mentions of XDG variables refer to that document.
1951 @url{http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html}
1953 This specification allows the user to specify some environment variables
1954 to customize how applications behave to his preferences.
1956 On Windows platforms, when not using Cygwin,
1957 instead of the XDG base directory specification,
1958 we try to use folder configuration from the registry regarding
1959 @code{Common AppData} and similar directories.
1960 However, support for querying the Windows registry is limited as of ASDF 2,
1961 and on many implementations, we may fall back to always using the defaults
1962 without consulting the registry.
1965 @section Backward Compatibility
1967 For backward compatibility as well as to provide a practical backdoor for hackers,
1968 ASDF will first search for @code{.asd} files in the directories specified in
1969 @code{asdf:*central-registry*}
1970 before it searches in the source registry above.
1972 @xref{Configuring ASDF,,Configuring ASDF to find your systems --- old style}.
1974 By default, @code{asdf:*central-registry*} will be empty.
1976 This old mechanism will therefore not affect you if you don't use it,
1977 but will take precedence over the new mechanism if you do use it.
1979 @section Configuration DSL
1981 Here is the grammar of the s-expression (SEXP) DSL for source-registry
1984 @c FIXME: This is too wide for happy compilation into pdf.
1987 ;; A configuration is a single SEXP starting with keyword :source-registry
1988 ;; followed by a list of directives.
1989 CONFIGURATION := (:source-registry DIRECTIVE ...)
1991 ;; A directive is one of the following:
1993 ;; INHERITANCE DIRECTIVE:
1994 ;; Your configuration expression MUST contain
1995 ;; exactly one of either of these:
1996 :inherit-configuration | ; splices inherited configuration (often specified last)
1997 :ignore-inherited-configuration | ; drop inherited configuration (specified anywhere)
1999 ;; forward compatibility directive (since ASDF 2.011.4), useful when
2000 ;; you want to use new configuration features but have to bootstrap a
2001 ;; the newer required ASDF from an older release that doesn't sport said features:
2002 :ignore-invalid-entries | ; drops subsequent invalid entries instead of erroring out
2004 ;; add a single directory to be scanned (no recursion)
2005 (:directory DIRECTORY-PATHNAME-DESIGNATOR) |
2007 ;; add a directory hierarchy, recursing but excluding specified patterns
2008 (:tree DIRECTORY-PATHNAME-DESIGNATOR) |
2010 ;; override the defaults for exclusion patterns
2011 (:exclude EXCLUSION-PATTERN ...) |
2012 ;; augment the defaults for exclusion patterns
2013 (:also-exclude EXCLUSION-PATTERN ...) |
2014 ;; Note that the scope of a an exclude pattern specification is
2015 ;; the rest of the current configuration expression or file.
2017 ;; splice the parsed contents of another config file
2018 (:include REGULAR-FILE-PATHNAME-DESIGNATOR) |
2020 ;; This directive specifies that some default must be spliced.
2023 REGULAR-FILE-PATHNAME-DESIGNATOR := PATHNAME-DESIGNATOR ;; interpreted as a file
2024 DIRECTORY-PATHNAME-DESIGNATOR := PATHNAME-DESIGNATOR ;; interpreted as a directory name
2026 PATHNAME-DESIGNATOR :=
2027 NIL | ;; Special: skip this entry.
2028 ABSOLUTE-COMPONENT-DESIGNATOR ;; see pathname DSL
2030 EXCLUSION-PATTERN := a string without wildcards, that will be matched exactly
2031 against the name of a any subdirectory in the directory component
2032 of a path. e.g. @code{"_darcs"} will match @file{#p"/foo/bar/_darcs/src/bar.asd"}
2035 Pathnames are designated using another DSL,
2036 shared with the output-translations configuration DSL below.
2037 The DSL is resolved by the function @code{asdf::resolve-location},
2038 to be documented and exported at some point in the future.
2041 ABSOLUTE-COMPONENT-DESIGNATOR :=
2042 (ABSOLUTE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
2043 STRING | ;; namestring (better be absolute or bust, directory assumed where applicable).
2044 ;; In output-translations, directory is assumed and **/*.*.* added if it's last.
2045 ;; On MCL, a MacOSX-style POSIX namestring (for MacOS9 style, use #p"...");
2046 ;; Note that none of the above applies to strings used in *central-registry*,
2047 ;; which doesn't use this DSL: they are processed as normal namestrings.
2048 ;; however, you can compute what you put in the *central-registry*
2049 ;; based on the results of say (asdf::resolve-location "/Users/fare/cl/cl-foo/")
2050 PATHNAME | ;; pathname (better be an absolute path, or bust)
2051 ;; In output-translations, unless followed by relative components,
2052 ;; it better have appropriate wildcards, as in **/*.*.*
2053 :HOME | ;; designates the user-homedir-pathname ~/
2054 :USER-CACHE | ;; designates the default location for the user cache
2055 :HERE | ;; designates the location of the configuration file
2056 ;; (or *default-pathname-defaults*, if invoked interactively)
2057 :ROOT ;; magic, for output-translations source only: paths that are relative
2058 ;; to the root of the source host and device
2059 ;; Not valid anymore: :SYSTEM-CACHE (was a security hazard)
2061 RELATIVE-COMPONENT-DESIGNATOR :=
2062 (RELATIVE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
2063 STRING | ;; relative directory pathname as interpreted by coerce-pathname.
2064 ;; In output translations, if last component, **/*.*.* is added
2065 PATHNAME | ;; pathname; unless last component, directory is assumed.
2066 :IMPLEMENTATION | ;; directory based on implementation, e.g. sbcl-1.0.49-linux-x64
2067 :IMPLEMENTATION-TYPE | ;; a directory based on lisp-implementation-type only, e.g. sbcl
2068 :DEFAULT-DIRECTORY | ;; a relativized version of the default directory
2069 :*/ | ;; any direct subdirectory (since ASDF 2.011.4)
2070 :**/ | ;; any recursively inferior subdirectory (since ASDF 2.011.4)
2071 :*.*.* | ;; any file (since ASDF 2.011.4)
2072 ;; Not supported (anymore): :UID and :USERNAME
2075 For instance, as a simple case, my @file{~/.config/common-lisp/source-registry.conf},
2076 which is the default place ASDF looks for this configuration, once contained:
2079 (:tree (:home "cl")) ;; will expand to e.g. "/home/joeluser/cl/"
2080 :inherit-configuration)
2083 @section Configuration Directories
2085 Configuration directories consist in files each containing
2086 a list of directives without any enclosing @code{(:source-registry ...)} form.
2087 The files will be sorted by namestring as if by @code{string<} and
2088 the lists of directives of these files with be concatenated in order.
2089 An implicit @code{:inherit-configuration} will be included
2090 at the @emph{end} of the list.
2092 This allows for packaging software that has file granularity
2093 (e.g. Debian's @code{dpkg} or some future version of @code{clbuild})
2094 to easily include configuration information about distributed software.
2096 The convention is that, for sorting purposes,
2097 the names of files in such a directory begin with two digits
2098 that determine the order in which these entries will be read.
2099 Also, the type of these files is conventionally @code{"conf"}
2100 and as a limitation to some implementations (e.g. GNU clisp),
2101 the type cannot be @code{NIL}.
2103 Directories may be included by specifying a directory pathname
2104 or namestring in an @code{:include} directive, e.g.:
2107 (:include "/foo/bar/")
2110 Hence, to achieve the same effect as
2111 my example @file{~/.config/common-lisp/source-registry.conf} above,
2112 I could simply create a file
2113 @file{~/.config/common-lisp/source-registry.conf.d/33-home-fare-cl.conf}
2114 alone in its directory with the following contents:
2116 (:tree "/home/fare/cl/")
2119 @subsection The :here directive
2121 The @code{:here} directive is an absolute pathname designator that
2122 refers to the directory containing the configuration file currently
2125 The @code{:here} directive is intended to simplify the delivery of
2126 complex CL systems, and for easy configuration of projects shared through
2127 revision control systems, in accordance with our design principle that
2128 each participant should be able to provide all and only the information
2129 available to him or her.
2131 Consider a person X who has set up the source code repository for a
2132 complex project with a master directory @file{dir/}. Ordinarily, one
2133 might simply have the user add a directive that would look something
2136 (:tree "path/to/dir")
2138 But what if X knows that there are very large subtrees
2139 under dir that are filled with, e.g., Java source code, image files for
2140 icons, etc.? All of the asdf system definitions are contained in the
2141 subdirectories @file{dir/src/lisp/} and @file{dir/extlib/lisp/}, and
2142 these are the only directories that should be searched.
2144 In this case, X can put into @file{dir/} a file @file{asdf.conf} that
2145 contains the following:
2148 (:tree (:here "src/lisp/"))
2149 (:tree (:here "extlib/lisp"))
2150 (:directory (:here "outlier/")))
2153 Then when someone else (call her Y) checks out a copy of this
2154 repository, she need only add
2156 (:include "/path/to/my/checkout/directory/asdf.conf")
2158 to one of her previously-existing asdf source location configuration
2159 files, or invoke @code{initialize-source-registry} with a configuration
2160 form containing that s-expression. ASDF will find the .conf file that X
2161 has provided, and then set up source locations within the working
2162 directory according to X's (relative) instructions.
2164 @section Shell-friendly syntax for configuration
2166 When considering environment variable @code{CL_SOURCE_REGISTRY}
2167 ASDF will skip to next configuration if it's an empty string.
2168 It will @code{READ} the string as a SEXP in the DSL
2169 if it begins with a paren @code{(}
2170 and it will be interpreted much like @code{TEXINPUTS}
2171 list of paths, where
2173 * paths are separated
2174 by a @code{:} (colon) on Unix platforms (including cygwin),
2175 by a @code{;} (semicolon) on other platforms (mainly, Windows).
2177 * each entry is a directory to add to the search path.
2179 * if the entry ends with a double slash @code{//}
2180 then it instead indicates a tree in the subdirectories
2181 of which to recurse.
2183 * if the entry is the empty string (which may only appear once),
2184 then it indicates that the inherited configuration should be
2188 @section Search Algorithm
2189 @vindex *default-source-registry-exclusions*
2191 In case that isn't clear, the semantics of the configuration is that
2192 when searching for a system of a given name,
2193 directives are processed in order.
2195 When looking in a directory, if the system is found, the search succeeds,
2196 otherwise it continues.
2198 When looking in a tree, if one system is found, the search succeeds.
2199 If multiple systems are found, the consequences are unspecified:
2200 the search may succeed with any of the found systems,
2201 or an error may be raised.
2202 ASDF currently returns the first system found,
2203 XCVB currently raised an error.
2204 If none is found, the search continues.
2206 Exclude statements specify patterns of subdirectories
2207 the systems from which to ignore.
2208 Typically you don't want to use copies of files kept by such
2209 version control systems as Darcs.
2210 Exclude statements are not propagated to further included or inherited
2211 configuration files or expressions;
2212 instead the defaults are reset around every configuration statement
2213 to the default defaults from @code{asdf::*default-source-registry-exclusions*}.
2215 Include statements cause the search to recurse with the path specifications
2216 from the file specified.
2218 An inherit-configuration statement cause the search to recurse with the path
2219 specifications from the next configuration
2220 (@pxref{Controlling where ASDF searches for systems,,Configurations} above).
2223 @section Caching Results
2225 The implementation is allowed to either eagerly compute the information
2226 from the configurations and file system, or to lazily re-compute it
2227 every time, or to cache any part of it as it goes.
2228 To explicitly flush any information cached by the system, use the API below.
2231 @section Configuration API
2233 The specified functions are exported from your build system's package.
2234 Thus for ASDF the corresponding functions are in package ASDF,
2235 and for XCVB the corresponding functions are in package XCVB.
2237 @defun initialize-source-registry @&optional PARAMETER
2238 will read the configuration and initialize all internal variables.
2239 You may extend or override configuration
2240 from the environment and configuration files
2241 with the given @var{PARAMETER}, which can be
2242 @code{NIL} (no configuration override),
2243 or a SEXP (in the SEXP DSL),
2244 a string (as in the string DSL),
2245 a pathname (of a file or directory with configuration),
2246 or a symbol (fbound to function that when called returns one of the above).
2249 @defun clear-source-registry
2250 undoes any source registry configuration
2251 and clears any cache for the search algorithm.
2252 You might want to call this function
2253 (or better, @code{clear-configuration})
2254 before you dump an image that would be resumed
2255 with a different configuration,
2256 and return an empty configuration.
2257 Note that this does not include clearing information about
2258 systems defined in the current image, only about
2259 where to look for systems not yet defined.
2262 @defun ensure-source-registry @&optional PARAMETER
2263 checks whether a source registry has been initialized.
2264 If not, initialize it with the given @var{PARAMETER}.
2267 Every time you use ASDF's @code{find-system}, or
2268 anything that uses it (such as @code{operate}, @code{load-system}, etc.),
2269 @code{ensure-source-registry} is called with parameter NIL,
2270 which the first time around causes your configuration to be read.
2271 If you change a configuration file,
2272 you need to explicitly @code{initialize-source-registry} again,
2273 or maybe simply to @code{clear-source-registry} (or @code{clear-configuration})
2274 which will cause the initialization to happen next time around.
2279 If this mechanism is successful, in the future, we may declare
2280 @code{asdf:*central-registry*} obsolete and eventually remove it.
2281 Any hook into implementation-specific search mechanisms will by then
2282 have been integrated in the @code{:default-configuration} which everyone
2283 should either explicitly use or implicit inherit. Some shell syntax
2284 for it should probably be added somehow.
2286 But we're not there yet. For now, let's see how practical this new
2290 @section Rejected ideas
2292 Alternatives I considered and rejected included:
2295 @item Keep @code{asdf:*central-registry*} as the master with its current semantics,
2296 and somehow the configuration parser expands the new configuration
2297 language into a expanded series of directories of subdirectories to
2298 lookup, pre-recursing through specified hierarchies. This is kludgy,
2299 and leaves little space of future cleanups and extensions.
2301 @item Keep @code{asdf:*central-registry*} remains the master but extend its semantics
2302 in completely new ways, so that new kinds of entries may be implemented
2303 as a recursive search, etc. This seems somewhat backwards.
2305 @item Completely remove @code{asdf:*central-registry*}
2306 and break backwards compatibility.
2307 Hopefully this will happen in a few years after everyone migrate to
2308 a better ASDF and/or to XCVB, but it would be very bad to do it now.
2310 @item Replace @code{asdf:*central-registry*} by a symbol-macro with appropriate magic
2311 when you dereference it or setf it. Only the new variable with new
2312 semantics is handled by the new search procedure.
2313 Complex and still introduces subtle semantic issues.
2317 I've been suggested the below features, but have rejected them,
2318 for the sake of keeping ASDF no more complex than strictly necessary.
2322 More syntactic sugar: synonyms for the configuration directives, such as
2323 @code{(:add-directory X)} for @code{(:directory X)}, or @code{(:add-directory-hierarchy X)}
2324 or @code{(:add-directory X :recurse t)} for @code{(:tree X)}.
2327 The possibility to register individual files instead of directories.
2330 Integrate Xach Beane's tilde expander into the parser,
2331 or something similar that is shell-friendly or shell-compatible.
2332 I'd rather keep ASDF minimal. But maybe this precisely keeps it
2333 minimal by removing the need for evaluated entries that ASDF has?
2334 i.e. uses of @code{USER-HOMEDIR-PATHNAME} and @code{$SBCL_HOME}
2335 Hopefully, these are already superseded by the @code{:default-registry}
2338 Using the shell-unfriendly syntax @code{/**} instead of @code{//} to specify recursion
2339 down a filesystem tree in the environment variable.
2340 It isn't that Lisp friendly either.
2350 @section Credits for the source-registry
2352 Thanks a lot to Stelian Ionescu for the initial idea.
2354 Thanks to Rommel Martinez for the initial implementation attempt.
2356 All bad design ideas and implementation bugs are to mine, not theirs.
2357 But so are good design ideas and elegant implementation tricks.
2359 --- Francois-Rene Rideau @email{fare@@tunes.org}, Mon, 22 Feb 2010 00:07:33 -0500
2363 @node Controlling where ASDF saves compiled files, Error handling, Controlling where ASDF searches for systems, Top
2364 @comment node-name, next, previous, up
2365 @chapter Controlling where ASDF saves compiled files
2366 @cindex asdf-output-translations
2367 @vindex ASDF_OUTPUT_TRANSLATIONS
2369 Each Common Lisp implementation has its own format
2370 for compiled files (fasls for short, short for ``fast loading'').
2371 If you use multiple implementations
2372 (or multiple versions of the same implementation),
2373 you'll soon find your source directories
2374 littered with various @file{fasl}s, @file{dfsl}s, @file{cfsl}s and so on.
2375 Worse yet, some implementations use the same file extension
2376 while changing formats from version to version (or platform to platform)
2377 which means that you'll have to recompile binaries
2378 as you switch from one implementation to the next.
2380 ASDF 2 includes the @code{asdf-output-translations} facility
2381 to mitigate the problem.
2383 @section Configurations
2385 Configurations specify mappings from input locations to output locations.
2386 Once again we rely on the XDG base directory specification for configuration.
2387 @xref{Controlling where ASDF searches for systems,,XDG base directory}.
2392 Some hardcoded wrapping output translations configuration may be used.
2393 This allows special output translations (or usually, invariant directories)
2394 to be specified corresponding to the similar special entries in the source registry.
2397 An application may explicitly initialize the output-translations
2398 configuration using the Configuration API
2399 in which case this takes precedence.
2400 (@pxref{Controlling where ASDF saves compiled files,,Configuration API}.)
2401 It may itself compute this configuration from the command-line,
2402 from a script, from its own configuration file, etc.
2405 The source registry will be configured from
2406 the environment variable @code{ASDF_OUTPUT_TRANSLATIONS} if it exists.
2409 The source registry will be configured from
2410 user configuration file
2411 @file{$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf}
2413 @file{~/.config/common-lisp/asdf-output-translations.conf})
2417 The source registry will be configured from
2418 user configuration directory
2419 @file{$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf.d/}
2421 @file{~/.config/common-lisp/asdf-output-translations.conf.d/})
2425 The source registry will be configured from
2426 system configuration file
2427 @file{/etc/common-lisp/asdf-output-translations.conf}
2431 The source registry will be configured from
2432 system configuration directory
2433 @file{/etc/common-lisp/asdf-output-translations.conf.d/}
2438 Each of these configurations is specified as a SEXP
2439 in a trival domain-specific language (defined below).
2440 Additionally, a more shell-friendly syntax is available
2441 for the environment variable (defined yet below).
2443 Each of these configurations is only used if the previous
2444 configuration explicitly or implicitly specifies that it
2445 includes its inherited configuration.
2447 Note that by default, a per-user cache is used for output files.
2448 This allows the seamless use of shared installations of software
2449 between several users, and takes files out of the way of the developers
2450 when they browse source code,
2451 at the expense of taking a small toll when developers have to clean up
2452 output files and find they need to get familiar with output-translations first.
2455 @section Backward Compatibility
2456 @cindex ASDF-BINARY-LOCATIONS compatibility
2459 We purposefully do NOT provide backward compatibility with earlier versions of
2460 @code{ASDF-Binary-Locations} (8 Sept 2009),
2461 @code{common-lisp-controller} (7.0) or
2462 @code{cl-launch} (2.35),
2463 each of which had similar general capabilities.
2464 The previous APIs of these programs were not designed
2465 for configuration by the end-user
2466 in an easy way with configuration files.
2467 Recent versions of same packages use
2468 the new @code{asdf-output-translations} API as defined below:
2469 @code{common-lisp-controller} (7.2) and @code{cl-launch} (3.000).
2470 @code{ASDF-Binary-Locations} is fully superseded and not to be used anymore.
2472 This incompatibility shouldn't inconvenience many people.
2473 Indeed, few people use and customize these packages;
2474 these few people are experts who can trivially adapt to the new configuration.
2475 Most people are not experts, could not properly configure these features
2476 (except inasmuch as the default configuration of
2477 @code{common-lisp-controller} and/or @code{cl-launch}
2478 might have been doing the right thing for some users),
2479 and yet will experience software that ``just works'',
2480 as configured by the system distributor, or by default.
2482 Nevertheless, if you are a fan of @code{ASDF-Binary-Locations},
2483 we provide a limited emulation mode:
2485 @defun enable-asdf-binary-locations-compatibility @&key centralize-lisp-binaries default-toplevel-directory include-per-user-information map-all-source-files source-to-target-mappings
2486 This function will initialize the new @code{asdf-output-translations} facility in a way
2487 that emulates the behavior of the old @code{ASDF-Binary-Locations} facility.
2488 Where you would previously set global variables
2489 @var{*centralize-lisp-binaries*},
2490 @var{*default-toplevel-directory*},
2491 @var{*include-per-user-information*},
2492 @var{*map-all-source-files*} or @var{*source-to-target-mappings*}
2493 you will now have to pass the same values as keyword arguments to this function.
2494 Note however that as an extension the @code{:source-to-target-mappings} keyword argument
2495 will accept any valid pathname designator for @code{asdf-output-translations}
2496 instead of just strings and pathnames.
2499 If you insist, you can also keep using the old @code{ASDF-Binary-Locations}
2500 (the one available as an extension to load of top of ASDF,
2501 not the one built into a few old versions of ASDF),
2502 but first you must disable @code{asdf-output-translations}
2503 with @code{(asdf:disable-output-translations)},
2504 or you might experience ``interesting'' issues.
2506 Also, note that output translation is enabled by default.
2507 To disable it, use @code{(asdf:disable-output-translations)}.
2510 @section Configuration DSL
2512 Here is the grammar of the SEXP DSL
2513 for @code{asdf-output-translations} configuration:
2516 ;; A configuration is single SEXP starting with keyword :source-registry
2517 ;; followed by a list of directives.
2518 CONFIGURATION := (:output-translations DIRECTIVE ...)
2520 ;; A directive is one of the following:
2522 ;; INHERITANCE DIRECTIVE:
2523 ;; Your configuration expression MUST contain
2524 ;; exactly one of either of these:
2525 :inherit-configuration | ; splices inherited configuration (often specified last)
2526 :ignore-inherited-configuration | ; drop inherited configuration (specified anywhere)
2528 ;; forward compatibility directive (since ASDF 2.011.4), useful when
2529 ;; you want to use new configuration features but have to bootstrap a
2530 ;; the newer required ASDF from an older release that doesn't sport said features:
2531 :ignore-invalid-entries | ; drops subsequent invalid entries instead of erroring out
2533 ;; include a configuration file or directory
2534 (:include PATHNAME-DESIGNATOR) |
2536 ;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/ or something.
2537 :enable-user-cache |
2538 ;; Disable global cache. Map / to /
2541 ;; add a single directory to be scanned (no recursion)
2542 (DIRECTORY-DESIGNATOR DIRECTORY-DESIGNATOR)
2544 ;; use a function to return the translation of a directory designator
2545 (DIRECTORY-DESIGNATOR (:function TRANSLATION-FUNCTION))
2547 DIRECTORY-DESIGNATOR :=
2548 NIL | ;; As source: skip this entry. As destination: same as source
2549 T | ;; as source matches anything, as destination leaves pathname unmapped.
2550 ABSOLUTE-COMPONENT-DESIGNATOR ;; same as in the source-registry language
2552 TRANSLATION-FUNCTION :=
2553 SYMBOL | ;; symbol of a function that takes two arguments,
2554 ;; the pathname to be translated and the matching DIRECTORY-DESIGNATOR
2555 LAMBDA ;; A form which evalutates to a function taking two arguments consisting of
2556 ;; the pathname to be translated and the matching DIRECTORY-DESIGNATOR
2560 Relative components better be either relative
2561 or subdirectories of the path before them, or bust.
2563 The last component, if not a pathname, is notionally completed by @file{/**/*.*}.
2564 You can specify more fine-grained patterns
2565 by using a pathname object as the last component
2566 e.g. @file{#p"some/path/**/foo*/bar-*.fasl"}
2568 You may use @code{#+features} to customize the configuration file.
2570 The second designator of a mapping may be @code{NIL}, indicating that files are not mapped
2571 to anything but themselves (same as if the second designator was the same as the first).
2573 When the first designator is @code{t},
2574 the mapping always matches.
2575 When the first designator starts with @code{:root},
2576 the mapping matches any host and device.
2577 In either of these cases, if the second designator
2578 isn't @code{t} and doesn't start with @code{:root},
2579 then strings indicating the host and pathname are somehow copied
2580 in the beginning of the directory component of the source pathname
2581 before it is translated.
2583 When the second designator is @code{t}, the mapping is the identity.
2584 When the second designator starts with @code{:root},
2585 the mapping preserves the host and device of the original pathname.
2586 Notably, this allows you to map files
2587 to a subdirectory of the whichever directory the file is in.
2588 Though the syntax is not quite as easy to use as we'd like,
2589 you can have an (source destination) mapping entry such as follows
2590 in your configuration file,
2591 or you may use @code{enable-asdf-binary-locations-compatibility}
2592 with @code{:centralize-lisp-binaries nil}
2593 which will do the same thing internally for you:
2595 #.(let ((wild-subdir (make-pathname :directory '(:relative :wild-inferiors)))
2596 (wild-file (make-pathname :name :wild :version :wild :type :wild)))
2597 `((:root ,wild-subdir ,wild-file) ;; Or using the implicit wildcard, just :root
2598 (:root ,wild-subdir :implementation ,wild-file)))
2600 Starting with ASDF 2.011.4, you can use the simpler:
2601 @code{`(:root (:root :**/ :implementation :*.*.*))}
2605 @code{:include} statements cause the search to recurse with the path specifications
2606 from the file specified.
2608 If the @code{translate-pathname} mechanism cannot achieve a desired
2609 translation, the user may provide a function which provides the
2610 required algorithim. Such a translation function is specified by
2611 supplying a list as the second @code{directory-designator}
2612 the first element of which is the keyword @code{:function},
2613 and the second element of which is
2614 either a symbol which designates a function or a lambda expression.
2615 The function designated by the second argument must take two arguments,
2616 the first being the pathname of the source file,
2617 the second being the wildcard that was matched.
2618 The result of the function invocation should be the translated pathname.
2620 An @code{:inherit-configuration} statement cause the search to recurse with the path
2621 specifications from the next configuration.
2622 @xref{Controlling where ASDF saves compiled files,,Configurations}, above.
2626 @code{:enable-user-cache} is the same as @code{(t :user-cache)}.
2628 @code{:disable-cache} is the same as @code{(t t)}.
2630 @code{:user-cache} uses the contents of variable @code{asdf::*user-cache*}
2631 which by default is the same as using
2632 @code{(:home ".cache" "common-lisp" :implementation)}.
2634 @code{:system-cache} uses the contents of variable @code{asdf::*system-cache*}
2635 which by default is the same as using
2636 @code{("/var/cache/common-lisp" :uid :implementation-type)}
2637 (on Unix and cygwin), or something semi-sensible on Windows.
2641 @section Configuration Directories
2643 Configuration directories consist in files each contains
2644 a list of directives without any enclosing
2645 @code{(:output-translations ...)} form.
2646 The files will be sorted by namestring as if by @code{string<} and
2647 the lists of directives of these files with be concatenated in order.
2648 An implicit @code{:inherit-configuration} will be included
2649 at the @emph{end} of the list.
2651 This allows for packaging software that has file granularity
2652 (e.g. Debian's @command{dpkg} or some future version of @command{clbuild})
2653 to easily include configuration information about software being distributed.
2655 The convention is that, for sorting purposes,
2656 the names of files in such a directory begin with two digits
2657 that determine the order in which these entries will be read.
2658 Also, the type of these files is conventionally @code{"conf"}
2659 and as a limitation of some implementations, the type cannot be @code{NIL}.
2661 Directories may be included by specifying a directory pathname
2662 or namestring in an @code{:include} directive, e.g.:
2664 (:include "/foo/bar/")
2667 @section Shell-friendly syntax for configuration
2669 When considering environment variable @code{ASDF_OUTPUT_TRANSLATIONS}
2670 ASDF will skip to next configuration if it's an empty string.
2671 It will @code{READ} the string as an SEXP in the DSL
2672 if it begins with a paren @code{(}
2673 and it will be interpreted as a list of directories.
2674 Directories should come by pairs, indicating a mapping directive.
2675 Entries are separated
2676 by a @code{:} (colon) on Unix platforms (including cygwin),
2677 by a @code{;} (semicolon) on other platforms (mainly, Windows).
2679 The magic empty entry,
2680 if it comes in what would otherwise be the first entry in a pair,
2681 indicates the splicing of inherited configuration.
2682 If it comes as the second entry in a pair,
2683 it indicates that the directory specified first is to be left untranslated
2684 (which has the same effect as if the directory had been repeated).
2687 @section Semantics of Output Translations
2689 From the specified configuration,
2690 a list of mappings is extracted in a straightforward way:
2691 mappings are collected in order, recursing through
2692 included or inherited configuration as specified.
2693 To this list is prepended some implementation-specific mappings,
2694 and is appended a global default.
2696 The list is then compiled to a mapping table as follows:
2697 for each entry, in order, resolve the first designated directory
2698 into an actual directory pathname for source locations.
2699 If no mapping was specified yet for that location,
2700 resolve the second designated directory to an output location directory
2701 add a mapping to the table mapping the source location to the output location,
2702 and add another mapping from the output location to itself
2703 (unless a mapping already exists for the output location).
2705 Based on the table, a mapping function is defined,
2706 mapping source pathnames to output pathnames:
2707 given a source pathname, locate the longest matching prefix
2708 in the source column of the mapping table.
2709 Replace that prefix by the corresponding output column
2710 in the same row of the table, and return the result.
2711 If no match is found, return the source pathname.
2712 (A global default mapping the filesystem root to itself
2713 may ensure that there will always be a match,
2714 with same fall-through semantics).
2716 @section Caching Results
2718 The implementation is allowed to either eagerly compute the information
2719 from the configurations and file system, or to lazily re-compute it
2720 every time, or to cache any part of it as it goes.
2721 To explicitly flush any information cached by the system, use the API below.
2724 @section Output location API
2726 The specified functions are exported from package ASDF.
2728 @defun initialize-output-translations @&optional PARAMETER
2729 will read the configuration and initialize all internal variables.
2730 You may extend or override configuration
2731 from the environment and configuration files
2732 with the given @var{PARAMETER}, which can be
2733 @code{NIL} (no configuration override),
2734 or a SEXP (in the SEXP DSL),
2735 a string (as in the string DSL),
2736 a pathname (of a file or directory with configuration),
2737 or a symbol (fbound to function that when called returns one of the above).
2740 @defun disable-output-translations
2741 will initialize output translations in a way
2742 that maps every pathname to itself,
2743 effectively disabling the output translation facility.
2746 @defun clear-output-translations
2747 undoes any output translation configuration
2748 and clears any cache for the mapping algorithm.
2749 You might want to call this function
2750 (or better, @code{clear-configuration})
2751 before you dump an image that would be resumed
2752 with a different configuration,
2753 and return an empty configuration.
2754 Note that this does not include clearing information about
2755 systems defined in the current image, only about
2756 where to look for systems not yet defined.
2759 @defun ensure-output-translations @&optional PARAMETER
2760 checks whether output translations have been initialized.
2761 If not, initialize them with the given @var{PARAMETER}.
2762 This function will be called before any attempt to operate on a system.
2765 @defun apply-output-translations PATHNAME
2766 Applies the configured output location translations to @var{PATHNAME}
2767 (calls @code{ensure-output-translations} for the translations).
2770 Every time you use ASDF's @code{output-files}, or
2771 anything that uses it (that may compile, such as @code{operate}, @code{perform}, etc.),
2772 @code{ensure-output-translations} is called with parameter NIL,
2773 which the first time around causes your configuration to be read.
2774 If you change a configuration file,
2775 you need to explicitly @code{initialize-output-translations} again,
2776 or maybe @code{clear-output-translations} (or @code{clear-configuration}),
2777 which will cause the initialization to happen next time around.
2780 @section Credits for output translations
2782 Thanks a lot to Bjorn Lindberg and Gary King for @code{ASDF-Binary-Locations},
2783 and to Peter van Eynde for @code{Common Lisp Controller}.
2785 All bad design ideas and implementation bugs are to mine, not theirs.
2786 But so are good design ideas and elegant implementation tricks.
2788 --- Francois-Rene Rideau @email{fare@@tunes.org}
2790 @c @section Default locations
2791 @c @findex output-files-for-system-and-operation
2793 @c The default binary location for each Lisp implementation
2794 @c is a subdirectory of each source directory.
2795 @c To account for different Lisps, Operating Systems, Implementation versions,
2796 @c and so on, ASDF borrows code from SLIME
2797 @c to create reasonable custom directory names.
2798 @c Here are some examples:
2802 @c SBCL, version 1.0.45 on Mac OS X for Intel: @code{sbcl-1.0.45-darwin-x86}
2805 @c Franz Allegro, version 8.0, ANSI Common Lisp: @code{allegro-8.0a-macosx-x86}
2808 @c Franz Allegro, version 8.1, Modern (case sensitive) Common Lisp: @code{allegro-8.1m-macosx-x86}
2811 @c By default, all output file pathnames will be relocated
2812 @c to some thus-named subdirectory of @file{~/.cache/common-lisp/}.
2814 @c See the document @file{README.asdf-output-translations}
2815 @c for a full specification on how to configure @code{asdf-output-translations}.
2817 @node Error handling, Miscellaneous additional functionality, Controlling where ASDF saves compiled files, Top
2818 @comment node-name, next, previous, up
2819 @chapter Error handling
2820 @findex SYSTEM-DEFINITION-ERROR
2821 @findex OPERATION-ERROR
2823 @section ASDF errors
2825 If ASDF detects an incorrect system definition, it will signal a generalised instance of
2826 @code{SYSTEM-DEFINITION-ERROR}.
2828 Operations may go wrong (for example when source files contain errors).
2829 These are signalled using generalised instances of
2830 @code{OPERATION-ERROR}.
2832 @section Compilation error and warning handling
2833 @vindex *compile-file-warnings-behaviour*
2834 @vindex *compile-file-errors-behavior*
2836 ASDF checks for warnings and errors when a file is compiled.
2837 The variables @var{*compile-file-warnings-behaviour*} and
2838 @var{*compile-file-errors-behavior*}
2839 control the handling of any such events.
2840 The valid values for these variables are
2841 @code{:error}, @code{:warn}, and @code{:ignore}.
2843 @node Miscellaneous additional functionality, Getting the latest version, Error handling, Top
2844 @comment node-name, next, previous, up
2845 @chapter Miscellaneous additional functionality
2847 ASDF includes several additional features that are generally
2848 useful for system definition and development.
2850 @section Controlling file compilation
2852 When declaring a component (system, module, file),
2853 you can specify a keyword argument @code{:around-compile function}.
2854 If left unspecified,
2855 the value will be inherited from the parent component if any,
2856 or with a default of @code{nil}
2857 if no value is specified in any transitive parent.
2859 The argument must be a either @code{nil}, a fbound symbol,
2860 a lambda-expression (e.g. @code{(lambda (thunk) ...(funcall thunk) ...)})
2861 a function object (e.g. using @code{#.#'} but that's discouraged
2862 because it prevents the introspection done by e.g. asdf-dependency-grovel),
2863 or a string that when read yields a symbol or a lambda-expression.
2864 @code{nil} means the normal compile-file function will be called.
2865 A non-nil value designates a function of one argument
2866 that will be called with a thunk for calling
2867 the compile-file function with proper arguments.
2869 Note that by using a string, you may reference
2870 a function, symbol and/or package
2871 that will only be created later during the build, but
2872 isn't yet present at the time the defsystem form is evaluated.
2873 However, if your entire system is using such a hook, you may have to
2874 explicitly override the hook with @code{nil} for all the modules and files
2875 that are compiled before the hook is defined.
2877 Using this hook, you may achieve such effects as:
2878 locally renaming packages,
2879 binding @var{*readtables*} and other syntax-controlling variables,
2880 handling warnings and other conditions,
2881 proclaiming consistent optimization settings,
2882 saving code coverage information,
2883 maintaining meta-data about compilation timings,
2884 setting gensym counters and PRNG seeds and other sources of non-determinism,
2885 overriding the source-location and/or timestamping systems,
2886 checking that some compile-time side-effects were properly balanced,
2890 @section Miscellaneous Exported Functions
2892 @defun coerce-pathname name @&key type defaults
2894 This function (available starting with ASDF 2.012.11)
2895 takes an argument, and portably interprets it as a pathname.
2896 If the argument @var{name} is a pathname or @code{nil}, it is passed through;
2897 if it's a symbol, it's interpreted as a string by downcasing it;
2898 if it's a string, it is first separated using @code{/} into substrings;
2899 the leading substrings denote subdirectories of a relative pathname.
2900 If @var{type} is @code{:directory} or the string ends with @code{/},
2901 the last substring is also a subdirectory;
2902 if @var{type} is a string, it is used as the type of the pathname, and
2903 the last substring is the name component of the pathname;
2904 if @var{type} is @code{nil}, the last substring specifies both name and type components
2905 of the pathname, with the last @code{.} separating them, or only the name component
2906 if there's no last @code{.} or if there is only one dot and it's the first character.
2907 The host, device and version components come from @var{defaults}, which defaults to
2908 @var{*default-pathname-defaults*}; but that shouldn't matter if you use @code{merge-pathnames*}.
2912 @defun merge-pathnames* @&key specified defaults
2914 This function is a replacement for @code{merge-pathnames} that uses the host and device
2915 from the @var{defaults} rather than the @var{specified} pathname when the latter
2916 is a relative pathname. This allows ASDF and its users to create and use relative pathnames
2917 without having to know beforehand what are the host and device
2918 of the absolute pathnames they are relative to.
2922 @defun system-relative-pathname system name @&key type
2924 It's often handy to locate a file relative to some system.
2925 The @code{system-relative-pathname} function meets this need.
2927 It takes two mandatory arguments @var{system} and @var{name}
2928 and a keyword argument @var{type}:
2929 @var{system} is name of a system, whereas @var{name} and optionally @var{type}
2930 specify a relative pathname, interpreted like a component pathname specifier
2931 by @code{coerce-pathname}. @xref{The defsystem grammar,,Pathname specifiers}.
2933 It returns a pathname built from the location of the system's
2934 source directory and the relative pathname. For example:
2937 > (asdf:system-relative-pathname 'cl-ppcre "regex.data")
2938 #P"/repository/other/cl-ppcre/regex.data"
2943 @defun system-source-directory system-designator
2945 ASDF does not provide a turnkey solution for locating
2946 data (or other miscellaneous) files
2947 that are distributed together with the source code of a system.
2948 Programmers can use @code{system-source-directory} to find such files.
2949 Returns a pathname object.
2950 The @var{system-designator} may be a string, symbol, or ASDF system object.
2953 @defun clear-system system-designator
2955 It is sometimes useful to force recompilation of a previously loaded system.
2956 In these cases, it may be useful to @code{(asdf:clear-system :foo)}
2957 to remove the system from the table of currently loaded systems;
2958 the next time the system @code{foo} or one that depends on it is re-loaded,
2959 @code{foo} will then be loaded again.
2960 Alternatively, you could touch @code{foo.asd} or
2961 remove the corresponding fasls from the output file cache.
2962 (It was once conceived that one should provide
2963 a list of systems the recompilation of which to force
2964 as the @code{:force} keyword argument to @code{load-system};
2965 but this has never worked, and though the feature was fixed in ASDF 2.000,
2966 it remains @code{cerror}'ed out as nobody ever used it.)
2968 Note that this does not and cannot by itself undo the previous loading
2969 of the system. Common Lisp has no provision for such an operation,
2970 and its reliance on irreversible side-effects to global datastructures
2971 makes such a thing impossible in the general case.
2972 If the software being re-loaded is not conceived with hot upgrade in mind,
2973 this re-loading may cause many errors, warnings or subtle silent problems,
2974 as packages, generic function signatures, structures, types, macros, constants, etc.
2975 are being redefined incompatibly.
2976 It is up to the user to make sure that reloading is possible and has the desired effect.
2977 In some cases, extreme measures such as recursively deleting packages,
2978 unregistering symbols, defining methods on @code{update-instance-for-redefined-class}
2979 and much more are necessary for reloading to happen smoothly.
2980 ASDF itself goes through notable pains to make such a hot upgrade possible
2981 with respect to its own code, and what it does is ridiculously complex;
2982 look at the beginning of @file{asdf.lisp} to see what it does.
2985 @defun run-shell-command
2987 This function is obsolete and present only for the sake of backwards-compatibility:
2988 ``If it's not backwards, it's not compatible''. We strongly discourage its use.
2989 Its current behavior is only well-defined on Unix platforms
2990 (which includes MacOS X and cygwin). On Windows, anything goes.
2992 Instead we recommend the use of such a function as
2993 @code{xcvb-driver:run-program/process-output-stream}
2994 from the @code{xcvb-driver} system that is distributed with XCVB:
2995 @url{http://common-lisp.net/project/xcvb}.
2996 It's only alternative that supports
2997 as many implementations and operating systems as ASDF does,
2998 and provides well-defined behavior outside Unix (i.e. on Windows).
2999 (The only unsupported exception is Genera, since on it
3000 @code{run-shell-command} doesn't make sense anyway on that platform).
3002 This function takes as arguments a @code{format} control-string
3003 and arguments to be passed to @code{format} after this control-string
3004 to produce a string.
3005 This string is a command that will be evaluated with a POSIX shell if possible;
3006 yet, on Windows, some implementations will use CMD.EXE,
3007 while others (like SBCL) will make an attempt at invoking a POSIX shell
3008 (and fail if it is not present).
3012 @node Getting the latest version, FAQ, Miscellaneous additional functionality, Top
3013 @comment node-name, next, previous, up
3014 @chapter Getting the latest version
3016 Decide which version you want.
3017 The @code{master} branch is where development happens;
3018 its @code{HEAD} is usually OK, including the latest fixes and portability tweaks,
3019 but an occasional regression may happen despite our (limited) test suite.
3021 The @code{release} branch is what cautious people should be using;
3022 it has usually been tested more, and releases are cut at a point
3023 where there isn't any known unresolved issue.
3025 You may get the ASDF source repository using git:
3026 @kbd{git clone git://common-lisp.net/projects/asdf/asdf.git}
3028 You will find the above referenced tags in this repository.
3029 You can also browse the repository on
3030 @url{http://common-lisp.net/gitweb?p=projects/asdf/asdf.git}.
3032 Discussion of ASDF development is conducted on the
3034 @kbd{asdf-devel@@common-lisp.net}.
3035 @url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel}
3038 @node FAQ, TODO list, Getting the latest version, Top
3039 @comment node-name, next, previous, up
3042 @section ``Where do I report a bug?''
3044 ASDF bugs are tracked on launchpad: @url{https://launchpad.net/asdf}.
3046 If you're unsure about whether something is a bug, or for general discussion,
3047 use the @url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}
3050 @section ``What has changed between ASDF 1 and ASDF 2?''
3052 @subsection What are ASDF 1 and ASDF 2?
3054 On May 31st 2010, we have released ASDF 2.
3055 ASDF 2 refers to release 2.000 and later.
3056 (Releases between 1.656 and 1.728 were development releases for ASDF 2.)
3057 ASDF 1 to any release earlier than 1.369 or so.
3058 If your ASDF doesn't sport a version, it's an old ASDF 1.
3060 ASDF 2 and its release candidates push
3061 @code{:asdf2} onto @code{*features*} so that if you are writing
3062 ASDF-dependent code you may check for this feature
3063 to see if the new API is present.
3064 @emph{All} versions of ASDF should have the @code{:asdf} feature.
3066 If you are experiencing problems or limitations of any sort with ASDF 1,
3067 we recommend that you should upgrade to ASDF 2,
3068 or whatever is the latest release.
3071 @subsection ASDF can portably name files in subdirectories
3073 Common Lisp namestrings are not portable,
3074 except maybe for logical pathnamestrings,
3075 that themselves have various limitations and require a lot of setup
3076 that is itself ultimately non-portable.
3078 In ASDF 1, the only portable ways to refer to pathnames inside systems and components
3079 were very awkward, using @code{#.(make-pathname ...)} and
3080 @code{#.(merge-pathnames ...)}.
3081 Even the above were themselves were inadequate in the general case
3082 due to host and device issues, unless horribly complex patterns were used.
3083 Plenty of simple cases that looked portable actually weren't,
3084 leading to much confusion and greavance.
3086 ASDF 2 implements its own portable syntax for strings as pathname specifiers.
3087 Naming files within a system definition becomes easy and portable again.
3088 @xref{Miscellaneous additional functionality,asdf:system-relative-pathname},
3089 @code{merge-pathnames*},
3090 @code{coerce-pathname}.
3092 On the other hand, there are places where systems used to accept namestrings
3093 where you must now use an explicit pathname object:
3094 @code{(defsystem ... :pathname "LOGICAL-HOST:PATH;TO;SYSTEM;" ...)}
3095 must now be written with the @code{#p} syntax:
3096 @code{(defsystem ... :pathname #p"LOGICAL-HOST:PATH;TO;SYSTEM;" ...)}
3098 @xref{The defsystem grammar,,Pathname specifiers}.
3101 @subsection Output translations
3103 A popular feature added to ASDF was output pathname translation:
3104 @code{asdf-binary-locations}, @code{common-lisp-controller},
3105 @code{cl-launch} and other hacks were all implementing it in ways
3106 both mutually incompatible and difficult to configure.
3108 Output pathname translation is essential to share
3109 source directories of portable systems across multiple implementations
3110 or variants thereof,
3111 or source directories of shared installations of systems across multiple users,
3112 or combinations of the above.
3114 In ASDF 2, a standard mechanism is provided for that,
3115 @code{asdf-output-translations},
3116 with sensible defaults, adequate configuration languages,
3117 a coherent set of configuration files and hooks,
3118 and support for non-Unix platforms.
3120 @xref{Controlling where ASDF saves compiled files}.
3122 @subsection Source Registry Configuration
3124 Configuring ASDF used to require special magic
3125 to be applied just at the right moment,
3126 between the moment ASDF is loaded and the moment it is used,
3127 in a way that is specific to the user,
3128 the implementation he is using and the application he is building.
3130 This made for awkward configuration files and startup scripts
3131 that could not be shared between users, managed by administrators
3132 or packaged by distributions.
3134 ASDF 2 provides a well-documented way to configure ASDF,
3135 with sensible defaults, adequate configuration languages,
3136 and a coherent set of configuration files and hooks.
3138 We believe it's a vast improvement because it decouples
3139 application distribution from library distribution.
3140 The application writer can avoid thinking where the libraries are,
3141 and the library distributor (dpkg, clbuild, advanced user, etc.)
3142 can configure them once and for every application.
3143 Yet settings can be easily overridden where needed,
3144 so whoever needs control has exactly as much as required.
3146 At the same time, ASDF 2 remains compatible
3147 with the old magic you may have in your build scripts
3148 (using @code{*central-registry*} and
3149 @code{*system-definition-search-functions*})
3150 to tailor the ASDF configuration to your build automation needs,
3151 and also allows for new magic, simpler and more powerful magic.
3153 @xref{Controlling where ASDF searches for systems}.
3156 @subsection Usual operations are made easier to the user
3158 In ASDF 1, you had to use the awkward syntax
3159 @code{(asdf:oos 'asdf:load-op :foo)}
3161 and similarly for @code{compile-op}, @code{test-op}.
3163 In ASDF 2, you can use shortcuts for the usual operations:
3164 @code{(asdf:load-system :foo)}, and
3165 similarly for @code{compile-system}, @code{test-system}.
3168 @subsection Many bugs have been fixed
3170 The following issues and many others have been fixed:
3174 The infamous TRAVERSE function has been revamped significantly,
3175 with many bugs squashed.
3176 In particular, dependencies were not correctly propagated
3177 across submodules within a system but now are.
3178 The :version and :feature features and
3179 the :force (system1 .. systemN) feature have been fixed.
3182 Performance has been notably improved for large systems
3183 (say with thousands of components) by using
3184 hash-tables instead of linear search,
3185 and linear-time list accumulation
3186 instead of quadratic-time recursive appends.
3189 Many features used to not be portable,
3190 especially where pathnames were involved.
3191 Windows support was notably quirky because of such non-portability.
3194 The internal test suite used to massively fail on many implementations.
3195 While still incomplete, it now fully passes
3196 on all implementations supported by the test suite,
3197 except for GCL (due to GCL bugs).
3200 Support was lacking for some implementations.
3201 ABCL and GCL were notably wholly broken.
3202 ECL extensions were not integrated in the ASDF release.
3205 The documentation was grossly out of date.
3210 @subsection ASDF itself is versioned
3212 Between new features, old bugs fixed, and new bugs introduced,
3213 there were various releases of ASDF in the wild,
3214 and no simple way to check which release had which feature set.
3215 People using or writing systems had to either make worst-case assumptions
3216 as to what features were available and worked,
3217 or take great pains to have the correct version of ASDF installed.
3219 With ASDF 2, we provide a new stable set of working features
3220 that everyone can rely on from now on.
3221 Use @code{#+asdf2} to detect presence of ASDF 2,
3222 @code{(asdf:version-satisfies (asdf:asdf-version) "2.345.67")}
3223 to check the availability of a version no earlier than required.
3226 @subsection ASDF can be upgraded
3228 When an old version of ASDF was loaded,
3229 it was very hard to upgrade ASDF in your current image
3230 without breaking everything.
3231 Instead you had to exit the Lisp process and
3232 somehow arrange to start a new one from a simpler image.
3233 Something that can't be done from within Lisp,
3234 making automation of it difficult,
3235 which compounded with difficulty in configuration,
3236 made the task quite hard.
3237 Yet as we saw before, the task would have been required
3238 to not have to live with the worst case or non-portable
3239 subset of ASDF features.
3241 With ASDF 2, it is easy to upgrade
3242 from ASDF 2 to later versions from within Lisp,
3243 and not too hard to upgrade from ASDF 1 to ASDF 2 from within Lisp.
3244 We support hot upgrade of ASDF and any breakage is a bug
3245 that we will do our best to fix.
3246 There are still limitations on upgrade, though,
3247 most notably the fact that after you upgrade ASDF,
3248 you must also reload or upgrade all ASDF extensions.
3250 @subsection Decoupled release cycle
3252 When vendors were releasing their Lisp implementations with ASDF,
3253 they had to basically never change version
3254 because neither upgrade nor downgrade was possible
3255 without breaking something for someone,
3256 and no obvious upgrade path was visible and recommendable.
3258 With ASDF 2, upgrade is possible, easy and can be recommended.
3259 This means that vendors can safely ship a recent version of ASDF,
3260 confident that if a user isn't fully satisfied,
3261 he can easily upgrade ASDF and deal
3262 with a supported recent version of it.
3263 This means that release cycles will be causally decoupled,
3264 the practical consequence of which will mean faster convergence
3265 towards the latest version for everyone.
3268 @subsection Pitfalls of the transition to ASDF 2
3270 The main pitfalls in upgrading to ASDF 2 seem to be related
3271 to the output translation mechanism.
3276 Output translations is enabled by default. This may surprise some users,
3277 most of them in pleasant way (we hope), a few of them in an unpleasant way.
3278 It is trivial to disable output translations.
3279 @xref{FAQ,,``How can I wholly disable the compiler output cache?''}.
3282 Some systems in the large have been known not to play well with output translations.
3283 They were relatively easy to fix.
3284 Once again, it is also easy to disable output translations,
3285 or to override its configuration.
3288 The new ASDF output translations are incompatible with ASDF-Binary-Locations.
3289 They replace A-B-L, and there is compatibility mode to emulate
3290 your previous A-B-L configuration.
3291 See @code{enable-asdf-binary-locations-compatibility} in
3292 @pxref{Controlling where ASDF saves compiled files,,Backward Compatibility}.
3293 But thou shall not load ABL on top of ASDF 2.
3297 Other issues include the following:
3302 ASDF pathname designators are now specified in places where they were unspecified,
3303 and a few small adjustments have to be made to some non-portable defsystems.
3304 Notably, in the @code{:pathname} argument to a @code{defsystem} and its components,
3305 a logical pathname (or implementation-dependent hierarchical pathname)
3306 must now be specified with @code{#p} syntax
3307 where the namestring might have previously sufficed;
3308 moreover when evaluation is desired @code{#.} must be used,
3309 where it wasn't necessary in the toplevel @code{:pathname} argument.
3312 There is a slight performance bug, notably on SBCL,
3313 when initially searching for @file{asd} files,
3314 the implicit @code{(directory "/configured/path/**/*.asd")}
3315 for every configured path @code{(:tree "/configured/path/")}
3316 in your @code{source-registry} configuration can cause a slight pause.
3317 Try to @code{(time (asdf:initialize-source-registry))}
3318 to see how bad it is or isn't on your system.
3319 If you insist on not having this pause,
3320 you can avoid the pause by overriding the default source-registry configuration
3321 and not use any deep @code{:tree} entry but only @code{:directory} entries
3322 or shallow @code{:tree} entries.
3323 Or you can fix your implementation to not be quite that slow
3324 when recursing through directories.
3325 @emph{Update}: performance bug fixed the hard way in 2.010.
3328 On Windows, only LispWorks supports proper default configuration pathnames
3329 based on the Windows registry.
3330 Other implementations make do with environment variables,
3331 that you may have to define yourself if you're using an older version of Windows.
3332 Windows support is somewhat less tested than Unix support.
3333 Please help report and fix bugs.
3336 The mechanism by which one customizes a system so that Lisp files
3337 may use a different extension from the default @file{.lisp} has changed.
3338 Previously, the pathname for a component was lazily computed when operating on a system,
3340 @code{(defmethod source-file-type ((component cl-source-file) (system (eql (find-system 'foo))))
3341 (declare (ignorable component system)) "lis")}.
3342 Now, the pathname for a component is eagerly computed when defining the system,
3343 and instead you will @code{(defclass cl-source-file.lis (cl-source-file) ((type :initform "lis")))}
3344 and use @code{:default-component-class cl-source-file.lis} as argument to @code{defsystem},
3345 as detailed in a @pxref{FAQ,How do I create a system definition where all the source files have a .cl extension?} below.
3347 @findex source-file-type
3353 @section Issues with installing the proper version of ASDF
3355 @subsection ``My Common Lisp implementation comes with an outdated version of ASDF. What to do?''
3357 We recommend you upgrade ASDF.
3358 @xref{Loading ASDF,,Upgrading ASDF}.
3360 If this does not work, it is a bug, and you should report it.
3361 @xref{FAQ, report-bugs, Where do I report a bug}.
3362 In the meantime, you can load @file{asdf.lisp} directly.
3363 @xref{Loading ASDF,Loading an otherwise installed ASDF}.
3366 @subsection ``I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?''
3368 Starting with current candidate releases of ASDF 2,
3369 it should always be a good time to upgrade to a recent ASDF.
3370 You may consult with the maintainer for which specific version they recommend,
3371 but the latest @code{release} should be correct.
3372 We trust you to thoroughly test it with your implementation before you release it.
3373 If there are any issues with the current release,
3374 it's a bug that you should report upstream and that we will fix ASAP.
3376 As to how to include ASDF, we recommend the following:
3380 If ASDF isn't loaded yet, then @code{(require "asdf")}
3381 should load the version of ASDF that is bundled with your system.
3382 You may have it load some other version configured by the user,
3383 if you allow such configuration.
3386 If your system provides a mechanism to hook into @code{CL:REQUIRE},
3387 then it would be nice to add ASDF to this hook the same way that
3388 ABCL, CCL, CLISP, CMUCL, ECL, SBCL and SCL do it.
3391 You may, like SBCL, have ASDF be implicitly used to require systems
3392 that are bundled with your Lisp distribution.
3393 If you do have a few magic systems that come with your implementation
3394 in a precompiled way such that one should only use the binary version
3395 that goes with your distribution, like SBCL does,
3396 then you should add them in the beginning of @code{wrapping-source-registry}.
3399 If you have magic systems as above, like SBCL does,
3400 then we explicitly ask you to @emph{NOT} distribute
3401 @file{asdf.asd} as part of those magic systems.
3402 You should still include the file @file{asdf.lisp} in your source distribution
3403 and precompile it in your binary distribution,
3404 but @file{asdf.asd} if included at all,
3405 should be secluded from the magic systems,
3406 in a separate file hierarchy;
3407 alternatively, you may provide the system
3408 after renaming it and its @file{.asd} file to e.g.
3409 @code{asdf-ecl} and @file{asdf-ecl.asd}, or
3410 @code{sb-asdf} and @file{sb-asdf.asd}.
3411 Indeed, if you made @file{asdf.asd} a magic system,
3412 then users would no longer be able to upgrade ASDF using ASDF itself
3413 to some version of their preference that
3414 they maintain independently from your Lisp distribution.
3417 If you do not have any such magic systems, or have other non-magic systems
3418 that you want to bundle with your implementation,
3419 then you may add them to the @code{default-source-registry},
3420 and you are welcome to include @file{asdf.asd} amongst them.
3423 Please send us upstream any patches you make to ASDF itself,
3424 so we can merge them back in for the benefit of your users
3425 when they upgrade to the upstream version.
3431 @section Issues with configuring ASDF
3433 @subsection ``How can I customize where fasl files are stored?''
3435 @xref{Controlling where ASDF saves compiled files}.
3437 Note that in the past there was an add-on to ASDF called
3438 @code{ASDF-binary-locations}, developed by Gary King.
3439 That add-on has been merged into ASDF proper,
3440 then superseded by the @code{asdf-output-translations} facility.
3442 Note that use of @code{asdf-output-translations}
3443 can interfere with one aspect of your systems
3444 --- if your system uses @code{*load-truename*} to find files
3445 (e.g., if you have some data files stored with your program),
3446 then the relocation that this ASDF customization performs
3447 is likely to interfere.
3448 Use @code{asdf:system-relative-pathname} to locate a file
3449 in the source directory of some system, and
3450 use @code{asdf:apply-output-translations} to locate a file
3451 whose pathname has been translated by the facility.
3453 @subsection ``How can I wholly disable the compiler output cache?''
3455 To permanently disable the compiler output cache
3456 for all future runs of ASDF, you can:
3459 mkdir -p ~/.config/common-lisp/asdf-output-translations.conf.d/
3460 echo ':disable-cache' > ~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf
3463 This assumes that you didn't otherwise configure the ASDF files
3464 (if you did, edit them again),
3465 and don't somehow override the configuration at runtime
3466 with a shell variable (see below) or some other runtime command
3467 (e.g. some call to @code{asdf:initialize-output-translations}).
3469 To disable the compiler output cache in Lisp processes
3470 run by your current shell, try (assuming @code{bash} or @code{zsh})
3471 (on Unix and cygwin only):
3474 export ASDF_OUTPUT_TRANSLATIONS=/:
3477 To disable the compiler output cache just in the current Lisp process,
3478 use (after loading ASDF but before using it):
3481 (asdf:disable-output-translations)
3484 @section Issues with using and extending ASDF to define systems
3486 @subsection ``How can I cater for unit-testing in my system?''
3488 ASDF provides a predefined test operation, @code{test-op}.
3489 @xref{Predefined operations of ASDF, test-op}.
3490 The test operation, however, is largely left to the system definer to specify.
3491 @code{test-op} has been
3492 a topic of considerable discussion on the
3493 @url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list},
3495 @url{https://launchpad.net/asdf,launchpad bug-tracker}.
3497 Here are some guidelines:
3501 For a given system, @var{foo}, you will want to define a corresponding
3502 test system, such as @var{foo-test}. The reason that you will want this
3503 separate system is that ASDF does not out of the box supply components
3504 that are conditionally loaded. So if you want to have source files
3505 (with the test definitions) that will not be loaded except when testing,
3506 they should be put elsewhere.
3509 The @var{foo-test} system can be defined in an asd file of its own or
3510 together with @var{foo}. An aesthetic preference against cluttering up
3511 the filesystem with extra asd files should be balanced against the
3512 question of whether one might want to directly load @var{foo-test}.
3513 Typically one would not want to do this except in early stages of
3517 Record that testing is implemented by @var{foo-test}. For example:
3519 (defsystem @var{foo}
3520 :in-order-to ((test-op (test-op @var{foo-test})))
3523 (defsystem @var{foo-test}
3524 :depends-on (@var{foo} @var{my-test-library} ...)
3529 This procedure will allow you to support users who do not wish to
3530 install your test framework.
3532 One oddity of ASDF is that @code{operate} (@pxref{Operations,operate})
3533 does not return a value. So in current versions of ASDF there is no
3534 reliable programmatic means of determining whether or not a set of tests
3535 has passed, or which tests have failed. The user must simply read the
3536 console output. This limitation has been the subject of much
3539 @subsection ``How can I cater for documentation generation in my system?''
3541 The ASDF developers are currently working to add a @code{doc-op}
3542 to the set of predefined ASDF operations.
3543 @xref{Predefined operations of ASDF}.
3544 See also @url{https://bugs.launchpad.net/asdf/+bug/479470}.
3548 @subsection ``How can I maintain non-Lisp (e.g. C) source files?''
3550 See @code{cffi}'s @code{cffi-grovel}.
3552 @anchor{report-bugs}
3555 @subsection ``I want to put my module's files at the top level. How do I do this?''
3557 By default, the files contained in an asdf module go
3558 in a subdirectory with the same name as the module.
3559 However, this can be overridden by adding a @code{:pathname ""} argument
3560 to the module description.
3561 For example, here is how it could be done
3562 in the spatial-trees ASDF system definition for ASDF 2:
3565 (asdf:defsystem :spatial-trees
3571 (:file "basedefs" :depends-on ("package"))
3572 (:file "rectangles" :depends-on ("package"))))
3578 (:file "greene-trees" :depends-on ("r-trees"))
3579 (:file "rstar-trees" :depends-on ("r-trees"))
3580 (:file "rplus-trees" :depends-on ("r-trees"))
3581 (:file "x-trees" :depends-on ("r-trees" "rstar-trees"))))
3586 ((:static-file "spatial-tree-viz.lisp")))
3591 ((:static-file "spatial-tree-test.lisp")))
3592 (:static-file "LICENCE")
3593 (:static-file "TODO")))
3596 All of the files in the @code{tree-impls} module are at the top level,
3597 instead of in a @file{tree-impls/} subdirectory.
3599 Note that the argument to @code{:pathname} can be either a pathname object or a string.
3600 A pathname object can be constructed with the @file{#p"foo/bar/"} syntax,
3601 but this is discouraged because the results of parsing a namestring are not portable.
3602 A pathname can only be portably constructed with such syntax as
3603 @code{#.(make-pathname :directory '(:relative "foo" "bar"))},
3604 and similarly the current directory can only be portably specified as
3605 @code{#.(make-pathname :directory '(:relative))}.
3606 However, as of ASDF 2, you can portably use a string to denote a pathname.
3607 The string will be parsed as a @code{/}-separated path from the current directory,
3608 such that the empty string @code{""} denotes the current directory, and
3609 @code{"foo/bar"} (no trailing @code{/} required in the case of modules)
3610 portably denotes the same subdirectory as above.
3611 When files are specified, the last @code{/}-separated component is interpreted
3612 either as the name component of a pathname
3613 (if the component class specifies a pathname type),
3614 or as a name component plus optional dot-separated type component
3615 (if the component class doesn't specifies a pathname type).
3617 @subsection How do I create a system definition where all the source files have a .cl extension?
3619 Starting with ASDF 2.014.14, you may just pass
3620 the builtin class @code{cl-source-file.cl} as
3621 the @code{:default-component-class} argument to @code{defsystem}:
3624 (defsystem my-cl-system
3625 :default-component-class cl-source-file.cl
3629 Another builtin class @code{cl-source-file.lsp} is offered
3630 for files ending in @file{.lsp}.
3632 If you want to use a different extension
3633 for which ASDF doesn't provide builtin support,
3634 or want to support versions of ASDF
3635 earlier than 2.014.14 (but later than 2.000),
3636 you can define a class as follows:
3639 ;; Prologue: make sure we're using a sane package.
3640 (defpackage :my-asdf-extension
3641 (:use :asdf :common-lisp)
3642 (:export #:cl-source-file.lis))
3643 (in-package :my-asdf-extension)
3645 (defclass cl-source-file.lis (cl-source-file)
3646 ((type :initform "lis")))
3649 Then you can use it as follows:
3651 (defsystem my-cl-system
3652 :default-component-class my-asdf-extension:cl-source-file.lis
3656 Of course, if you're in the same package, e.g. in the same file,
3657 you won't need to use the package qualifier before @code{cl-source-file.lis}.
3658 Actually, if all you're doing is defining this class
3659 and using it in the same file without other fancy definitions,
3660 you might skip package complications:
3664 (defclass cl-source-file.lis (cl-source-file)
3665 ((type :initform "lis")))
3666 (defsystem my-cl-system
3667 :default-component-class cl-source-file.lis
3671 It is possible to achieve the same effect
3672 in a way that supports both ASDF 1 and ASDF 2,
3673 but really, friends don't let friends use ASDF 1.
3674 Please upgrade to ASDF 2.
3675 In short, though: do same as above, but
3676 @emph{before} you use the class in a @code{defsystem},
3677 you also define the following method:
3680 (defmethod source-file-type ((f cl-source-file.lis) (m module))
3681 (declare (ignorable f m))
3685 @comment FIXME: Add a FAQ about how to use a new system class...
3688 @node TODO list, Inspiration, FAQ, Top
3689 @comment node-name, next, previous, up
3692 Here is an old list of things to do,
3693 in addition to the bugs that are now tracked on launchpad:
3694 @url{https://launchpad.net/asdf}.
3696 @section Outstanding spec questions, things to add
3698 ** packaging systems
3700 *** manual page component?
3702 ** style guide for .asd files
3704 You should either use keywords or be careful
3705 with the package that you evaluate defsystem forms in.
3706 Otherwise @code{(defsystem partition ...)}
3707 being read in the @code{cl-user} package
3708 will intern a @code{cl-user:partition} symbol,
3709 which will then collide with the @code{partition:partition} symbol.
3711 Actually there's a hairier packages problem to think about too.
3712 @code{in-order-to} is not a keyword:
3713 if you read @code{defsystem} forms in a package that doesn't use ASDF,
3714 odd things might happen.
3717 ** extending defsystem with new options
3719 You might not want to write a whole parser,
3720 but just to add options to the existing syntax.
3721 Reinstate @code{parse-option} or something akin.
3724 ** document all the error classes
3726 ** what to do with compile-file failure
3728 Should check the primary return value from compile-file and see if
3729 that gets us any closer to a sensible error handling strategy
3733 lift unix-dso stuff from db-sockets
3737 A ``dry run'' of an operation can be made with the following form:
3740 (traverse (make-instance '<operation-name>)
3741 (find-system <system-name>)
3745 This uses unexported symbols.
3746 What would be a nice interface for this functionality?
3748 @section Missing bits in implementation
3750 ** reuse the same scratch package whenever a system is reloaded from disk
3752 ** proclamations probably aren't
3754 ** when a system is reloaded with fewer components than it previously had, odd things happen
3756 We should do something inventive when processing a @code{defsystem} form,
3757 like take the list of kids and @code{setf} the slot to @code{nil},
3758 then transfer children from old to new list as they're found.
3760 ** (stuff that might happen later)
3762 *** Propagation of the @code{:force} option.
3766 @code{(asdf:compile-system :araneida :force t)}
3768 also forces compilation of every other system the @code{:araneida} system depends on.
3769 This is rarely useful to me;
3770 usually, when I want to force recompilation of something more than a single source file,
3771 I want to recompile only one system.
3772 So it would be more useful to have @code{make-sub-operation}
3773 refuse to propagate @code{:force t} to other systems, and
3774 propagate only something like @code{:force :recursively}.
3776 Ideally what we actually want is some kind of criterion that says
3777 to which systems (and which operations) a @code{:force} switch will propagate.
3779 The problem is perhaps that ``force'' is a pretty meaningless concept.
3780 How obvious is it that @code{load :force t} should force @emph{compilation}?
3781 But we don't really have the right dependency setup
3782 for the user to compile @code{:force t} and expect it to work
3783 (files will not be loaded after compilation, so the compile
3784 environment for subsequent files will be emptier than it needs to be)
3786 What does the user actually want to do when he forces?
3787 Usually, for me, update for use with a new version of the Lisp compiler.
3788 Perhaps for recovery when he suspects that something has gone wrong.
3789 Or else when he's changed compilation options or configuration
3790 in some way that's not reflected in the dependency graph.
3792 Other possible interface: have a ``revert'' function akin to @code{make clean}.
3795 (asdf:revert 'asdf:compile-op 'araneida)
3798 would delete any files produced by @code{(compile-system :araneida)}.
3799 Of course, it wouldn't be able to do much about stuff in the image itself.
3801 How would this work?
3805 There's a difference between a module's dependencies (peers)
3806 and its components (children).
3807 Perhaps there's a similar difference in operations?
3808 For example, @code{(load "use") depends-on (load "macros")} is a peer,
3809 whereas @code{(load "use") depends-on (compile "use")}
3810 is more of a ``subservient'' relationship.
3812 @node Inspiration, Concept Index, TODO list, Top
3813 @comment node-name, next, previous, up
3814 @chapter Inspiration
3816 @section mk-defsystem (defsystem-3.x)
3818 We aim to solve basically the same problems as @code{mk-defsystem} does.
3819 However, our architecture for extensibility
3820 better exploits CL language features (and is documented),
3821 and we intend to be portable rather than just widely-ported.
3822 No slight on the @code{mk-defsystem} authors and maintainers is intended here;
3823 that implementation has the unenviable task
3824 of supporting pre-ANSI implementations, which is no longer necessary.
3826 The surface defsystem syntax of asdf is more-or-less compatible with
3827 @code{mk-defsystem}, except that we do not support
3828 the @code{source-foo} and @code{binary-foo} prefixes
3829 for separating source and binary files, and
3830 we advise the removal of all options to specify pathnames.
3832 The @code{mk-defsystem} code for topologically sorting
3833 a module's dependency list was very useful.
3835 @section defsystem-4 proposal
3837 Marco and Peter's proposal for defsystem 4 served as the driver for
3838 many of the features in here. Notable differences are:
3842 We don't specify output files or output file extensions
3843 as part of the system.
3845 If you want to find out what files an operation would create,
3849 We don't deal with CL packages
3851 If you want to compile in a particular package, use an @code{in-package} form
3852 in that file (ilisp / SLIME will like you more if you do this anyway)
3855 There is no proposal here that @code{defsystem} does version control.
3857 A system has a given version which can be used to check dependencies,
3861 The defsystem 4 proposal tends to look more at the external features,
3862 whereas this one centres on a protocol for system introspection.
3864 @section kmp's ``The Description of Large Systems'', MIT AI Memo 801
3866 Available in updated-for-CL form on the web at
3867 @url{http://nhplace.com/kent/Papers/Large-Systems.html}
3869 In our implementation we borrow kmp's overall @code{PROCESS-OPTIONS}
3870 and concept to deal with creating component trees
3871 from @code{defsystem} surface syntax.
3872 [ this is not true right now, though it used to be and
3873 probably will be again soon ]
3876 @c -------------------
3879 @node Concept Index, Function and Class Index, Inspiration, Top
3880 @unnumbered Concept Index
3884 @node Function and Class Index, Variable Index, Concept Index, Top
3885 @unnumbered Function and Class Index
3889 @node Variable Index, , Function and Class Index, Top
3890 @unnumbered Variable Index