pax_global_header 0000666 0000000 0000000 00000000064 13621551153 0014514 g ustar 00root root 0000000 0000000 52 comment=082f4ed4952dbca0216b92f48fe52280a82c65ae
asdf-3.3.4/ 0000775 0000000 0000000 00000000000 13621551153 0012440 5 ustar 00root root 0000000 0000000 asdf-3.3.4/.cl-source-registry.cache 0000664 0000000 0000000 00000000152 13621551153 0017243 0 ustar 00root root 0000000 0000000 (:source-registry-cache
"asdf.asd"
"uiop/asdf-driver.asd"
"uiop/uiop.asd"
"tools/asdf-tools.asd")
asdf-3.3.4/.gitattributes 0000664 0000000 0000000 00000000041 13621551153 0015326 0 ustar 00root root 0000000 0000000 ext export-ignore
* export-subst
asdf-3.3.4/.gitignore 0000664 0000000 0000000 00000002131 13621551153 0014425 0 ustar 00root root 0000000 0000000 ??
build
asdf.lisp
doc/cmucl/
doc/asdf/
doc/asdf.aux
doc/asdf.cp
doc/asdf.cps
doc/asdf.fn
doc/asdf.fns
doc/asdf.html
doc/asdf.info
doc/asdf.ky
doc/asdf.log
doc/asdf.pdf
doc/asdf.pg
doc/asdf.toc
doc/asdf.tps
doc/asdf.tp
doc/asdf.tps
doc/asdf.vr
doc/asdf.vrs
doc/asdf.t2d/
doc/asdf.dvi
doc/version.texinfo
doc/*.log
*.tmp
uiop/doc/uiop.html
uiop/doc/uiop.info
uiop/doc/uiop.pdf
uiop/doc/uiop.texinfo
LICENSE
README.html
tmp/
man/
lib/
*.dribble
*.fas[bcl]
*.fas
*.lib
*.[oahcisS]
*.*fsl
*.x86f
*.bak
*.data
*.ufasl
*.vbin
*.~*~
*.sse2f
test/try-reloading-dependency.asd
test/fileMissing.lisp
test/hello-world-example
test/test-include.asd
test/test-multiple-too.asd
build-stamp
# Although there is no debian subdir/ in this repo any more, the
# presence of these lines helps the debian package maintainers, so
# please leave them here.
debian/cl-asdf.debhelper.log
debian/cl-asdf.postinst.debhelper
debian/cl-asdf.prerm.debhelper
debian/cl-asdf.substvars
debian/cl-asdf/
debian/files
.pc
.DS_Store
core
# Hack: ignore the GNUmakefile here, so you can ln -s Makefile-lisp-scripting GNUmakefile
GNUmakefile
asdf-3.3.4/.gitmodules 0000664 0000000 0000000 00000002661 13621551153 0014622 0 ustar 00root root 0000000 0000000 [submodule "ext/fare-utils"]
path = ext/fare-utils
url = https://gitlab.common-lisp.net/frideau/fare-utils.git
[submodule "ext/fare-quasiquote"]
path = ext/fare-quasiquote
url = https://gitlab.common-lisp.net/frideau/fare-quasiquote.git
[submodule "ext/fare-mop"]
path = ext/fare-mop
url = https://gitlab.common-lisp.net/frideau/fare-mop.git
[submodule "ext/closer-closer-mop"]
path = ext/closer-closer-mop
url = https://github.com/pcostanza/closer-mop.git
[submodule "ext/alexandria"]
path = ext/alexandria
url = https://gitlab.common-lisp.net/alexandria/alexandria.git
[submodule "ext/optima"]
path = ext/optima
url = https://github.com/m2ym/optima.git
[submodule "ext/named-readtables"]
path = ext/named-readtables
url = https://github.com/melisgl/named-readtables.git
[submodule "ext/inferior-shell"]
path = ext/inferior-shell
url = https://gitlab.common-lisp.net/qitab/inferior-shell.git
[submodule "ext/lisp-invocation"]
path = ext/lisp-invocation
url = https://gitlab.common-lisp.net/qitab/lisp-invocation.git
[submodule "ext/cl-ppcre"]
path = ext/cl-ppcre
url = https://github.com/edicl/cl-ppcre
[submodule "ext/asdf-encodings"]
path = ext/asdf-encodings
url = https://gitlab.common-lisp.net/asdf/asdf-encodings.git
[submodule "ext/cl-scripting"]
path = ext/cl-scripting
url = https://github.com/fare/cl-scripting.git
[submodule "ext/cl-launch"]
path = ext/cl-launch
url = https://gitlab.common-lisp.net/xcvb/cl-launch.git
asdf-3.3.4/Makefile 0000664 0000000 0000000 00000025152 13621551153 0014105 0 ustar 00root root 0000000 0000000 # Configuring this Makefile for your personal use:
# Set environment variable ASDF_TEST_LISPS to a space-separated list of values
# (see "defaultlisps" below, for an example).
# If you have a special way to find libraries that are used in the build and
# test process, you may bind ASDF_DEVEL_SOURCE_REGISTRY to a source registry to
# use (using the environment variable syntax), or bind it to "override" to use
# your normal CL source registry. Otherwise, it will use local copies of
# everything.
system := "asdf"
webhome_private := common-lisp.net:/project/asdf/public_html/
webhome_public := "http://common-lisp.net/project/asdf/"
clnet_home := "/project/asdf/public_html/"
sourceDirectory := $(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))
#### Common Lisp implementations available for testing.
## export ASDF_TEST_LISPS to override the default list of such implementations,
## or specify a lisps= argument at the make command-line
defaultLisps = ccl clisp sbcl ecl ecl_bytecodes cmucl abcl scl allegro lispworks allegromodern gcl xcl mkcl
ifdef ASDF_TEST_LISPS
lisps ?= ${ASDF_TEST_LISPS}
else
lisps ?= ${defaultLisps}
endif
ifdef ASDF_UPGRADE_TEST_LISPS
ulisps ?= ${ASDF_UPGRADE_TEST_LISPS}
else
ifdef ASDF_TEST_LISPS
ulisps ?= ${ASDF_TEST_LISPS}
else
ulisps ?= ${defaultLisps}
endif
endif
version := $(shell cat "version.lisp-expr")
#$(info $$version is [${version}])
version := $(patsubst "%",%,$(version))
#$(info $$version is [${version}])
fullversion := $(shell git describe --tags --match "[0-9][.][0-9]*" 2> /dev/null || echo $(version))
## grep for #+/#- features in the test/ directory to see plenty of disabled tests on some platforms
## NOT SUPPORTED BY OUR AUTOMATED TESTS:
## cormancl genera lispworks-personal-edition rmcl
## Some are manually tested once in a while.
ifdef ASDF_TEST_SYSTEMS
s ?= ${ASDF_TEST_SYSTEMS}
endif
ifdef ASDF_DEVEL_SOURCE_REGISTRY
ifeq ($(ASDF_DEVEL_SOURCE_REGISTRY), override)
# do nothing... Use the user's CL_SOURCE_REGISTRY
else
export CL_SOURCE_REGISTRY = ${ASDF_DEVEL_SOURCE_REGISTRY}
endif
else # no ASDF_DEVEL_SOURCE_REGISTRY
export CL_SOURCE_REGISTRY = ${sourceDirectory}/:${sourceDirectory}/uiop/:${sourceDirectory}/ext//
endif
#$(error "CL_SOURCE_REGISTRY is ${CL_SOURCE_REGISTRY}")
sys := $(shell uname -s)
ifneq (,$(findstring CYGWIN,$(sys)))
CL_SOURCE_REGISTRY := $(shell cygpath -pw "${CL_SOURCE_REGISTRY}")
endif
l ?= sbcl
ABCL ?= abcl
ALLEGRO ?= alisp
ALLEGROMODERN ?= mlisp
CCL ?= ccl
CLISP ?= clisp
CMUCL ?= cmucl
ECL ?= ecl
GCL ?= gcl
LISPWORKS ?= lispworks
MKCL ?= mkcl
SBCL ?= sbcl
SCL ?= scl
XCL ?= xcl
header_lisp := header.lisp
driver_lisp := uiop/package.lisp uiop/common-lisp.lisp uiop/utility.lisp uiop/version.lisp uiop/os.lisp uiop/pathname.lisp uiop/filesystem.lisp uiop/stream.lisp uiop/image.lisp uiop/lisp-build.lisp uiop/launch-program.lisp uiop/run-program.lisp uiop/configuration.lisp uiop/backward-driver.lisp uiop/driver.lisp
defsystem_lisp := upgrade.lisp session.lisp component.lisp operation.lisp system.lisp system-registry.lisp action.lisp lisp-action.lisp find-component.lisp forcing.lisp plan.lisp operate.lisp find-system.lisp parse-defsystem.lisp bundle.lisp concatenate-source.lisp package-inferred-system.lisp output-translations.lisp source-registry.lisp backward-internals.lisp backward-interface.lisp interface.lisp user.lisp footer.lisp
all_lisp := $(header_lisp) $(driver_lisp) $(defsystem_lisp)
print-% : ; @echo $* = $($*)
# Making ASDF itself should be our first, default, target:
build/asdf.lisp: $(all_lisp)
mkdir -p build
rm -f $@
cat $(all_lisp) > $@
ext:
git submodule update --init
noext:
git submodule deinit .
# This quickly locates such mistakes as unbalanced parentheses:
load: build/asdf.lisp
./test/run-tests.sh -t $l $(all_lisp)
install: archive
bump: bump-version
git commit -a -m "Bump version to $$(eval a=$$(cat version.lisp-expr) ; echo $$a)"
temp=$$(cat version.lisp-expr); temp="$${temp%\"}"; temp="$${temp#\"}"; git tag $$temp
bump-version: build/asdf.lisp
./bin/bump-version ${v}
driver-files:
@echo $(driver_lisp)
defsystem-files:
@echo $(defsystem_lisp)
# FIXME: needs rewrite
#archive: build/asdf.lisp
# ./bin/asdf-builder make-and-publish-archive
archive: build/asdf.lisp
$(eval UIOPDIR := "uiop-$(version)")
mkdir -p build/$(UIOPDIR) # UIOP tarball
cp -pHux uiop/README.md uiop/uiop.asd uiop/asdf-driver.asd ${driver_lisp} uiop/contrib/debug.lisp build/$(UIOPDIR)
tar zcf "build/uiop-${version}.tar.gz" -C build $(UIOPDIR)
rm -r build/$(UIOPDIR)
$(eval ASDFDIR := "asdf-$(version)")
mkdir -p build/$(ASDFDIR) # asdf-defsystem tarball
cp -pHux build/asdf.lisp asdf.asd version.lisp-expr header.lisp README.md ${defsystem_lisp} build/$(ASDFDIR)
tar zcf "build/asdf-defsystem-${version}.tar.gz" -C build $(ASDFDIR)
rm -r build/$(ASDFDIR)
git archive --worktree-attributes --prefix="asdf-$(version)/" --format=tar -o "build/asdf-${version}.tar" ${version} #asdf-all tarball
gzip "build/asdf-${version}.tar"
cp "build/asdf.lisp" "build/asdf-${version}.lisp"
publish-archive:
rsync --times --chmod=a+rX,ug+w "build/uiop-${version}.tar.gz" "build/asdf-defsystem-${version}.tar.gz" \
"build/asdf-${version}.tar.gz" "build/asdf-${version}.lisp" common-lisp.net:/project/asdf/public_html/archives/
ssh common-lisp.net "cd /project/asdf/public_html/archives/; ln -sf uiop-${version}.tar.gz uiop.tar.gz; ln -sf asdf-defsystem-${version}.tar.gz asdf-defsystem.tar.gz; ln -sf asdf-${version}.tar.gz asdf.tar.gz; ln -sf asdf-${version}.lisp asdf.lisp"
### Count lines separately for asdf-driver and asdf itself:
wc:
@wc $(driver_lisp) | sort -n ; echo ; \
wc $(header_lisp) $(defsystem_lisp) | sort -n ; \
echo ; \
wc $(header_lisp) $(driver_lisp) $(defsystem_lisp) | tail -n 1
push:
git status
git push --tags cl.net release master
git push --tags github release master
git fetch
git status
# doc:
# ${MAKE} -C doc
# don't have the toolchain to build docs installed...
doc: ;
website:
${MAKE} -C doc website
${MAKE} -C uiop/doc website
clean_dirs = $(sourceDirectory)
clean_extensions = fasl dfsl cfsl fasl fas lib dx32fsl lx64fsl lx32fsl ufasl o bak x86f vbin amd64f sparcf sparc64f hpf hp64f
clean:
@for dir in $(clean_dirs); do \
if test -d $$dir; then \
echo Cleaning $$dir; \
for ext in $(clean_extensions); do \
find $$dir \( -name "*.$$ext" \) \
-and -not -path \""*/.git/*"\" \
-and -not -path \""*/_darcs/*"\" \
-and -not -path \""*/tags/*"\" -delete; \
done; \
fi; \
echo "Cleaned $$dir"; \
done
echo "Done with cleaning loop."
rm -rf build/ LICENSE test/try-reloading-dependency.asd test/hello-world-example asdf.lisp
rm -rf test/hello-world-example.exe test/mkcl_*.dll # needed only on MS-Windows
${MAKE} -C doc clean
${MAKE} -C uiop/doc clean
mrproper:
git clean -xfd
test-upgrade: build/asdf.lisp show-version
./test/run-tests.sh -u ${l}
u: test-upgrade
test-clean-load: build/asdf.lisp show-version
./test/run-tests.sh -c ${l}
show-version:
@echo "Building and testing asdf $(fullversion)"
# test-glob has been replaced by t, and lisp by l, easier to type
test-lisp: build/asdf.lisp show-version
@cd test; ./run-tests.sh ${l} ${t}
t: test-lisp
test: doc test-lisp test-clean-load test-load-systems
test-load-systems: build/asdf.lisp show-version
./test/run-tests.sh -l ${l} ${s}
test-all-lisps: test-load-systems test-all-clean-load test-all-lisp test-all-upgrade
test-all-clean-load:
@for lisp in ${lisps} ; do ${MAKE} test-clean-load l=$$lisp || exit 1 ; done
test-all-lisp:
@for lisp in ${lisps} ; do ${MAKE} test-lisp l=$$lisp || exit 1 ; done
test-all-upgrade:
@for lisp in ${ulisps} ; do ${MAKE} test-upgrade l=$$lisp || exit 1 ; done
test-all-no-upgrade: doc test-load-systems test-all-clean-load test-all-lisp
test-all: test-all-no-upgrade test-all-upgrade
test-all-lisp-no-stop:
@for lisp in ${lisps} ; do ${MAKE} test-lisp l=$$lisp ; done ; :
test-all-upgrade-no-stop:
@for lisp in ${ulisps} ; do ${MAKE} test-upgrade l=$$lisp ; done ; :
test-all-no-upgrade-no-stop: doc test-load-systems test-all-clean-load test-all-lisp-no-stop
make --quiet check-all-test-results
test-all-no-stop: doc test-load-systems test-all-clean-load test-all-lisp-no-stop test-all-upgrade-no-stop
make --quiet check-all-results
check-all-test-results:
@A="`grep -L '[5-9][0-9] passing and 0 failing' build/results/*-test.text`" ; \
if [ -n "$$A" ] ; then \
echo "Unexpected test failures on these implementations:" ; \
echo "$$A" ; \
exit 1 ; \
fi
check-all-upgrade-results:
@A="`grep -L 'Upgrade test succeeded for ' build/results/*-upgrade.text`" ; \
if [ -n "$$A" ] ; then \
echo "Unexpected upgrade failures on these implementations:" ; \
echo "$$A" ; \
exit 1 ; \
fi
check-all-results:
@r=0 ; \
make --quiet check-all-test-results || r=1 ; \
make --quiet check-all-upgrade-results || r=1 ; \
exit $r
extract: extract-all-tagged-asdf
extract-all-tagged-asdf: build/asdf.lisp
./test/run-tests.sh -H
# Delete wrongful tags from local repository
fix-local-git-tags:
for i in ${WRONGFUL_TAGS} ; do git tag -d $$i ; done
# Delete wrongful tags from remote repository
fix-remote-git-tags:
for i in ${WRONGFUL_TAGS} ; do git push $${REMOTE:-cl.net} :refs/tags/$$i ; done
release-push:
git checkout master
git merge release
git checkout release
git merge master
git checkout master
TODO:
exit 2
release: TODO test-all test-on-other-machines-too debian-changelog debian-package send-mail-to-mailing-lists
.PHONY: install archive push doc website clean mrproper show-version \
test-forward-references test test-lisp test-upgrade test-forward-references \
test-all test-all-lisps test-all-no-upgrade \
debian-package release \
replace-sbcl-asdf replace-ccl-asdf \
fix-local-git-tags fix-remote-git-tags wc wc-driver wc-asdf \
list-source-registry \
ext noext
# debug the source registry that will be used to execute commands from this Makefile.
#list-source-registry:
# ${sourceDirectory}/bin/asdf-builder re '(uiop:writeln (sort (alexandria:hash-table-alist asdf::*source-registry*) `string< :key `car))'
# RELEASE or PUSH checklist:
# make test-all
# make test-load-systems s=fare-all
# make bump v=3.0
# edit debian/changelog # RELEASE only...
# git commit
# git tag 3.0 # for example ...
# make debian-package
# git push
# git push origin 3.0 # for example...
# everything from here for RELEASE only
# make release-push archive website debian-package
# dput mentors ../*.changes
# send debian mentors request
# send announcement to asdf-announce, asdf-devel, etc.
# Move all fixed bugs from Fix Committed -> Fix Released on launchpad
#
## Users don't release as above, only maintainers do.
## Users, all you need to do is: make
## Vendors, you may want to test your implementation with: make test l=sbcl
asdf-3.3.4/Makefile-lisp-scripting 0000664 0000000 0000000 00000010600 13621551153 0017042 0 ustar 00root root 0000000 0000000 # -*- Makefile -*- This minimal Makefile delegates most work to the asdf-tools script
#
# End-Users, all you need to do is:
# make -f Makefile-lisp-scripting
#
# Vendors, you may want to test your implementation with:
# make -f Makefile-lisp-scripting test l=sbcl
# BUT you first need have installed the development-time external dependencies of ASDF;
# this will be done automatically if you are using quicklisp;
# you can do it manually with your favorite tools (e.g. clbuild or git);
# or you can do it using `git submodule update` which is also available as:
# make -f Makefile-lisp-scripting ext
# To undo the `git submodule update` you can use: `make noext`
#
# Other targets are for maintainer use only. If you want a list of all of the targets, use
# make -f Makefile-lisp-scripting help
#
### Default fall back rule: delegate to asdf-tools.
# Note that the l= L= etc. are the only way I (Faré) have found to
# pass arguments from the Makefile to the underlying script:
# l= overrides $ASDF_TEST_LISPS to specify which lisp implementations to use
# L= overrides $ASDF_UPGRADE_TEST_LISPS (defaults to the former) to lisps during upgrade
# s= overrides $ASDF_TEST_SYSTEMS to specify systems with which to test ASDF
# t= overrides $ASDF_TESTS to specify test script patterns to use (default to *.script)
# u= overrides $ASDF_UPGRADE_TEST_TAGS to specify versions to upgrade from (e.g. 3.0.3 or REQUIRE)
# U= overrides $ASDF_UPGRADE_TEST_METHODS to specify upgrade methods
# v= overrides the default next version for bump-version or bump.
# see in tools/test-environment.lisp for details.
# Note that because of how make and the shell quote arguments,
# thou shalt not use the single-quote character in any of the short x= parameters
# (but you may use them in the long variant in the exported environment variable).
# To have a list of commands, see make help or ./tools/asdf-tools help
# Note that when you call ./tools/asdf-tools directly,
# you may have to use positional parameters instead (unless you use env as below), as in
# ./tools/asdf-tools bump 3.2.1
# instead of
# make -f Makefile-lisp-scripting bump v=3.2.1
# or
# ./make-asdf.sh v=3.2.1 bump
# or
# ./tools/asdf-tools env v=3.2.1 bump
# or
# v=3.2.1 ./tools/asdf-tools bump
ifeq ($(OS),Windows_NT)
MAKE_SCRIPT := cmd /c make-asdf.bat
else
MAKE_SCRIPT := ./make-asdf.sh
endif
all ext noext driver_files defsystem_files build_asdf build_asdf_tools: force
${MAKE_SCRIPT} $@
build/asdf.lisp: build_asdf
build/asdf-tools build/asdf-tools.exe: build_asdf_tools
.PHONY: force all ext noext driver_files defsystem_files build_asdf build_asdf_tools
# The text below was automaticaly generated by
# make -f Makefile-lisp-scripting --silent makefile-targets
# then manually inserted here to provide for completion:
.PHONY: archive build-asdf build-asdf-tools bump bump-version check-all-results check-all-scripts-results check-all-upgrade-results clean debian-package doc ext-clear ext-init ext-reset ext-update extract extract-all-tagged-asdf extract-tagged-asdf fix-local-git-tags fix-remote-git-tags git-all-committed-p help install install-asdf link-archive load make-and-publish-archive make-archive makefile-targets merge-master-into-release publish-archive publish-debian-package push re show-commands show-version t test test-all test-all-basic test-all-clean-load test-all-no-stop test-all-no-upgrade test-all-no-upgrade-no-stop test-all-scripts test-all-scripts-no-stop test-all-upgrade test-all-upgrade-no-stop test-ascii test-basic test-clean-load test-load-systems test-scripts test-upgrade u wc website
archive build-asdf build-asdf-tools bump bump-version check-all-results check-all-scripts-results check-all-upgrade-results clean debian-package doc ext-clear ext-init ext-reset ext-update extract extract-all-tagged-asdf extract-tagged-asdf fix-local-git-tags fix-remote-git-tags git-all-committed-p help install install-asdf link-archive load make-and-publish-archive make-archive makefile-targets merge-master-into-release publish-archive publish-debian-package push re show-commands show-version t test test-all test-all-basic test-all-clean-load test-all-no-stop test-all-no-upgrade test-all-no-upgrade-no-stop test-all-scripts test-all-scripts-no-stop test-all-upgrade test-all-upgrade-no-stop test-ascii test-basic test-clean-load test-load-systems test-scripts test-upgrade u wc website: force
${MAKE_SCRIPT} l='$l' L='$L' u='$u' U='$U' v='$v' s='$s' t='$t' $@
asdf-3.3.4/README.md 0000664 0000000 0000000 00000030173 13621551153 0013723 0 ustar 00root root 0000000 0000000 ASDF: Another System Definition Facility
========================================
For general information about ASDF, consult the web page:
For some reference documentation, read the manual:
For a guide on how to use it, read our "best practices" document:
Below is a guide for ASDF developers. It is not meant for ASDF users.
[TOC]
Building ASDF
-------------
First, make sure ASDF is checked out under a path registered to the source-registry,
if that isn't the case yet (see the [manual](http://common-lisp.net/project/asdf/asdf.html)).
One place would be:
~/.local/share/common-lisp/source/asdf/
or, assuming your implementation provides ASDF 3.1 or later:
~/common-lisp/asdf/
If you cloned our git repository rather than extracted a tarball,
bootstrap a copy of `build/asdf.lisp` with:
make
Building the documentation
--------------------------
The manual is also in the [doc/](doc/) subdirectory, and can be prepared with:
make -C doc
Testing ASDF
------------
Before you may run tests, you need a few CL libraries.
The simplest way to get them is as follows, but read below:
make ext
_NOTA BENE_: You may also need to run `make ext` again
after you `git pull` or switch branch, to update the `ext/` directory.
This unhappily is not automatic.
If for some reason tests fail, particularly due to an error
compiling, loading or running a library, then run `make ext` and try again.
The above `make` target uses `git submodule update --init` to download
all these libraries using git. If you don't otherwise maintain your
own set of carefully controlled CL libraries, that's what you want to use.
However, it is only available if you have a git checkout of ASDF;
not if you used a tarball.
If you use a tarball or otherwise do maintain your own set
of carefully controlled CL libraries then you will want to use whichever tools
you use (e.g. `quicklisp`, `clbuild`, or your own scripts around `git`)
to download these libraries:
`alexandria`, `asdf-encodings`, `cl-launch`, `closer-mop`, `cl-ppcre`,
`cl-scripting`, `fare-mop`, `fare-quasiquote`, `fare-utils`, `inferior-shell`,
`lisp-invocation`, `named-readtables`, `optima`.
If you are a CL developer, you may already have them, or may want
to use your own tools to download a version of them you control.
If you use [Quicklisp](https://www.quicklisp.org/), you may let
Quicklisp download those you don't have.
In these cases, you may NOT want to use the git submodules from `make ext`;
you may undo a `make ext` with `make noext`.
Otherwise, if you want to let ASDF download known-working versions
of its dependencies, you can do it with `make ext`.
Once you have all the required libraries and the asdf-tools script can find
a suitable Common Lisp implementation, you may run all the tests
on a given Common Lisp implementation `$L`, with your favorite installed system `$S`, using:
make t u l=$L s=$S
To run only the regression test scripts, try simply:
make l=$L test-scripts
Lisp Scripting test system
--------------------------
ASDF by default uses a shell script in `./test/run-tests.sh` to run the scripts
that orchestrate its tests.
An alternate build and test system is available
that uses Common Lisp as a scripting language.
It is disabled by default because
the new maintainer is having trouble with it in some of his environments.
It worked fine for the previous maintainer in his environments,
and may be particularly useful on Windows if and when
the shell-based test system fails or is not available.
Its source code is in [tools/](tools/) and
you can invoke it without going through GNU make,
using the script [make-asdf.sh](make-asdf.sh),
or, on Windows, [make-asdf.bat](make-asdf.bat).
To use this alternate test system, pass to `make` the extra arguments `-f Makefile-lisp-scripting`
as in for instance:
make -f Makefile-lisp-scripting t l=sbcl
Or you can make that your local default (assuming GNU make) using:
echo "include Makefile-lisp-scripting" > GNUmakefile
These Lisp tools by default use Clozure Common Lisp (CCL) to build and run a binary
`build/asdf-tools` that will orchestrate the tests.
By defining and exporting the variable `LISP` to be one of `ccl`, `sbcl` or `allegro`, you
can have it use an alternate Common Lisp implementation instead.
Install CCL (respectively SBCL or Allegro) and make sure an executable called
`ccl` (respectively `sbcl` or `alisp`) is in your `PATH`,
or that you export a variable `CCL` (respectively `SBCL` or `ALLEGRO`)
that points to the executable.
To use a further Common Lisp implementation, suitably edit the script
[`tools/asdf-tools`](tools/asdf-tools),
or, on Windows, the batch file [`tools/asdf-tools.bat`](tools/asdf-tools.bat).
(Note that we recommend SBCL 1.3.13 or later when on Windows.)
Note that the executable `build/asdf-tools` is built
the first time you test ASDF.
When you update ASDF, via e.g. `git pull` or a branch switch,
you may have to update it, with:
make -f Makefile-lisp-scripting build-asdf-tools
The reason this is not done automatically every time is because
building it depends on a working ASDF;
but when you're modifying ASDF and testing it, you cannot rely on a working ASDF:
indeed, a developer may not only make mistakes, but may deliberately
introduce or re-introduce bugs at some place to test code in another place.
Debugging ASDF
--------------
To interactively debug ASDF, you may load it in such a way that `M-.` will work,
by installing the source code, and running:
(map () 'load (asdf:input-files :monolithic-concatenate-source-op "asdf/defsystem"))
To interactively use the `asdf-tools`, you need to either have
all its dependencies installed and configured.
If you're using them through the `ext/` directory and `make ext`,
then you may need to emulate
what the script in [tools/asdf-tools](tools/asdf-tools) does
with respect to initializing the source-registry.
Note that it also declares a system for `cl-launch/dispatch`;
you can either do something similar, or expand the source for `cl-launch` with
`make -C ext/cl-launch source` so `cl-launch.asd` will be created.
Using ASDF internals
--------------------
If you have to use or extend internal functionality not currently exported by
ASDF, please contact us and have us negotiate a proper, stable, tested interface
that you can actually rely on. Also, please *DO NOT* refer to specific
subpackages such as `asdf/find-system` from the outside of ASDF, because
functions may occasionally be moved from one internal package to the other,
without notification. They have in the past and will in the future.
Instead, when refering to symbols in ASDF, we recommend you either have
your package `:use` the package `:asdf` or `:import-from` it, or that
you shall use `asdf:` or `asdf::` as a prefix to the symbols.
And once again, please contact us if you have to use non-exported symbols.
Also, the normal way of extending ASDF is to use our class hierarchies for
`component` and `operation` and to define methods on `component-depends-on`,
`perform`, `input-files`, `output-files`.
A common mistake seems to be that some people define methods on `operate`,
which usually is not at all what they think it is.
How do I navigate this source tree?
-----------------------------------
* [asdf.asd](asdf.asd)
* The system definition for building ASDF with ASDF.
* `*.lisp`
* The source code files for `asdf/defsystem`.
See [asdf.asd](asdf.asd) for the order in which they are loaded.
All exported functions should have docstrings,
and all internal functions should have comments.
If any definition is insufficiently documented,
please tell us: that's a bug.
* [uiop/](uiop/)
* Utilities of Implementation- and OS- Portability,
the portability layer of ASDF. It has its own [README](uiop/README.md),
and exported functions should all have docstrings and other ones comment,
or once again it's a bug.
* [Makefile](Makefile)
* The classical `Makefile` used for development purposes.
Regular users only need to call `make` with the default target.
Developers will typically use the like of
`make t l=sbcl` or `make u l=ccl`.
* [bin/](bin/)
* [bump-version](bin/bump-version) --
a script to bump the version of ASDF, used by the classic `Makefile`.
Use it with e.g. `./bin/bump-version 3.4.5`
to test with the next version number before you release.
NB: ASDF's version number notably affects the behavior of ASDF
with respect to deprecated functions.
* [tools/](tools/)
* `asdf-tools`, a system to build, test and release ASDF. It includes:
* [asdf-tools](tools/asdf-tools) --
a shell script to run it as a shell command.
* [asdf-tools.bat](tools/asdf-tools.bat) --
a Windows batch file to run the above.
* [asdf-tools.asd](tools/asdf-tools.asd) --
system definition for asdf-tools
* `*.lisp` -- the source code for the `asdf-tools` system,
except for the few files below.
Check the `.asd` file for the order in which to read them.
* Also a couple scripts to help ASDF users:
* [load-asdf.lisp](tools/load-asdf.lisp) --
a working example script to load, configure and use ASDF
in a self-contained project
* [install-asdf.lisp](install-asdf.lisp) --
replace and update an implementation's ASDF
* [cl-source-registry-cache.lisp](cl-source-registry-cache.lisp) --
update a cache for the source-registry as a standalone script.
* [Makefile-lisp-scripting](Makefile-lisp-scripting),
[make-asdf.sh](make-asdf.sh) and [make-asdf.bat](make-asdf.bat)
* Minimal Makefile and scripts to invoke
the lisp scripting variants of the build system.
* [version.lisp-expr](version.lisp-expr)
* The current version. Bumped up every time the code changes, using:
make bump
* [doc/](doc/)
* Documentation for ASDF, including:
* [index.html](doc/index.html) --
the web page for
* [asdf.texinfo](doc/asdf.texinfo) -- our manual
* [Makefile](doc/Makefile) -- how to build the manual
* [cclan.png](doc/cclan.png) [lisp-logo120x80.png](doc/lisp-logo120x80.png)
[style.css](doc/style.css) [favicon.ico](doc/favicon.ico)
-- auxiliaries of [index.html](doc/index.html)
* [test/](test/)
* Regression test scripts (and ancillary files) for developers to check
that they don't unintentionally break any of the functionality of ASDF.
They are far from covering all of ASDF, but they are a good start.
* [script-support.lisp](test/script-support.lisp) --
the common test infrastructure used by our tests
* [run-tests.sh](test/run-tests.sh) --
the shell script used by the classic `Makefile` to run tests.
It is not used by the Lisp scripting variant of the `Makefile`.
* [contrib/](contrib/)
* A few contributed files that show case how to use ASDF
or help with debugging it or debugging programs that use it.
* [debian/](debian/)
* Files for packaging on Debian, Ubuntu, etc.
(now only present in the debian branch).
* [build/](build/)
* Where the `Makefile` and `asdf-tools` store their output files,
including:
* `asdf.lisp` -- the current one-file deliverable of ASDF
* `asdf-*.lisp` -- for upgrade test purposes, old versions
* `asdf-tools` -- the executable for asdf-tools (.exe on Windows)
* `results/` -- logs of tests that have been run
* `fasls/` -- output files while running tests
* [ext/](ext/)
* External dependencies, that can be populated with `make ext`
or equivalently with `git submodule update --init`.
Depopulate it with `make noext`
or equivalently with: `submodule deinit .`
* [README.md](README.md)
* This file.
* [TODO](TODO)
* Plenty of ideas for how to further improve ASDF
(not all of them guaranteed good ideas.)
asdf-3.3.4/TODO 0000664 0000000 0000000 00000077537 13621551153 0013153 0 ustar 00root root 0000000 0000000 * Decree that versions older than 2 years are not supported;
yet, keep supporting an upgrade from whatever vendors provide
— so push them to provide recent stuff.
** Already, swank-asdf doesn't support anything older than 2.014.6
(as provided by the first 2011 iteration of Quicklisp), and
I (fare) am pushing for swank-asdf to not support anything older
than 3.1.2 (since no maintained implementation has anything older,
with the LispWorks 7.0 release being last to upgrade, in May 2015;
or CLISP hg in May 2016, though it hasn't been released since 2010).
** Maybe remove old versions from upgrade tests; or maybe not:
if we support old versions in any way,
it should be for upgrade only, and "punt" is acceptable.
** Upgrade tests might be split in two test sets: short and long.
** Make tests stateless and/or make any modifications private,
so that they can be run in parallel.
* Have a better story for linking C static or dynamic libraries.
** Some groundwork has been done in cffi-toolchain, but an interface must be designed.
** Then you'll have to migrate all the code in Quicklisp to use your new interface.
** See commonqt's qt.asd and qtools's qt-libs.asd for instances of ugliness.
* Testing support
** Replace test-op with run-test-op and test-report-op ?
* Implement a style-checker, that will issue STYLE-WARNINGs
when you don't follow all the recommended guidelines.
* Moving toward cross-compilation (ASDF 3.4? 4?)
This would allow to get most of the benefits of XCVB
(reproducibility, scalability, applicability to mobile platforms, etc.),
except without the backward incompatibility of XCVB.
NB: the MOCL author would benefit a lot, and might chip in.
** Need to further split asdf:perform in two parts:
A part that runs on the host and specifies (as SEXP or string to read)
forms that must be evaluated on the target machine, not the host:
(asdf:perform-forms target operation component &key input-files output-files)
The default implementation can fallback to running the
(asdf:perform operation component) on the target.
To ensure isolation, it would run in an isolated process in which
just the specially crafted operation and component objects are defined,
though the defsystem-depends-on dependencies are also loaded;
the action would be run in a temporary directory, that would contain
only a read-only copy of the declared input-files, and some writable
output directory for the output files, that would afterwards be
copied to their actual destination.
;; null means the target is the current host.
;; Or should the base class be plan-traversal or such?
(defmethod perform-form ((target null) operation component)
;; :host means execute on the host. () is empty options.
`(:host () (asdf:perform ',op ',comp)))
;; external-target means a cross compiler that we spawn.
(defmethod perform-form ((target external-target) operation component)
`(:target ;; who is to execute that? the target Lisp.
;; options for the performing system:
(:depends-on ,(defsystem-dependencies
(component-system component)))
;; The actual forms to evaluate
(asdf:perform ,(fake-operation-form operation)
,(fake-component-form component))))
By specifying :host-common-lisp you can have forms run on the host.
By specifying :run-program, you can spawn a subprocess without
having to first spawn a Lisp that will call run-program. etc.
The other way around the default perform method could be:
(defmethod perform ((o t) (c t))
(let ((forms (perform-forms nil o c)))
(if (equal forms
`((asdf:perform ',o ',c)))
(error "Missing perform method on ..." ...)
(map () 'eval-thunk forms))))
Note that in the general case, there are multiple forms,
that must be provided on the command line somehow
(see the lisp-invocation system and also how cl-launch does it),
with packages necessary to read latter forms being
created by former forms, so you cannot read everything in one go.
ASDF or at least UIOP should probably be provided in the target
image by default, anyway, without needing to be explicitly specified.
A more declarative interface to needing the defsystem-deps
is probably useful.
** A real cross-compiling backend that works the way of XCVB
would need to compute a complete graph for the plan,
which could be achieved by inheriting from the code in POIU.
Thinking about it, the cross-compiling target object
could actually be the same as the plan object.
The basic case of in-image execution would need to be in ASDF,
while the actual cross-compilation case would be in an extension.
** Audit all the current specializers of perform, and offer them a new way;
they can keep the perform method to run on older versions of ASDF.
** Modify SBCL and other implementations so they provide UIOP
independently from ASDF?
** The default perform-plan method could iterate over pre-computed forms,
in a way that does not involve the ASDF object model anymore,
making ASDF friendlier to self-upgrades.
Then, ASDF wouldn't need to be concatenated during upgrade
— but should still concatenate for bootstrap purposes,
when require'ing it as an implementation-provided module,
compiling from ASDF 2, or otherwise distributing as a single file.
* Implementation bugs
** CMUCL has bugs:
*** In ASDF 2.32.13, sibling-dependencies is renamed to sideway-dependencies
in defclass component, a superclass of system, and upgrade from
2.32 or earlier thus fails with
Error in function KERNEL:CLASS-TYPEP: Class is currently invalid:
#
in a direct call from ASDF/FIND-SYSTEM:LOCATE-SYSTEM,
which suggests CMUCL's PCL fails to finalize classes properly.
*** Non-default optimize settings may or may not subtly break PCL.
For the longest time (from 2.26.136 to 3.1.0.42), ASDF had:
(declaim (optimize (speed 1) (safety 3) (debug 3)))
This form may or may not work around that breakage in some cases:
(setf c::top-level-lambda-max 0)
*** At some point there was massive breakage due to uninitialized slots
as revealed in 3.1.0.37 with
make t l=cmucl t=test-encodings.script
which was a different PCL bug from the above (without same workaround)
but possibly also triggered by the non-standard declaim.
*** `#5(1 ,@\`(2 3)))` returns `#(1 2 3)`,
rather than `#(1 2 3 2 3 2 3 2 3)` or even better `#(1 2 3 3 3)`.
*** It purports to support Unicode, but it has only 16-bit characters.
Note that (subtypep 'character 'base-char) says T -- everything is a base char(!)
*** In general, running upgrade tests triggers massive CLOS breakage on CMUCL.
** SCL has bugs:
*** it doesn't like run-program from a modified directory?
*** it somehow pushes `:non-base-chars-exist-p` even though `+non-base-chars-exist-p+` is `NIL`???
** XCL has bad bugs:
*** make-pathname doesn't handle :type nil properly and
has massive lossage in logical-pathname support.
*** If using block () and return in search-for-system-definition
instead of return-from, XCL mistakenly has the return jump
to the end of the try function or something.
*** It also takes a long time for errors to propagate into a debugging REPL —
Maybe O(n^3) behavior or worse in walking the C++ stack?
*** The backtrace frames may contains unprintable objects.
*** make-pathname fails to copy the version from the defaults.
*** (make-pathname :host "ASDFTEST" :directory '(:absolute "system2" "module4")
:name nil :type nil) fails to handle the logical-pathname-ness of ASDFTEST.
*** `#5(1 ,@`(2 3)))` returns #(1 2 3),
rather than #(1 2 3 2 3 2 3 2 3) or even better #(1 2 3 3 3).
*** XCL recognizes :unspecific for a pathname type,
but prints the namestring with a dot separator!
(make-pathname :name "foo" :type :unspecific) ==> #P"foo."
If bug is ever fixed, upgrade *unspecific-pathname-type* in uiop/pathname.
*** XCL doesn't properly process files the name of which contains a *
*** XCL fails to recognize that specialized method parameters are implicitly ignorable.
** GCL is almost working again; but implementation bugs remain.
See Francois-Rene Rideau's messages on gcl-devel starting November 2013.
*** Missing support for many UIOP functions:
combine-fasls, get-optimization-settings...
*** ASDF may now be included for (require "asdf") and (require "ASDF"),
but how to compile it properly?
*** GCL fails to properly compile ASDF with the default compilation settings,
but works with those in script-support.lisp.
Symptoms when trying to load asdf.o:
Signalled by "AN ANONYMOUS FUNCTION".
INTERNAL-SIMPLE-ERROR: The package named ASDF/INTERFACE, does not exist
*** Another GCL compiler bug:
when I changed the definition of getcwd from
`(let ((*default-pathname-defaults* #p"")) (truename #p""))` to
`(let ((*default-pathname-defaults* *nil-pathname*)) (truename *nil-pathname*))`
to guard against e.g. a logical-pathname context while loading asdf
and parsing `#p""`, calls to `getcwd` result in a segfault.
*** An another bug: gcl refuses dynamic-extent declaration on functions.
```uiop/stream.lisp: #-gcl (declare (dynamic-extent ,@(when
before `(#',beforef)) ,@(when after `(#',afterf))))```
*** `(typep p 'logical-pathname)` should be T if p has a logical-pathname host.
*** `apropos` is case-sensitive and returns a same symbol many times
(presumably once per package where it is present,
instead of just once for its home package)
*** `compile-file` fails to return proper secondary values in case of non-style `WARNING`.
*** `(pathname-directory #p"foo/")` is incorrectly `("foo")` instead of `(:RELATIVE "foo")`
*** Do whatever it takes to pass the asdf tests, add the above?
*** Trying to `uiop:slurp-stream-forms` from a stream with `#+(or) :foo`
(or `read-file-forms` from an file with same) results in an error,
rather than `nil`. This is probably a bug in `#+` processing.
Unhappily, debian creates such a file in
`/etc/common-lisp/asdf-output-translations.conf.d/01-common-lisp-controller.conf`
*** Tests that try to catch an error fail (but catching a warning succeeds),
which suggests brokenness in handler-bind and/or error.
*** `COMPILE-FILE*` fails due to handler-bind error in
`with-muffled-compiler-conditions` or so.
*** `#5(1 ,@`(2 3)))` returns `#(1 2 3)`,
rather than `#(1 2 3 2 3 2 3 2 3)` or even better `#(1 2 3 3 3)`.
*** `(DIRECTORY #p"*.*")` fails to match files with pathname-type `NIL`.
*** GCL doesn't properly process files the name of which contains a `*`
** ABCL has a few bugs.
*** ABCL fails the timestamp propagation test.
*** `#5(1 ,@`(2 3)))` returns #(1 2 3),
rather than #(1 2 3 2 3 2 3 2 3) or even better #(1 2 3 3 3).
*** ABCL doesn't properly process files the name of which contains a *
** ECL has issues with its bundles.
On MacOS X, test-bundle.script fails.
*** ECL doesn't properly process files the name of which contains a *
** Allegro fails to parse argv the correct Windows way wrt C++ escaping conventions.
Is this (still) the case? What about LispWorks? Other implementations?
* Design & Implement some out-of-line configuration mechanism for various options?
i.e. let configuration files override some variables around some actions.
** Could be used to override new backward-incompatible defaults
(e.g. for operation propagation, deferred warnings, etc.)
** Use the above to bind variable around performing of actions.
* Improve robustness
** Fix bugs on http://bugs.launchpad.net/asdf/+bugs
*** fix directory-files to not return directories on CCL, etc. Add tests.
*** have a better defsystem form verifier - see lp#1007335
*** have a function verify-strict-asd that can verify a asd is pure lp#541562
Then if it passes, use load-strict-asd.
If not, optionally issue a warning. Start migrating people toward that.
** Include tests for prebuilt-system in test-bundle and in test-program.
** Test that a package-system secondary system is properly superseded
when the primary system is redefined.
* Learn to use cl-grid-test
** So we can easily make sure ASDF changes don't break stuff,
and that breakage gets fixed quickly.
* Diagnostics
** have a mode to explain WHY a component needs to be recompiled.
** A ``dry run'' of an operation can be made with the following form:
(let ((asdf:*verbose-out* *standard-output*))
(loop :for (op . comp) :in
(asdf/plan:plan-actions
(asdf/plan:make-plan nil ' ' :force t))
:do (asdf:explain op comp)))
What would be a nice interface for this functionality?
* have with-input-file use the encodings mechanism?
** Import asdf-encodings into UIOP? Sounds a lot of code for no users.
* have a single test .asd that tests as many features as possible, use it for upgrade test.
* operation cleanup?
** Refactor operation classes in action.lisp to not use slots for metadata
*** See commit message for 8e68ac229c19b7b611caf942a7f0998c88047a79
*** The problem: slots will NOT get properly upgraded with new initform.
*** Bad solution: A U-I-F-R-C method might do but would be much more complex to maintain,
not just for ASDF but potentially for anyone who defines extensions to ASDF.
*** The solution: use defmethod self-operation, not a self-operation slot.
This solution is trivially backward-compatible with older variants of ASDF.
*** Migration: find everyone on Quicklisp that defines an operation, and have them use defmethod.
Document all that in asdf.texinfo. Yet, unless noone is affected in Quicklisp,
don't modify ASDF classes themselves until a year or two afterwards, for compatibility purposes;
and/or when ASDF classes themselves need to be modified for the sake of some fix.
** To allow semantically distinct operations of the same class:
You'd need to have a protocol to canonicalize them
in the *OPERATIONS* memoization table, not by class name,
but by CONS of the class name and some CANONICAL-OPERATION-INITARGS.
The latter would be a generic function called on the initargs,
where any parasite initargs such as FORCE and FORCE-NOT have been removed,
since they below to the PLAN, not the OPERATION:
the OPERATE protocol would be refined to explicit split
arguments to be passed to MAKE-PLAN or to MAKE-OPERATION.
The default method for CANONICAL-OPERATION-INITARGS
would SORT (a plist->alist of) the initargs,
and that would replace the current ORIGINAL-INITARGS slot.
For this scheme to work even in presence of undisciplined users
using MAKE-INSTANCE on an operation class,
the OPERATION class would have an extra slot EFFECTIVE-OPERATION,
uninitialized by default (nil or unbound), whose accessor initializes it
if it's uninitialized, by looking up a canonical instance in *OPERATIONS*,
and if unfound registering the current operation as canonical.
Then, each component's COMPONENT-OPERATION-TIME hash-table
would be indexed by canonicalized operation object
rather than by operation class,
and POIU would have to be changed accordingly.
Of course, this entire cleanup is incompatible
with how SWANK and GBBopen currently abuse slots of operation,
so these would have to be fixed first.
And that's why I didn't do it.
It looks like SWANK can be fixed soon, though, so we'll see.
* Hunt systems that use obsolete APIs
* Get rid of component-properties
** directly use component-properties:
*** yaclml.asd => misguided :features for version comparison
*** amazon-ecs-20110418-git/amazon-ecs.asd => :website property
*** hemlock.asd => bad implementation of latin1 encodings
** .asd use :properties
*** arnesi, arnesi+ => :features, misguided for version comparison and pseudo #+features
*** lkcas, thopter => :long-name
*** cl-irc cliki-bot rss cl-syslog com.informatimago.clext
com.informatimago.clisp com.informatimago.clmisc
com.informatimago.common-lisp.arithmetic
com.informatimago.common-lisp.bank
com.informatimago.common-lisp.cesarum
com.informatimago.common-lisp com.informatimago.common-lisp.csv
com.informatimago.common-lisp.cxx
com.informatimago.common-lisp.data-encoding
com.informatimago.common-lisp.diagram
com.informatimago.common-lisp.ed
com.informatimago.common-lisp.graphviz
com.informatimago.common-lisp.heap
com.informatimago.common-lisp.html-base
com.informatimago.common-lisp.html-generator
com.informatimago.common-lisp.html-parser
com.informatimago.common-lisp.http
com.informatimago.common-lisp.interactive
com.informatimago.common-lisp.invoice
com.informatimago.common-lisp.lisp
com.informatimago.common-lisp.lisp.ibcl
com.informatimago.common-lisp.lisp.stepper
com.informatimago.common-lisp.lisp-reader
com.informatimago.common-lisp.lisp-sexp
com.informatimago.common-lisp.lisp-text
com.informatimago.common-lisp.parser
com.informatimago.common-lisp.picture
com.informatimago.common-lisp.regexp
com.informatimago.common-lisp.rfc2822
com.informatimago.common-lisp.rfc3548
com.informatimago.common-lisp.telnet
com.informatimago.common-lisp.unix
linc
com.informatimago.lispdoc
com.informatimago.lua
com.informatimago.cocoa-playground
com.informatimago.objcl
com.informatimago.rdp
com.informatimago.rdp.basic
com.informatimago.rdp.basic.example
com.informatimago.rdp.example
com.informatimago.susv3
com.informatimago.common-lisp.tools.make-depends
com.informatimago.xcode
spartns
xlunit
=> (uninterned!)
#:author-email #:date
(#:albert #:output-dirs)
(#:albert #:formats)
(#:albert #:docbook #:template)
(#:albert #:docbook #:bgcolor)
(#:albert #:docbook #:textcolor)
(#:albert #:docbook #:dtd)
*** portableaserve
=>
("system" "author" "email")
("albert" "presentation" "output-dir")
("albert" "presentation" "formats")
("albert" "docbook" "dtd")
("albert" "docbook" "template")
*** com.clearly-useful.generic-collection-interface => :com.clearly-useful
*** metatilities
=> :ait-timeout :system-applicable-p
*** ucw ucw-core
=>
version
* ASDF4: search for this tag, rename things (incompatibly, thus) and cleanup code.
** Migrate from component-depends-on to action-depends-on
*** I contend a future version of ASDF will replace
`(component-depends-on operation component)`
with `(action-depends-on plan operation component)`.
This allows for different normalization strategies for dependencies
(including strategies that avoid resolving things to NIL),
a reified context for featurep checks, etc.
*** Easy but long backward-compatible transition:
**** get all users to use the new gf and keep extending both new and old gf,
meanwhile the new gf has an around method that actually calls the old gf
except in testing mode and/or if we can check that they're using the new convention
**** when everyone has migrated, remove the old mode and the short-circuit.
*** However, we cannot deprecate component-depends-on yet — not until we have
some transition in place to a better interface.
* Documentation
** See message from 2014-01-27 05:26:44 GMT for stuff to document.
http://thread.gmane.org/gmane.lisp.asdf.devel/3675/focus=3695
** style guide for .asd files
* UIOP
** deferred-warnings support probably needs to be redone better.
*** implement deferred warnings support on lispworks
*** turn undefined function style-warnings into full warnings(?)
*** work with cl-test-grid to eliminate deferred warnings from quicklisp libraries
*** https://www.mail-archive.com/asdf-devel@common-lisp.net/msg03608.html
*** czak@google.com rewrote part of deferred warnings support.
Ask him to release the code he implemented at Google under QITAB.
** Ensure all run-program issues on Windows are solved.
*** SBCL cannot do raw CMD.EXE command-lines
*** We don't seem to properly escape CRLF in escape-windows-token,
or maybe it is, but CMD.EXE does the wrong thing in them,
so the semantics depend on whether it's used,
or maybe it's CCL eating them while parsing, or maybe not, etc.
In any case, this requires clarification.
** define-package cannot deal with symbols moving "forward".
*** document that THOU SHALT NOT USE :RECYCLE with packages previously
defined by define-package when building from scratch.
*** Maybe add a check? But how to tell whether you're building from scratch?
*** Add some :moved-to directive to define-package, such that
(:moved-to forward-package symbols...)
will declare symbols as moved forward: when the symbol already exists,
it is moved to the forward package if that package already exists,
after the package created if it doesn't exist yet (!)
*** There again, a check that a forward-package is not backward
would be very nice.
* Faster source-registry:
** In addition and/or as a substitute to the .cl-source-registry.cache,
that is meant to be semi-automatically managed, there could be
a cl-source-registry.conf meant for manual management:
when recursing into a source-registry :tree, if such file is present
(or if not, if a hidden .cl-source-registry.conf is present instead?),
its contents is read as a (:source-registry ...) specification, and
replaces the actual or notional (:tree ...) for the current directory;
it may then include :file entries as well as :directory and :tree entries,
whereby the programmer can explicitly give a definitive list of
systems exported by his software, while excluding any test system
that he doesn't want to export. This means that developers have
both a way of speeding up the build of their software and of
avoiding pollution by test systems that should remain private,
and that they can otherwise explicitly enable when they need them.
** The .cl-source-registry.cache should avoid recursing into
directories that themselves already have a cache or a .conf file,
but instead store the name of these directories,
so these files will be read recursively by asdf, allowing for
semi-modular updates.
* Properly deprecate all that needs to go
** Get lisa, readable, bourbaki to NOT include ASDF 1 anymore in their sources.
** Identify all the things in ASDF that we want to deprecate, and make
sure we deprecate them all in 3.4.
** Implement support for deprecating old packages,
by having all functions and macros under the old package name be
proxies to those in the new package name?
(Exception: special variables can't be proxies, have to be imported.)
** Delete asdf-driver.asd, nobody has used it in years
** Eradicate Quicklisp systems that depend on asdf-package-system, make them depend on asdf3.1 instead.
** Deprecate and remove asdf-binary-locations (ABL) compatibility altogether.
No one has been using ASDF1 for years.
There is no ABL to be compatible with —
is anyone still using the compatibility mode?
Maybe issue a warning, then a cerror, before to remove the code?
* Fix plan
** Goal: Implement proper incrementality for defsystem-depends-on.
Fix the bug wherein ASDF fails to properly handle incrementality for `defsystem-depends-on`.
https://bugs.launchpad.net/asdf/+bug/1500578
Some discussion about ASDF at
http://ccl.clozure.com/irc-logs/lisp/lisp-2016-10.txt
** DONE Items
*** Add `DEFINE-OP` for loading system definitions.
*** A `DEFINE-OP` will depend on other `DEFINE-OP`s
*** A `DEFINE-OP` depends on all `LOAD-OP` in the file.
Whether via defsystem-depends-on or manual `LOAD-OP`s.
*** Store timestamps in `DEFINE-OP` entries, not `*DEFINED-SYSTEMS*`.
*** In find-system, add condition that all dependencies are up-to-date.
*** This necessitates another layer of visit states,
that do not plan, just check planning...
*** `LOAD-ASD` calls `PERFORM DEFINE-OP` (not the other way around)
*** Systems probably need depend on `(DEFINE-OP . PRIMARY-SYSTEM)`
*** These dynamically-discovered dependencies are stored in a slot of `SYSTEM`.
*** Have a special kind of definition-depends-on dependency.
Before we reuse a node from a previous session,
we must make sure it is still properly defined.
This matters because we do reuse (at least *some* nodes, e.g. system nodes)
from previous sessions, and the control structure may have changed
(i.e. the system hasn't been redefined, but one of its defsystem-depends-on
dependencies has changed).
*** Handle incomplete definitions properly
Don't just let the incompletely parsed system be registered
in a false positive success as if it were an empty system.
Solution: It is registered, but considered out-of-date,
so next attempt to use it will cause a refresh attempt.
https://bugs.launchpad.net/asdf/+bug/1515372
*** Handle nested calls to `OPERATE`
We must accept that ASDF isn't really plan-then-perform,
as the ASDF1 model claimed to be.
It's an arbitrary nesting of plan-and-perform, like a parenthesization
with plan (steps) as left parenthesis and perform (steps) as right parenthesis,
and with operate being a maximal balanced span of plan and perform steps.
*** What goes in a shared dynamic `*SESSION*`, what in a private lexical `PLAN`?
Memoization CACHE of various functions, Status of VISITED-NODES, FORCING parameters.
The session will contain not just the current `*CACHE*`, but also
all or most of the graph traversal, thus the `:force` options, etc.
The `*PLAN*` may or may not contain some work queueing.
But even, e.g. a table of "nodes still directly blocking us"
is shared at the shared traversal level.
*** It is an error for a nested `OPERATE` to contradict session flags.
This raises the question of `:force` and `:force-not` flags.
An actual operate cannot contradict them and cause things to be performed
with a wrong subset of dependencies loaded.
Yet, `REQUIRED-COMPONENTS` (that does cause anything to be performed —
except via nested `OPERATE` from `defsystem-depends-on`)
must be able to skip some dependencies
(though maybe only _in addition_ to the global ones).
*** What timestamp for `forced` and `forced-not` actions?
If an action is forced-not, it should be returned with an action stamp from this cache,
and not with `nil` as is currently wrongly done
(unless of course the cache entry is missing,
at which point `nil` is the correct answer).
Conversely, a force means the stamp should be `t`
(indicating it needs to be done in the future)
(that part asdf gets right).
*** Handle planning things that are now done but were done in a previous phase of the build,
so dependency on them should trigger the build.
*** Protocol to not re-perform an action twice
In PERFORM-PLAN, check that an action wasn't already DONE-P due to
being needed in a previous phase of recursively calling OPERATE,
before to PERFORM it.
To correctly propagate timestamps in across nested calls,
the graph traversal and timestamp propagation is shared at the session level
between all nested calls to `OPERATE`.
During a session and across phases, every action has a status made of
a stamp and three bits: KEEP-P, DONE-P, NEED-P.
The stamp also survives across sessions, in `COMPONENT-OPERATION-TIMES`.
*** Detect circularities across nested calls to `OPERATE`
This means the circularity detection data is part of the session.
Notably, the visiting list and set.
The top of the list can also serve to record the dependencies from `OPERATE` to `DEPEND-OP`.
*** In UIOP, RECORD-DEPENDENCY must not cross to an upper plan and/or it should
record the dependency in said upper plan (that matters because
parallel plans doing extra checking, and this is a problem
whereby some links to extra actions are left unresolved).
Maybe in the future, record the dependency in the session, not in a plan.
** TODO items
*** find-system should probably cause a dependency on define-op, especially inside another define-op
*** Is it worth it trying to optimize away a dependency on a define-op
when an action already depends on another operation that "obviously" depends on that define-op?
*** Document DEFINE-OP and the design in asdf.texinfo and/or in some article.
** Future developments
*** Grovel all .asd files in Quicklisp and collect all violations of declarativeness,
where declarativeness is having only defsystem forms. Specially classify in-package,
maybe also defpackage. Then we can assess the impact of requiring declarativeness.
*** Also grovel Quicklisp for all extensions to ASDF:
see if there are new methods on perform, input-files, output-files, operate, etc.
*** To allow defsystem-depends-on to another secondary system within the
same file, I can imagine some system to dynamically create a separate action
(DEFINE-OP foo/x) for each form defsystem foo/x, and have it depend on
all the preceding actions operated in the .asd file.
Plus a last action for dangling load-system or operate statements?
Or one action for every operate statement?
There would be no action of the entire load-asd, but a separate mechanism
to detect circularity?
What about dangling statements? They would be a bit like xcvb weakly-ordered
run-time dependencies that CAN have circularities? Ouch. Really ugly.
Each statement would need its own action? Ouch.
*** Have load-asd clear any invalidated previous secondary system
before loading, which supposes remembering what these systems are.
Then, you're not allowed to forward-reference a secondary system that
hasn't been defined yet while you're loading the .asd, whereas you
can load the asd if you aren't loading it yet.
*** Maybe split DEFINE-OP into PREPARE-DEFINE-OP and DEFINE-OP, so that
secondary systems can be properly loaded?
*** Add mapping from files to action that creates it and/or uses it?
Then we can detect conflict between multiple actions creating one file.
Forbid direct use of files not listed as inputs? What about transitive inputs?
Build in a container that has only the proper files...
*** What data structure for scheduling planned actions?
A doubly-linked to remove entire chunks of the plan after a sub-operate?
That won't do, because later-discovered defsystem dependency can refer to
systems that were planned but not performed, so there need be no contiguity
in the chunks that are performed by subcalls to operate.
Actually, if we otherwise forbid reference to another system
from non-system components, then we could move things with system granularity,
which is one thing; but we still need a general mechanism at the system level.
So, whether it's an explicit queue or an implicit traversal of the dependency graph,
we must check whether an action has already been done before we try to perform it.
And an implicit traversal has the advantage that you can avoid entire subtrees
when you find that the current node has already been performed during
a previous phase of the plan.
In conclusion: "just" traverse the graph at the last minute, and
perform things serially, and/or if you want some parallelism,
build a queue dynamically at the last minute for the "now" jobs
while keeping most of the plan as graph structures.
*** Merging in parts of POIU?
ASDF internals are nothing to be proud of:
ASDF1 was optimized for "smallest code that kind of works in the usual case",
and ASDF3 was optimized for "smallest code that fixes ASDF1 in the general case
while mostly maintaining backward compatibility".
Because of its optimization constraint, ASDF1 was using and abusing lists a lot,
rather than defining nice data structures.
ASDF3 uses somewhat more structured data, with a few more classes, and
algorithms that are O(n) instead of O(n**3) in simple cases and
exponential in carefully crafted examples;
yet it has shunned any definition of more advanced or general data structures.
By contrast, POIU has a dequeue to represent queued compilation jobs, and
a general graph representation for the action graph
(though the original POIU was also O(n**3) because it lacked PREPARE-OP).
I could import the POIU queue and graph representations into ASDF, and
that would add about 100 lines of code to UIOP for the queue, and
200 lines to ASDF for the graph, maybe a bit more if the code is
generalized, commented and largely put in UIOP.
Then, there's the support for actual forking and using forks,
that would be about 400 lines added to UIOP, and
the using it in ASDF to consume the plan, which would be under 200 lines.
But those parts are probably better left out of ASDF itself.
That said, it all was a lot when ASDF was < 1000 lines of code,
but isn't all that much now that it is > 12000 lines of code.
asdf-3.3.4/action.lisp 0000664 0000000 0000000 00000063143 13621551153 0014615 0 ustar 00root root 0000000 0000000 ;;;; -------------------------------------------------------------------------
;;;; Actions
(uiop/package:define-package :asdf/action
(:nicknames :asdf-action)
(:recycle :asdf/action :asdf/plan :asdf)
(:use :uiop/common-lisp :uiop :asdf/upgrade :asdf/session :asdf/component :asdf/operation)
(:import-from :asdf/operation #:check-operation-constructor)
(:import-from :asdf/component #:%additional-input-files)
(:export
#:action #:define-convenience-action-methods
#:action-description #:format-action
#:downward-operation #:upward-operation #:sideway-operation #:selfward-operation
#:non-propagating-operation
#:component-depends-on
#:input-files #:output-files #:output-file #:operation-done-p
#:action-operation #:action-component #:make-action
#:component-operation-time #:mark-operation-done #:compute-action-stamp
#:perform #:perform-with-restarts #:retry #:accept
#:action-path #:find-action
#:operation-definition-warning #:operation-definition-error ;; condition
#:action-valid-p
#:circular-dependency #:circular-dependency-actions
#:call-while-visiting-action #:while-visiting-action
#:additional-input-files))
(in-package :asdf/action)
(eval-when (#-lispworks :compile-toplevel :load-toplevel :execute) ;; LispWorks issues spurious warning
(deftype action ()
"A pair of operation and component uniquely identifies a node in the dependency graph
of steps to be performed while building a system."
'(cons operation component))
(deftype operation-designator ()
"An operation designates itself. NIL designates a context-dependent current operation,
and a class-name or class designates the canonical instance of the designated class."
'(or operation null symbol class)))
;;; these are pseudo accessors -- let us abstract away the CONS cell representation of plan
;;; actions.
(with-upgradability ()
(defun make-action (operation component)
(cons operation component))
(defun action-operation (action)
(car action))
(defun action-component (action)
(cdr action)))
;;;; Reified representation for storage or debugging. Note: an action is identified by its class.
(with-upgradability ()
(defun action-path (action)
"A readable data structure that identifies the action."
(when action
(let ((o (action-operation action))
(c (action-component action)))
(cons (type-of o) (component-find-path c)))))
(defun find-action (path)
"Reconstitute an action from its action-path"
(destructuring-bind (o . c) path (make-action (make-operation o) (find-component () c)))))
;;;; Convenience methods
(with-upgradability ()
;; A macro that defines convenience methods for a generic function (gf) that
;; dispatches on operation and component. The convenience methods allow users
;; to call the gf with operation and/or component designators, that the
;; methods will resolve into actual operation and component objects, so that
;; the users can interact using readable designators, but developers only have
;; to write methods that handle operation and component objects.
;; FUNCTION is the generic function name
;; FORMALS is its list of arguments, which must include OPERATION and COMPONENT.
;; IF-NO-OPERATION is a form (defaults to NIL) describing what to do if no operation is found.
;; IF-NO-COMPONENT is a form (defaults to NIL) describing what to do if no component is found.
(defmacro define-convenience-action-methods
(function formals &key if-no-operation if-no-component)
(let* ((rest (gensym "REST"))
(found (gensym "FOUND"))
(keyp (equal (last formals) '(&key)))
(formals-no-key (if keyp (butlast formals) formals))
(len (length formals-no-key))
(operation 'operation)
(component 'component)
(opix (position operation formals))
(coix (position component formals))
(prefix (subseq formals 0 opix))
(suffix (subseq formals (1+ coix) len))
(more-args (when keyp `(&rest ,rest &key &allow-other-keys))))
(assert (and (integerp opix) (integerp coix) (= coix (1+ opix))))
(flet ((next-method (o c)
(if keyp
`(apply ',function ,@prefix ,o ,c ,@suffix ,rest)
`(,function ,@prefix ,o ,c ,@suffix))))
`(progn
(defmethod ,function (,@prefix (,operation string) ,component ,@suffix ,@more-args)
(declare (notinline ,function))
(let ((,component (find-component () ,component))) ;; do it first, for defsystem-depends-on
,(next-method `(safe-read-from-string ,operation :package :asdf/interface) component)))
(defmethod ,function (,@prefix (,operation symbol) ,component ,@suffix ,@more-args)
(declare (notinline ,function))
(if ,operation
,(next-method
`(make-operation ,operation)
`(or (find-component () ,component) ,if-no-component))
,if-no-operation))
(defmethod ,function (,@prefix (,operation operation) ,component ,@suffix ,@more-args)
(declare (notinline ,function))
(if (typep ,component 'component)
(error "No defined method for ~S on ~/asdf-action:format-action/"
',function (make-action ,operation ,component))
(if-let (,found (find-component () ,component))
,(next-method operation found)
,if-no-component))))))))
;;;; Self-description
(with-upgradability ()
(defgeneric action-description (operation component)
(:documentation "returns a phrase that describes performing this operation
on this component, e.g. \"loading /a/b/c\".
You can put together sentences using this phrase."))
(defmethod action-description (operation component)
(format nil (compatfmt "~@<~A on ~A~@:>")
operation component))
(defun format-action (stream action &optional colon-p at-sign-p)
"FORMAT helper to display an action's action-description.
Use it in FORMAT control strings as ~/asdf-action:format-action/"
(assert (null colon-p)) (assert (null at-sign-p))
(destructuring-bind (operation . component) action
(princ (action-description operation component) stream))))
;;;; Detection of circular dependencies
(with-upgradability ()
(defun (action-valid-p) (operation component)
"Is this action valid to include amongst dependencies?"
;; If either the operation or component was resolved to nil, the action is invalid.
;; :if-feature will invalidate actions on components for which the features don't apply.
(and operation component
(if-let (it (component-if-feature component)) (featurep it) t)))
(define-condition circular-dependency (system-definition-error)
((actions :initarg :actions :reader circular-dependency-actions))
(:report (lambda (c s)
(format s (compatfmt "~@")
(circular-dependency-actions c)))))
(defun call-while-visiting-action (operation component fun)
"Detect circular dependencies"
(with-asdf-session ()
(with-accessors ((action-set visiting-action-set)
(action-list visiting-action-list)) *asdf-session*
(let ((action (cons operation component)))
(when (gethash action action-set)
(error 'circular-dependency :actions
(member action (reverse action-list) :test 'equal)))
(setf (gethash action action-set) t)
(push action action-list)
(unwind-protect
(funcall fun)
(pop action-list)
(setf (gethash action action-set) nil))))))
;; Syntactic sugar for call-while-visiting-action
(defmacro while-visiting-action ((o c) &body body)
`(call-while-visiting-action ,o ,c #'(lambda () ,@body))))
;;;; Dependencies
(with-upgradability ()
(defgeneric component-depends-on (operation component) ;; ASDF4: rename to component-dependencies
(:documentation
"Returns a list of dependencies needed by the component to perform
the operation. A dependency has one of the following forms:
( *), where is an operation designator
with respect to FIND-OPERATION in the context of the OPERATION argument,
and each is a component designator with respect to
FIND-COMPONENT in the context of the COMPONENT argument,
and means that the component depends on
having been performed on each ;
[Note: an is an operation designator -- it can be either an
operation name or an operation object. Similarly, a may be
a component name or a component object. Also note that, the degenerate
case of () is a no-op.]
Methods specialized on subclasses of existing component types
should usually append the results of CALL-NEXT-METHOD to the list."))
(define-convenience-action-methods component-depends-on (operation component))
(defmethod component-depends-on :around ((o operation) (c component))
(do-asdf-cache `(component-depends-on ,o ,c)
(call-next-method))))
;;;; upward-operation, downward-operation, sideway-operation, selfward-operation
;; These together handle actions that propagate along the component hierarchy or operation universe.
(with-upgradability ()
(defclass downward-operation (operation)
((downward-operation
:initform nil :reader downward-operation
:type operation-designator :allocation :class))
(:documentation "A DOWNWARD-OPERATION's dependencies propagate down the component hierarchy.
I.e., if O is a DOWNWARD-OPERATION and its DOWNWARD-OPERATION slot designates operation D, then
the action (O . M) of O on module M will depends on each of (D . C) for each child C of module M.
The default value for slot DOWNWARD-OPERATION is NIL, which designates the operation O itself.
E.g. in order for a MODULE to be loaded with LOAD-OP (resp. compiled with COMPILE-OP), all the
children of the MODULE must have been loaded with LOAD-OP (resp. compiled with COMPILE-OP."))
(defun downward-operation-depends-on (o c)
`((,(or (downward-operation o) o) ,@(component-children c))))
(defmethod component-depends-on ((o downward-operation) (c parent-component))
`(,@(downward-operation-depends-on o c) ,@(call-next-method)))
(defclass upward-operation (operation)
((upward-operation
:initform nil :reader upward-operation
:type operation-designator :allocation :class))
(:documentation "An UPWARD-OPERATION has dependencies that propagate up the component hierarchy.
I.e., if O is an instance of UPWARD-OPERATION, and its UPWARD-OPERATION slot designates operation U,
then the action (O . C) of O on a component C that has the parent P will depends on (U . P).
The default value for slot UPWARD-OPERATION is NIL, which designates the operation O itself.
E.g. in order for a COMPONENT to be prepared for loading or compiling with PREPARE-OP, its PARENT
must first be prepared for loading or compiling with PREPARE-OP."))
;; For backward-compatibility reasons, a system inherits from module and is a child-component
;; so we must guard against this case. ASDF4: remove that.
(defun upward-operation-depends-on (o c)
(if-let (p (component-parent c)) `((,(or (upward-operation o) o) ,p))))
(defmethod component-depends-on ((o upward-operation) (c child-component))
`(,@(upward-operation-depends-on o c) ,@(call-next-method)))
(defclass sideway-operation (operation)
((sideway-operation
:initform nil :reader sideway-operation
:type operation-designator :allocation :class))
(:documentation "A SIDEWAY-OPERATION has dependencies that propagate \"sideway\" to siblings
that a component depends on. I.e. if O is a SIDEWAY-OPERATION, and its SIDEWAY-OPERATION slot
designates operation S (where NIL designates O itself), then the action (O . C) of O on component C
depends on each of (S . D) where D is a declared dependency of C.
E.g. in order for a COMPONENT to be prepared for loading or compiling with PREPARE-OP,
each of its declared dependencies must first be loaded as by LOAD-OP."))
(defun sideway-operation-depends-on (o c)
`((,(or (sideway-operation o) o) ,@(component-sideway-dependencies c))))
(defmethod component-depends-on ((o sideway-operation) (c component))
`(,@(sideway-operation-depends-on o c) ,@(call-next-method)))
(defclass selfward-operation (operation)
((selfward-operation
;; NB: no :initform -- if an operation depends on others, it must explicitly specify which
:type (or operation-designator list) :reader selfward-operation :allocation :class))
(:documentation "A SELFWARD-OPERATION depends on another operation on the same component.
I.e., if O is a SELFWARD-OPERATION, and its SELFWARD-OPERATION designates a list of operations L,
then the action (O . C) of O on component C depends on each (S . C) for S in L.
E.g. before a component may be loaded by LOAD-OP, it must have been compiled by COMPILE-OP.
A operation-designator designates a singleton list of the designated operation;
a list of operation-designators designates the list of designated operations;
NIL is not a valid operation designator in that context. Note that any dependency
ordering between the operations in a list of SELFWARD-OPERATION should be specified separately
in the respective operation's COMPONENT-DEPENDS-ON methods so that they be scheduled properly."))
(defun selfward-operation-depends-on (o c)
(loop :for op :in (ensure-list (selfward-operation o)) :collect `(,op ,c)))
(defmethod component-depends-on ((o selfward-operation) (c component))
`(,@(selfward-operation-depends-on o c) ,@(call-next-method)))
(defclass non-propagating-operation (operation)
()
(:documentation "A NON-PROPAGATING-OPERATION is an operation that propagates
no dependencies whatsoever. It is supplied in order that the programmer be able
to specify that s/he is intentionally specifying an operation which invokes no
dependencies.")))
;;;---------------------------------------------------------------------------
;;; Help programmers catch obsolete OPERATION subclasses
;;;---------------------------------------------------------------------------
(with-upgradability ()
(define-condition operation-definition-warning (simple-warning)
()
(:documentation "Warning condition related to definition of obsolete OPERATION objects."))
(define-condition operation-definition-error (simple-error)
()
(:documentation "Error condition related to definition of incorrect OPERATION objects."))
(defmethod initialize-instance :before ((o operation) &key)
(check-operation-constructor)
(unless (typep o '(or downward-operation upward-operation sideway-operation
selfward-operation non-propagating-operation))
(warn 'operation-definition-warning
:format-control
"No dependency propagating scheme specified for operation class ~S.
The class needs to be updated for ASDF 3.1 and specify appropriate propagation mixins."
:format-arguments (list (type-of o)))))
(defmethod initialize-instance :before ((o non-propagating-operation) &key)
(when (typep o '(or downward-operation upward-operation sideway-operation selfward-operation))
(error 'operation-definition-error
:format-control
"Inconsistent class: ~S
NON-PROPAGATING-OPERATION is incompatible with propagating operation classes as superclasses."
:format-arguments
(list (type-of o)))))
(defun backward-compatible-depends-on (o c)
"DEPRECATED: all subclasses of OPERATION used in ASDF should inherit from one of
DOWNWARD-OPERATION UPWARD-OPERATION SIDEWAY-OPERATION SELFWARD-OPERATION NON-PROPAGATING-OPERATION.
The function BACKWARD-COMPATIBLE-DEPENDS-ON temporarily provides ASDF2 behaviour for those that
don't. In the future this functionality will be removed, and the default will be no propagation."
(uiop/version::notify-deprecated-function
(version-deprecation *asdf-version* :style-warning "3.2")
`(backward-compatible-depends-on :for-operation ,o))
`(,@(sideway-operation-depends-on o c)
,@(when (typep c 'parent-component) (downward-operation-depends-on o c))))
(defmethod component-depends-on ((o operation) (c component))
`(;; Normal behavior, to allow user-specified in-order-to dependencies
,@(cdr (assoc (type-of o) (component-in-order-to c)))
;; For backward-compatibility with ASDF2, any operation that doesn't specify propagation
;; or non-propagation through an appropriate mixin will be downward and sideway.
,@(unless (typep o '(or downward-operation upward-operation sideway-operation
selfward-operation non-propagating-operation))
(backward-compatible-depends-on o c))))
(defmethod downward-operation ((o operation)) nil)
(defmethod sideway-operation ((o operation)) nil))
;;;---------------------------------------------------------------------------
;;; End of OPERATION class checking
;;;---------------------------------------------------------------------------
;;;; Inputs, Outputs, and invisible dependencies
(with-upgradability ()
(defgeneric output-files (operation component)
(:documentation "Methods for this function return two values: a list of output files
corresponding to this action, and a boolean indicating if they have already been subjected
to relevant output translations and should not be further translated.
Methods on PERFORM *must* call this function to determine where their outputs are to be located.
They may rely on the order of the files to discriminate between outputs.
"))
(defgeneric input-files (operation component)
(:documentation "A list of input files corresponding to this action.
Methods on PERFORM *must* call this function to determine where their inputs are located.
They may rely on the order of the files to discriminate between inputs.
"))
(defgeneric operation-done-p (operation component)
(:documentation "Returns a boolean which is NIL if the action must be performed (again)."))
(define-convenience-action-methods output-files (operation component))
(define-convenience-action-methods input-files (operation component))
(define-convenience-action-methods operation-done-p (operation component))
(defmethod operation-done-p ((o operation) (c component))
t)
;; Translate output files, unless asked not to. Memoize the result.
(defmethod output-files :around ((operation t) (component t))
(do-asdf-cache `(output-files ,operation ,component)
(values
(multiple-value-bind (pathnames fixedp) (call-next-method)
;; 1- Make sure we have absolute pathnames
(let* ((directory (pathname-directory-pathname
(component-pathname (find-component () component))))
(absolute-pathnames
(loop
:for pathname :in pathnames
:collect (ensure-absolute-pathname pathname directory))))
;; 2- Translate those pathnames as required
(if fixedp
absolute-pathnames
(mapcar *output-translation-function* absolute-pathnames))))
t)))
(defmethod output-files ((o operation) (c component))
nil)
(defun output-file (operation component)
"The unique output file of performing OPERATION on COMPONENT"
(let ((files (output-files operation component)))
(assert (length=n-p files 1))
(first files)))
(defgeneric additional-input-files (operation component)
(:documentation "Additional input files for the operation on this
component. These are files that are inferred, rather than
explicitly specified, and these are typically NOT files that
undergo operations directly. Instead, they are files that it is
important for ASDF to know about in order to compute operation times,etc."))
(define-convenience-action-methods additional-input-files (operation component))
(defmethod additional-input-files ((op operation) (comp component))
(cdr (assoc op (%additional-input-files comp))))
;; Memoize input files.
(defmethod input-files :around (operation component)
(do-asdf-cache `(input-files ,operation ,component)
;; get the additional input files, if any
(append (call-next-method)
;; must come after the first, for other code that
;; assumes the first will be the "key" file
(additional-input-files operation component))))
;; By default an action has no input-files.
(defmethod input-files ((o operation) (c component))
nil)
;; An action with a selfward-operation by default gets its input-files from the output-files of
;; the actions using selfward-operations it depends on (and the same component),
;; or if there are none, on the component-pathname of the component if it's a file
;; -- and then on the results of the next-method.
(defmethod input-files ((o selfward-operation) (c component))
`(,@(or (loop :for dep-o :in (ensure-list (selfward-operation o))
:append (or (output-files dep-o c) (input-files dep-o c)))
(if-let ((pathname (component-pathname c)))
(and (file-pathname-p pathname) (list pathname))))
,@(call-next-method))))
;;;; Done performing
(with-upgradability ()
;; ASDF4: hide it behind plan-action-stamp
(defgeneric component-operation-time (operation component)
(:documentation "Return the timestamp for when an action was last performed"))
(defgeneric (setf component-operation-time) (time operation component)
(:documentation "Update the timestamp for when an action was last performed"))
(define-convenience-action-methods component-operation-time (operation component))
;; ASDF4: hide it behind (setf plan-action-stamp)
(defgeneric mark-operation-done (operation component)
(:documentation "Mark a action as having been just done.
Updates the action's COMPONENT-OPERATION-TIME to match the COMPUTE-ACTION-STAMP
using the JUST-DONE flag."))
(defgeneric compute-action-stamp (plan- operation component &key just-done)
;; NB: using plan- rather than plan above allows clisp to upgrade from 2.26(!)
(:documentation "Has this action been successfully done already,
and at what known timestamp has it been done at or will it be done at?
* PLAN is a plan object modelling future effects of actions,
or NIL to denote what actually happened.
* OPERATION and COMPONENT denote the action.
Takes keyword JUST-DONE:
* JUST-DONE is a boolean that is true if the action was just successfully performed,
at which point we want compute the actual stamp and warn if files are missing;
otherwise we are making plans, anticipating the effects of the action.
Returns two values:
* a STAMP saying when it was done or will be done,
or T if the action involves files that need to be recomputed.
* a boolean DONE-P that indicates whether the action has actually been done,
and both its output-files and its in-image side-effects are up to date."))
(defmethod component-operation-time ((o operation) (c component))
(gethash o (component-operation-times c)))
(defmethod (setf component-operation-time) (stamp (o operation) (c component))
(assert stamp () "invalid null stamp for ~A" (action-description o c))
(setf (gethash o (component-operation-times c)) stamp))
(defmethod mark-operation-done ((o operation) (c component))
(let ((stamp (compute-action-stamp nil o c :just-done t)))
(assert stamp () "Failed to compute a stamp for completed action ~A" (action-description o c))1
(setf (component-operation-time o c) stamp))))
;;;; Perform
(with-upgradability ()
(defgeneric perform (operation component)
(:documentation "PERFORM an action, consuming its input-files and building its output-files"))
(define-convenience-action-methods perform (operation component))
(defmethod perform :around ((o operation) (c component))
(while-visiting-action (o c) (call-next-method)))
(defmethod perform :before ((o operation) (c component))
(ensure-all-directories-exist (output-files o c)))
(defmethod perform :after ((o operation) (c component))
(mark-operation-done o c))
(defmethod perform ((o operation) (c parent-component))
nil)
(defmethod perform ((o operation) (c source-file))
;; For backward compatibility, don't error on operations that don't specify propagation.
(when (typep o '(or downward-operation upward-operation sideway-operation
selfward-operation non-propagating-operation))
(sysdef-error
(compatfmt "~@")
'perform (make-action o c))))
;; The restarts of the perform-with-restarts variant matter in an interactive context.
;; The retry strategies of p-w-r itself, and/or the background workers of a multiprocess build
;; may call perform directly rather than call p-w-r.
(defgeneric perform-with-restarts (operation component)
(:documentation "PERFORM an action in a context where suitable restarts are in place."))
(defmethod perform-with-restarts (operation component)
(perform operation component))
(defmethod perform-with-restarts :around (operation component)
(loop
(restart-case
(return (call-next-method))
(retry ()
:report
(lambda (s)
(format s (compatfmt "~@")
(action-description operation component))))
(accept ()
:report
(lambda (s)
(format s (compatfmt "~@")
(action-description operation component)))
(mark-operation-done operation component)
(return))))))
asdf-3.3.4/asdf.asd 0000664 0000000 0000000 00000012230 13621551153 0014044 0 ustar 00root root 0000000 0000000 ;;; -*- mode: lisp -*-
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; ;;;
;;; Free Software available under an MIT-style license. ;;;
;;; ;;;
;;; Copyright (c) 2001-2019 Daniel Barlow and contributors ;;;
;;; ;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package :asdf)
;; We can't rely on it being defined in uiop.asd, since that file isn't loaded.
(defun call-without-redefinition-warnings (thunk)
(handler-bind (((or
#+allegro simple-warning
#+clozure ccl:compiler-warning
#+cmucl kernel:simple-style-warning
#-(or allegro clozure cmucl) warning)
#'muffle-warning))
(funcall thunk)))
;; Note that it's polite to sort the defsystem forms in dependency order,
;; and compulsory to sort them in defsystem-depends-on order.
#+asdf3
(defsystem "asdf/prelude"
:version (:read-file-form "version.lisp-expr")
:around-compile call-without-redefinition-warnings ;; we need be the same as uiop
:encoding :utf-8
:components ((:file "header")))
#+asdf3
(defsystem "asdf/driver"
;; Since ASDF 3.3, asdf.asd can't afford to depend on reading uiop.asd,
;; which would cause circularity, since everything depends on reading asdf.asd.
;; Therefore, we can't "just" :depends-on ("uiop") like we used to do, and instead
;; we transclude the list of uiop component into this secondary system.
:pathname "uiop"
:around-compile call-without-redefinition-warnings ;; we need be the same as uiop
:components #.(getf (read-file-form (subpathname *load-pathname* "uiop/uiop.asd") :at 2) :components))
#+asdf3
(defsystem "asdf/defsystem"
:licence "MIT"
:description "The defsystem part of ASDF"
:long-name "Another System Definition Facility"
:description "The portable defsystem for Common Lisp"
:long-description "ASDF/DEFSYSTEM is the de facto standard DEFSYSTEM facility for Common Lisp,
a successor to Dan Barlow's ASDF and Francois-Rene Rideau's ASDF2.
For bootstrap purposes, it comes bundled with UIOP in a single file, asdf.lisp."
:homepage "http://common-lisp.net/projects/asdf/"
:bug-tracker "https://launchpad.net/asdf/"
:mailto "asdf-devel@common-lisp.net"
:source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
:version (:read-file-form "version.lisp-expr")
:build-operation monolithic-concatenate-source-op
:build-pathname "build/asdf" ;; our target
:around-compile call-without-redefinition-warnings ;; we need be the same as uiop
:depends-on ("asdf/prelude" "asdf/driver")
:encoding :utf-8
:components
((:file "upgrade")
(:file "session" :depends-on ("upgrade"))
(:file "component" :depends-on ("session"))
(:file "operation" :depends-on ("session"))
(:file "system" :depends-on ("component"))
(:file "system-registry" :depends-on ("system"))
(:file "action" :depends-on ("session" "system" "operation"))
(:file "lisp-action" :depends-on ("action"))
(:file "find-component" :depends-on ("component"))
(:file "forcing" :depends-on ("operation" "system-registry"))
(:file "plan" :depends-on ("lisp-action" "find-component" "forcing"))
(:file "operate" :depends-on ("plan"))
(:file "find-system" :depends-on ("system-registry" "operate"))
(:file "parse-defsystem" :depends-on ("system-registry" "lisp-action" "operate"
"find-system"))
(:file "bundle" :depends-on ("lisp-action" "parse-defsystem"))
(:file "concatenate-source" :depends-on ("bundle"))
(:file "package-inferred-system" :depends-on ("parse-defsystem"))
(:file "output-translations" :depends-on ("operate"))
(:file "source-registry" :depends-on ("find-system"))
(:file "backward-internals" :depends-on ("find-system" "parse-defsystem"))
(:file "backward-interface" :depends-on ("output-translations"))
(:file "interface" :depends-on
("parse-defsystem" "concatenate-source"
"output-translations" "source-registry" "package-inferred-system"
"backward-interface" "backward-internals"))
(:file "user" :depends-on ("interface"))
(:file "footer" :depends-on ("user"))))
(defsystem "asdf"
:author ("Daniel Barlow")
:maintainer ("Robert Goldman")
:licence "MIT"
:description "Another System Definition Facility"
:long-description "ASDF builds Common Lisp software organized into defined systems."
:version "3.3.4" ;; to be automatically updated by make bump-version
:depends-on ()
:components ((:module "build" :components ((:file "asdf"))))
. #-asdf3 () #+asdf3
(:encoding :utf-8
:class #+asdf3.1 package-inferred-system #-asdf3.1 system
;; For most purposes, asdf itself specially counts as a builtin system.
;; If you want to link it or do something forbidden to builtin systems,
;; specify separate dependencies on uiop (aka asdf/driver) and asdf/defsystem.
:builtin-system-p t
:in-order-to ((prepare-op (monolithic-concatenate-source-op "asdf/defsystem")))))
asdf-3.3.4/backward-interface.lisp 0000664 0000000 0000000 00000035166 13621551153 0017060 0 ustar 00root root 0000000 0000000 ;;;; -------------------------------------------------------------------------
;;; Backward-compatible interfaces
(uiop/package:define-package :asdf/backward-interface
(:recycle :asdf/backward-interface :asdf)
(:use :uiop/common-lisp :uiop :asdf/upgrade :asdf/session
:asdf/component :asdf/system :asdf/system-registry :asdf/operation :asdf/action
:asdf/lisp-action :asdf/plan :asdf/operate
:asdf/find-system :asdf/parse-defsystem :asdf/output-translations :asdf/bundle)
(:export
#:*asdf-verbose*
#:operation-error #:compile-error #:compile-failed #:compile-warned
#:error-component #:error-operation #:traverse
#:component-load-dependencies
#:enable-asdf-binary-locations-compatibility
#:operation-on-failure #:operation-on-warnings #:on-failure #:on-warnings
#:component-property
#:run-shell-command
#:system-definition-pathname #:system-registered-p #:require-system
#:explain
#+ecl #:make-build))
(in-package :asdf/backward-interface)
;; NB: the warning status of these functions may have to be distinguished later,
;; as some get removed faster than the others in client code.
(with-asdf-deprecation (:style-warning "3.2" :warning "3.4")
;; These conditions from ASDF 1 and 2 are used by many packages in Quicklisp;
;; but ASDF3 replaced them with somewhat different variants of uiop:compile-condition
;; that do not involve ASDF actions.
;; TODO: find the offenders and stop them.
(progn
(define-condition operation-error (error) ;; Bad, backward-compatible name
;; Used by SBCL, cffi-tests, clsql-mysql, clsql-uffi, qt, elephant, uffi-tests, sb-grovel
((component :reader error-component :initarg :component)
(operation :reader error-operation :initarg :operation))
(:report (lambda (c s)
(format s (compatfmt "~@<~A while invoking ~A on ~A~@:>")
(type-of c) (error-operation c) (error-component c)))))
(define-condition compile-error (operation-error) ())
(define-condition compile-failed (compile-error) ())
(define-condition compile-warned (compile-error) ()))
;; In Quicklisp 2015-05, still used by lisp-executable, staple, repl-utilities, cffi
(defun component-load-dependencies (component) ;; from ASDF 2.000 to 2.26
"DEPRECATED. Please use COMPONENT-SIDEWAY-DEPENDENCIES instead; or better,
define your operations with proper use of SIDEWAY-OPERATION, SELFWARD-OPERATION,
or define methods on PREPARE-OP, etc."
;; Old deprecated name for the same thing. Please update your software.
(component-sideway-dependencies component))
;; These old interfaces from ASDF1 have never been very meaningful
;; but are still used in obscure places.
;; In Quicklisp 2015-05, still used by cl-protobufs and clx.
(defgeneric operation-on-warnings (operation)
(:documentation "DEPRECATED. Please use UIOP:*COMPILE-FILE-WARNINGS-BEHAVIOUR* instead."))
(defgeneric operation-on-failure (operation)
(:documentation "DEPRECATED. Please use UIOP:*COMPILE-FILE-FAILURE-BEHAVIOUR* instead."))
(defgeneric (setf operation-on-warnings) (x operation)
(:documentation "DEPRECATED. Please SETF UIOP:*COMPILE-FILE-WARNINGS-BEHAVIOUR* instead."))
(defgeneric (setf operation-on-failure) (x operation)
(:documentation "DEPRECATED. Please SETF UIOP:*COMPILE-FILE-FAILURE-BEHAVIOUR* instead."))
(progn
(defmethod operation-on-warnings ((o operation))
*compile-file-warnings-behaviour*)
(defmethod operation-on-failure ((o operation))
*compile-file-failure-behaviour*)
(defmethod (setf operation-on-warnings) (x (o operation))
(setf *compile-file-warnings-behaviour* x))
(defmethod (setf operation-on-failure) (x (o operation))
(setf *compile-file-failure-behaviour* x)))
;; Quicklisp 2015-05: Still used by SLIME's swank-asdf (!), common-lisp-stat,
;; js-parser, osicat, babel, staple, weblocks, cl-png, plain-odbc, autoproject,
;; cl-blapack, com.informatimago, cells-gtk3, asdf-dependency-grovel,
;; cl-glfw, cffi, jwacs, montezuma
(defun system-definition-pathname (x)
;; As of 2.014.8, we mean to make this function obsolete,
;; but that won't happen until all clients have been updated.
"DEPRECATED. This function used to expose ASDF internals with subtle
differences with respect to user expectations, that have been refactored
away since. We recommend you use ASDF:SYSTEM-SOURCE-FILE instead for a
mostly compatible replacement that we're supporting, or even
ASDF:SYSTEM-SOURCE-DIRECTORY or ASDF:SYSTEM-RELATIVE-PATHNAME
if that's whay you mean." ;;)
(system-source-file x))
;; TRAVERSE is the function used to compute a plan in ASDF 1 and 2.
;; It was never officially exposed but some people still used it.
(defgeneric traverse (operation component &key &allow-other-keys)
(:documentation
"DEPRECATED. Use MAKE-PLAN and PLAN-ACTIONS, or REQUIRED-COMPONENTS,
or some other supported interface instead.
Generate and return a plan for performing OPERATION on COMPONENT.
The plan returned is a list of dotted-pairs. Each pair is the CONS
of ASDF operation object and a COMPONENT object. The pairs will be
processed in order by OPERATE."))
(progn
(define-convenience-action-methods traverse (operation component &key)))
(defmethod traverse ((o operation) (c component) &rest keys &key plan-class &allow-other-keys)
(plan-actions (apply 'make-plan plan-class o c keys)))
;; ASDF-Binary-Locations compatibility
;; This remains supported for legacy user, but not recommended for new users.
;; We suspect there are no more legacy users in 2016.
(defun enable-asdf-binary-locations-compatibility
(&key
(centralize-lisp-binaries nil)
(default-toplevel-directory
;; Use ".cache/common-lisp/" instead ???
(subpathname (user-homedir-pathname) ".fasls/"))
(include-per-user-information nil)
(map-all-source-files (or #+(or clasp clisp ecl mkcl) t nil))
(source-to-target-mappings nil)
(file-types `(,(compile-file-type)
"build-report"
#+clasp (compile-file-type :output-type :object)
#+ecl (compile-file-type :type :object)
#+mkcl (compile-file-type :fasl-p nil)
#+clisp "lib" #+sbcl "cfasl"
#+sbcl "sbcl-warnings" #+clozure "ccl-warnings")))
"DEPRECATED. Use asdf-output-translations instead."
#+(or clasp clisp ecl mkcl)
(when (null map-all-source-files)
(error "asdf:enable-asdf-binary-locations-compatibility doesn't support :map-all-source-files nil on CLISP, ECL and MKCL"))
(let* ((patterns (if map-all-source-files (list *wild-file*)
(loop :for type :in file-types
:collect (make-pathname :type type :defaults *wild-file*))))
(destination-directory
(if centralize-lisp-binaries
`(,default-toplevel-directory
,@(when include-per-user-information
(cdr (pathname-directory (user-homedir-pathname))))
:implementation ,*wild-inferiors*)
`(:root ,*wild-inferiors* :implementation))))
(initialize-output-translations
`(:output-translations
,@source-to-target-mappings
#+abcl (#p"jar:file:/**/*.jar!/**/*.*" (:function translate-jar-pathname))
#+abcl (#p"/___jar___file___root___/**/*.*" (,@destination-directory))
,@(loop :for pattern :in patterns
:collect `((:root ,*wild-inferiors* ,pattern)
(,@destination-directory ,pattern)))
(t t)
:ignore-inherited-configuration))))
(progn
(defmethod operate :before (operation-class system &rest args &key &allow-other-keys)
(declare (ignore operation-class system args))
(when (find-symbol* '#:output-files-for-system-and-operation :asdf nil)
(error "ASDF 2 is not compatible with ASDF-BINARY-LOCATIONS, which you are using.
ASDF 2 now achieves the same purpose with its builtin ASDF-OUTPUT-TRANSLATIONS,
which should be easier to configure. Please stop using ASDF-BINARY-LOCATIONS,
and instead use ASDF-OUTPUT-TRANSLATIONS. See the ASDF manual for details.
In case you insist on preserving your previous A-B-L configuration, but
do not know how to achieve the same effect with A-O-T, you may use function
ASDF:ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY as documented in the manual;
call that function where you would otherwise have loaded and configured A-B-L."))))
;; run-shell-command from ASDF 2, lightly fixed from ASDF 1, copied from MK-DEFSYSTEM. Die!
(defun run-shell-command (control-string &rest args)
"PLEASE DO NOT USE. This function is not just DEPRECATED, but also dysfunctional.
Please use UIOP:RUN-PROGRAM instead."
#-(and ecl os-windows)
(let ((command (apply 'format nil control-string args)))
(asdf-message "; $ ~A~%" command)
(let ((exit-code
(ignore-errors
(nth-value 2 (run-program command :force-shell t :ignore-error-status t
:output *verbose-out*)))))
(typecase exit-code
((integer 0 255) exit-code)
(t 255))))
#+(and ecl os-windows)
(not-implemented-error "run-shell-command" "for ECL on Windows."))
;; HOW do we get rid of variables??? With a symbol-macro that issues a warning?
;; In Quicklisp 2015-05, cl-protobufs still uses it, but that should be fixed in next version.
(progn
(defvar *asdf-verbose* nil)) ;; backward-compatibility with ASDF2 only. Unused.
;; Do NOT use in new code. NOT SUPPORTED.
;; NB: When this goes away, remove the slot PROPERTY in COMPONENT.
;; In Quicklisp 2014-05, it's still used by yaclml, amazon-ecs, blackthorn-engine, cl-tidy.
;; See TODO for further cleanups required before to get rid of it.
(defgeneric component-property (component property))
(defgeneric (setf component-property) (new-value component property))
(defmethod component-property ((c component) property)
(cdr (assoc property (slot-value c 'properties) :test #'equal)))
(defmethod (setf component-property) (new-value (c component) property)
(let ((a (assoc property (slot-value c 'properties) :test #'equal)))
(if a
(setf (cdr a) new-value)
(setf (slot-value c 'properties)
(acons property new-value (slot-value c 'properties)))))
new-value)
;; This method survives from ASDF 1, but really it is superseded by action-description.
(defgeneric explain (operation component)
(:documentation "Display a message describing an action.
DEPRECATED. Use ASDF:ACTION-DESCRIPTION and/or ASDF::FORMAT-ACTION instead."))
(progn
(define-convenience-action-methods explain (operation component)))
(defmethod explain ((o operation) (c component))
(asdf-message (compatfmt "~&~@<; ~@;~A~:>~%") (action-description o c))))
(with-asdf-deprecation (:style-warning "3.3")
(defun system-registered-p (name)
"DEPRECATED. Return a generalized boolean that is true if a system of given NAME was registered already.
NAME is a system designator, to be normalized by COERCE-NAME.
The value returned if true is a pair of a timestamp and a system object."
(if-let (system (registered-system name))
(cons (if-let (primary-system (registered-system (primary-system-name name)))
(component-operation-time 'define-op primary-system))
system)))
(defun require-system (system &rest keys &key &allow-other-keys)
"Ensure the specified SYSTEM is loaded, passing the KEYS to OPERATE, but do not update the
system or its dependencies if it has already been loaded."
(declare (ignore keys))
(unless (component-loaded-p system)
(load-system system))))
;;; This function is for backward compatibility with ECL only.
#+ecl
(with-asdf-deprecation (:style-warning "3.2" :warning "9999")
(defun make-build (system &rest args
&key (monolithic nil) (type :fasl) (move-here nil move-here-p)
prologue-code epilogue-code no-uiop
prefix-lisp-object-files postfix-lisp-object-files extra-object-files
&allow-other-keys)
(let* ((operation (asdf/bundle::select-bundle-operation type monolithic))
(move-here-path (if (and move-here
(typep move-here '(or pathname string)))
(ensure-pathname move-here :namestring :lisp :ensure-directory t)
(system-relative-pathname system "asdf-output/")))
(extra-build-args (remove-plist-keys
'(:monolithic :type :move-here
:prologue-code :epilogue-code :no-uiop
:prefix-lisp-object-files :postfix-lisp-object-files
:extra-object-files)
args))
(build-system (if (subtypep operation 'image-op)
(eval `(defsystem "asdf.make-build"
:class program-system
:source-file nil
:pathname ,(system-source-directory system)
:build-operation ,operation
:build-pathname ,(subpathname move-here-path
(file-namestring (first (output-files operation system))))
:depends-on (,(coerce-name system))
:prologue-code ,prologue-code
:epilogue-code ,epilogue-code
:no-uiop ,no-uiop
:prefix-lisp-object-files ,prefix-lisp-object-files
:postfix-lisp-object-files ,postfix-lisp-object-files
:extra-object-files ,extra-object-files
:extra-build-args ,extra-build-args))
system))
(files (output-files operation build-system)))
(operate operation build-system)
(if (or move-here
(and (null move-here-p) (member operation '(program-op image-op))))
(loop :with dest-path = (resolve-symlinks* (ensure-directories-exist move-here-path))
:for f :in files
:for new-f = (make-pathname :name (pathname-name f)
:type (pathname-type f)
:defaults dest-path)
:do (rename-file-overwriting-target f new-f)
:collect new-f)
files))))
asdf-3.3.4/backward-internals.lisp 0000664 0000000 0000000 00000001202 13621551153 0017077 0 ustar 00root root 0000000 0000000 ;;;; -------------------------------------------------------------------------
;;; Internal hacks for backward-compatibility
(uiop/package:define-package :asdf/backward-internals
(:recycle :asdf/backward-internals :asdf)
(:use :uiop/common-lisp :uiop :asdf/upgrade :asdf/find-system)
(:export #:load-sysdef))
(in-package :asdf/backward-internals)
(with-asdf-deprecation (:style-warning "3.2" :warning "3.4")
(defun load-sysdef (name pathname)
(declare (ignore name pathname))
;; Needed for backward compatibility with swank-asdf from SLIME 2015-12-01 or older.
(error "Use asdf:load-asd instead of asdf::load-sysdef")))
asdf-3.3.4/bin/ 0000775 0000000 0000000 00000000000 13621551153 0013210 5 ustar 00root root 0000000 0000000 asdf-3.3.4/bin/bump-version 0000775 0000000 0000000 00000005123 13621551153 0015565 0 ustar 00root root 0000000 0000000 #! /usr/bin/env perl
use FindBin;
use Getopt::Long;
our $old;
our $new;
our $usage = 0;
&GetOptions("help"=>\$usage,
"usage"=>\$usage);
if ($usage) {
print "$0 [old-version] [new-version]\n";
print "\tIf only one argument, treat it as the new version argument.\n";
print "\tIf two arguments treat the first as old version number and second as new.\n";
print "\n\tBumps the version numbers in all the relevant files.\n";
exit 0;
}
our $asdf_dir = $FindBin::RealBin . "/../";
our $file = $asdf_dir . "version.lisp-expr";
our @transform_ref =
(
[ "version.lisp-expr", "\"", "\"" ],
[ "uiop/version.lisp", "(defparameter *uiop-version* \"", "\")" ],
[ "asdf.asd", " :version \"", "\" ;; to be automatically updated by make bump-version" ],
[ "header.lisp", "This is ASDF ", ": Another System Definition Facility." ],
[ "upgrade.lisp", "(asdf-version \"", "\")" ],
[ "doc/asdf.texinfo", "Manual for Version ", "" ], );
if ($#ARGV == 1) {
$old = $ARGV[0];
$new = $ARGV[1];
} elsif ($#ARGV == 0) {
$new = $ARGV[0];
$old = read_asdf_version();
} else {
$old = read_asdf_version();
$new = bump_asdf_version($old);
}
print STDERR "Bumping from $old to $new\n";
transform_files();
sub read_asdf_version {
open(FILE, $file);
my $str = ;
chomp $str;
print STDERR "Read version string $str from $file\n";
close FILE;
$str =~ s/"//g;
return $str;
}
sub bump_asdf_version {
my $oldver = shift;
my @fields = split/\./, $oldver;
$fields[$#fields]++;
return join('.', @fields);
}
sub transform_files {
foreach my $entryptr (@transform_ref) {
my @entry = @{$entryptr};
my $file = $entry[0];
print STDERR "Modifying file $file\n";
print STDERR "Prefix is $entry[1], suffix is $entry[2]\n";
my $regex = "(" . quotemeta($entry[1]) . ")" . "((\\d+\\.)+\\d+)" . "(" . quotemeta($entry[2]) .")";
my $filename = $asdf_dir . $file;
my $data = read_text($filename);
my $count = ($data =~ s/$regex/$1$new$4/g);
if ($count == 0) {
die "Unable to replace $regex with $1$new$4";
}
# print STDERR "Writing $data to $filename\n";
write_text($filename, $data);
}
}
# can't reliably find File::Slurper, or File::Slurp, so do it
# old school.
sub read_text ($) {
my $fn = shift;
local $/ = undef;
open READFILE, $fn or die "Couldn't open file: $fn";
binmode READFILE;
my $string = ;
close READFILE;
return $string;
}
sub write_text ($$) {
my $fn = shift;
my $data = shift;
open WRITEFILE, "> $fn" or die "Couldn't open $fn for writing.";
print WRITEFILE $data;
close WRITEFILE;
return 1;
}
asdf-3.3.4/bundle.lisp 0000664 0000000 0000000 00000071321 13621551153 0014606 0 ustar 00root root 0000000 0000000 ;;;; -------------------------------------------------------------------------
;;;; ASDF-Bundle
(uiop/package:define-package :asdf/bundle
(:recycle :asdf/bundle :asdf)
(:use :uiop/common-lisp :uiop :asdf/upgrade
:asdf/component :asdf/system :asdf/operation
:asdf/find-component ;; used by ECL
:asdf/action :asdf/lisp-action :asdf/plan :asdf/operate :asdf/parse-defsystem)
(:export
#:bundle-op #:bundle-type #:program-system
#:bundle-system #:bundle-pathname-type #:direct-dependency-files
#:monolithic-op #:monolithic-bundle-op #:operation-monolithic-p
#:basic-compile-bundle-op #:prepare-bundle-op
#:compile-bundle-op #:load-bundle-op #:monolithic-compile-bundle-op #:monolithic-load-bundle-op
#:lib-op #:monolithic-lib-op
#:dll-op #:monolithic-dll-op
#:deliver-asd-op #:monolithic-deliver-asd-op
#:program-op #:image-op #:compiled-file #:precompiled-system #:prebuilt-system
#:user-system-p #:user-system #:trivial-system-p
#:prologue-code #:epilogue-code #:static-library))
(in-package :asdf/bundle)
(with-upgradability ()
(defclass bundle-op (operation) ()
(:documentation "base class for operations that bundle outputs from multiple components"))
(defgeneric bundle-type (bundle-op))
(defclass monolithic-op (operation) ()
(:documentation "A MONOLITHIC operation operates on a system *and all of its
dependencies*. So, for example, a monolithic concatenate operation will
concatenate together a system's components and all of its dependencies, but a
simple concatenate operation will concatenate only the components of the system
itself."))
(defclass monolithic-bundle-op (bundle-op monolithic-op)
;; Old style way of specifying prologue and epilogue on ECL: in the monolithic operation.
;; DEPRECATED. Supported replacement: Define slots on program-system instead.
((prologue-code :initform nil :accessor prologue-code)
(epilogue-code :initform nil :accessor epilogue-code))
(:documentation "operations that are both monolithic-op and bundle-op"))
(defclass program-system (system)
;; New style (ASDF3.1) way of specifying prologue and epilogue on ECL: in the system
((prologue-code :initform nil :initarg :prologue-code :reader prologue-code)
(epilogue-code :initform nil :initarg :epilogue-code :reader epilogue-code)
(no-uiop :initform nil :initarg :no-uiop :reader no-uiop)
(prefix-lisp-object-files :initarg :prefix-lisp-object-files
:initform nil :accessor prefix-lisp-object-files)
(postfix-lisp-object-files :initarg :postfix-lisp-object-files
:initform nil :accessor postfix-lisp-object-files)
(extra-object-files :initarg :extra-object-files
:initform nil :accessor extra-object-files)
(extra-build-args :initarg :extra-build-args
:initform nil :accessor extra-build-args)))
(defmethod prologue-code ((x system)) nil)
(defmethod epilogue-code ((x system)) nil)
(defmethod no-uiop ((x system)) nil)
(defmethod prefix-lisp-object-files ((x system)) nil)
(defmethod postfix-lisp-object-files ((x system)) nil)
(defmethod extra-object-files ((x system)) nil)
(defmethod extra-build-args ((x system)) nil)
(defclass link-op (bundle-op) ()
(:documentation "Abstract operation for linking files together"))
(defclass gather-operation (bundle-op) ()
(:documentation "Abstract operation for gathering many input files from a system"))
(defgeneric gather-operation (gather-operation))
(defmethod gather-operation ((o gather-operation)) nil)
(defgeneric gather-type (gather-operation))
(defun operation-monolithic-p (op)
(typep op 'monolithic-op))
;; Dependencies of a gather-op are the actions of the dependent operation
;; for all the (sorted) required components for loading the system.
;; Monolithic operations typically use lib-op as the dependent operation,
;; and all system-level dependencies as required components.
;; Non-monolithic operations typically use compile-op as the dependent operation,
;; and all transitive sub-components as required components (excluding other systems).
(defmethod component-depends-on ((o gather-operation) (s system))
(let* ((mono (operation-monolithic-p o))
(go (make-operation (or (gather-operation o) 'compile-op)))
(bundle-p (typep go 'bundle-op))
;; In a non-mono operation, don't recurse to other systems.
;; In a mono operation gathering bundles, don't recurse inside systems.
(component-type (if mono (if bundle-p 'system t) '(not system)))
;; In the end, only keep system bundles or non-system bundles, depending.
(keep-component (if bundle-p 'system '(not system)))
(deps
;; Required-components only looks at the dependencies of an action, excluding the action
;; itself, so it may be safely used by an action recursing on its dependencies (which
;; may or may not be an overdesigned API, since in practice we never use it that way).
;; Therefore, if we use :goal-operation 'load-op :keep-operation 'load-op, which looks
;; cleaner, we will miss the load-op on the requested system itself, which doesn't
;; matter for a regular system, but matters, a lot, for a package-inferred-system.
;; Using load-op as the goal operation and basic-compile-op as the keep-operation works
;; for our needs of gathering all the files we want to include in a bundle.
;; Note that we use basic-compile-op rather than compile-op so it will still work on
;; systems that would somehow load dependencies with load-bundle-op.
(required-components
s :other-systems mono :component-type component-type :keep-component keep-component
:goal-operation 'load-op :keep-operation 'basic-compile-op)))
`((,go ,@deps) ,@(call-next-method))))
;; Create a single fasl for the entire library
(defclass basic-compile-bundle-op (bundle-op basic-compile-op) ()
(:documentation "Base class for compiling into a bundle"))
(defmethod bundle-type ((o basic-compile-bundle-op)) :fasb)
(defmethod gather-type ((o basic-compile-bundle-op))
#-(or clasp ecl mkcl) :fasl
#+(or clasp ecl mkcl) :object)
;; Analog to prepare-op, for load-bundle-op and compile-bundle-op
(defclass prepare-bundle-op (sideway-operation)
((sideway-operation
:initform #+(or clasp ecl mkcl) 'load-bundle-op #-(or clasp ecl mkcl) 'load-op
:allocation :class))
(:documentation "Operation class for loading the bundles of a system's dependencies"))
(defclass lib-op (link-op gather-operation non-propagating-operation) ()
(:documentation "Compile the system and produce a linkable static library (.a/.lib)
for all the linkable object files associated with the system. Compare with DLL-OP.
On most implementations, these object files only include extensions to the runtime
written in C or another language with a compiler producing linkable object files.
On CLASP, ECL, MKCL, these object files _also_ include the contents of Lisp files
themselves. In any case, this operation will produce what you need to further build
a static runtime for your system, or a dynamic library to load in an existing runtime."))
(defmethod bundle-type ((o lib-op)) :lib)
(defmethod gather-type ((o lib-op)) :object)
;; What works: on ECL, CLASP(?), MKCL, we link the many .o files from the system into the .so;
;; on other implementations, we combine (usually concatenate) the .fasl files into one.
(defclass compile-bundle-op (basic-compile-bundle-op selfward-operation gather-operation
#+(or clasp ecl mkcl) link-op)
((selfward-operation :initform '(prepare-bundle-op) :allocation :class))
(:documentation "This operator is an alternative to COMPILE-OP. Build a system
and all of its dependencies, but build only a single (\"monolithic\") FASL, instead
of one per source file, which may be more resource efficient. That monolithic
FASL should be loaded with LOAD-BUNDLE-OP, rather than LOAD-OP."))
(defclass load-bundle-op (basic-load-op selfward-operation)
((selfward-operation :initform '(prepare-bundle-op compile-bundle-op) :allocation :class))
(:documentation "This operator is an alternative to LOAD-OP. Build a system
and all of its dependencies, using COMPILE-BUNDLE-OP. The difference with
respect to LOAD-OP is that it builds only a single FASL, which may be
faster and more resource efficient."))
;; NB: since the monolithic-op's can't be sideway-operation's,
;; if we wanted lib-op, dll-op, deliver-asd-op to be sideway-operation's,
;; we'd have to have the monolithic-op not inherit from the main op,
;; but instead inherit from a basic-FOO-op as with basic-compile-bundle-op above.
(defclass dll-op (link-op gather-operation non-propagating-operation) ()
(:documentation "Compile the system and produce a dynamic loadable library (.so/.dll)
for all the linkable object files associated with the system. Compare with LIB-OP."))
(defmethod bundle-type ((o dll-op)) :dll)
(defmethod gather-type ((o dll-op)) :object)
(defclass deliver-asd-op (basic-compile-op selfward-operation)
((selfward-operation
;; TODO: implement link-op on all implementations, and make that
;; '(compile-bundle-op lib-op #-(or clasp ecl mkcl) dll-op)
:initform '(compile-bundle-op #+(or clasp ecl mkcl) lib-op)
:allocation :class))
(:documentation "produce an asd file for delivering the system as a single fasl"))
(defclass monolithic-deliver-asd-op (deliver-asd-op monolithic-bundle-op)
((selfward-operation
;; TODO: implement link-op on all implementations, and make that
;; '(monolithic-compile-bundle-op monolithic-lib-op #-(or clasp ecl mkcl) monolithic-dll-op)
:initform '(monolithic-compile-bundle-op #+(or clasp ecl mkcl) monolithic-lib-op)
:allocation :class))
(:documentation "produce fasl and asd files for combined system and dependencies."))
(defclass monolithic-compile-bundle-op
(basic-compile-bundle-op monolithic-bundle-op
#+(or clasp ecl mkcl) link-op gather-operation non-propagating-operation)
()
(:documentation "Create a single fasl for the system and its dependencies."))
(defclass monolithic-load-bundle-op (load-bundle-op monolithic-bundle-op)
((selfward-operation :initform 'monolithic-compile-bundle-op :allocation :class))
(:documentation "Load a single fasl for the system and its dependencies."))
(defclass monolithic-lib-op (lib-op monolithic-bundle-op non-propagating-operation) ()
(:documentation "Compile the system and produce a linkable static library (.a/.lib)
for all the linkable object files associated with the system or its dependencies. See LIB-OP."))
(defclass monolithic-dll-op (dll-op monolithic-bundle-op non-propagating-operation) ()
(:documentation "Compile the system and produce a dynamic loadable library (.so/.dll)
for all the linkable object files associated with the system or its dependencies. See LIB-OP"))
(defclass image-op (monolithic-bundle-op selfward-operation
#+(or clasp ecl mkcl) link-op #+(or clasp ecl mkcl) gather-operation)
((selfward-operation :initform '(#-(or clasp ecl mkcl) load-op) :allocation :class))
(:documentation "create an image file from the system and its dependencies"))
(defmethod bundle-type ((o image-op)) :image)
#+(or clasp ecl mkcl) (defmethod gather-operation ((o image-op)) 'lib-op)
#+(or clasp ecl mkcl) (defmethod gather-type ((o image-op)) :static-library)
(defclass program-op (image-op) ()
(:documentation "create an executable file from the system and its dependencies"))
(defmethod bundle-type ((o program-op)) :program)
;; From the ASDF-internal bundle-type identifier, get a filesystem-usable pathname type.
(defun bundle-pathname-type (bundle-type)
(etypecase bundle-type
((or null string) ;; pass through nil or string literal
bundle-type)
((eql :no-output-file) ;; marker for a bundle-type that has NO output file
(error "No output file, therefore no pathname type"))
((eql :fasl) ;; the type of a fasl
(compile-file-type)) ; on image-based platforms, used as input and output
((eql :fasb) ;; the type of a fasl
#-(or clasp ecl mkcl) (compile-file-type) ; on image-based platforms, used as input and output
#+(or clasp ecl mkcl) "fasb") ; on C-linking platforms, only used as output for system bundles
((member :image)
#+allegro "dxl"
#+(and clisp os-windows) "exe"
#-(or allegro (and clisp os-windows)) "image")
;; NB: on CLASP and ECL these implementations, we better agree with
;; (compile-file-type :type bundle-type))
((eql :object) ;; the type of a linkable object file
(os-cond ((os-unix-p) "o")
((os-windows-p) (if (featurep '(:or :mingw32 :mingw64)) "o" "obj"))))
((member :lib :static-library) ;; the type of a linkable library
(os-cond ((os-unix-p) "a")
((os-windows-p) (if (featurep '(:or :mingw32 :mingw64)) "a" "lib"))))
((member :dll :shared-library) ;; the type of a shared library
(os-cond ((os-macosx-p) "dylib") ((os-unix-p) "so") ((os-windows-p) "dll")))
((eql :program) ;; the type of an executable program
(os-cond ((os-unix-p) nil) ((os-windows-p) "exe")))))
;; Compute the output-files for a given bundle action
(defun bundle-output-files (o c)
(let ((bundle-type (bundle-type o)))
(unless (or (eq bundle-type :no-output-file) ;; NIL already means something regarding type.
(and (null (input-files o c)) (not (member bundle-type '(:image :program)))))
(let ((name (or (component-build-pathname c)
(let ((suffix
(unless (typep o 'program-op)
;; "." is no good separator for Logical Pathnames, so we use "--"
(if (operation-monolithic-p o)
"--all-systems"
;; These use a different type .fasb or .a instead of .fasl
#-(or clasp ecl mkcl) "--system"))))
(format nil "~A~@[~A~]" (coerce-filename (component-name c)) suffix))))
(type (bundle-pathname-type bundle-type)))
(values (list (subpathname (component-pathname c) name :type type))
(eq (class-of o) (coerce-class (component-build-operation c)
:package :asdf/interface
:super 'operation
:error nil)))))))
(defmethod output-files ((o bundle-op) (c system))
(bundle-output-files o c))
#-(or clasp ecl mkcl)
(progn
(defmethod perform ((o image-op) (c system))
(dump-image (output-file o c) :executable (typep o 'program-op)))
(defmethod perform :before ((o program-op) (c system))
(setf *image-entry-point* (ensure-function (component-entry-point c)))))
(defclass compiled-file (file-component)
((type :initform #-(or clasp ecl mkcl) (compile-file-type) #+(or clasp ecl mkcl) "fasb"))
(:documentation "Class for a file that is already compiled,
e.g. as part of the implementation, of an outer build system that calls into ASDF,
or of opaque libraries shipped along the source code."))
(defclass precompiled-system (system)
((build-pathname :initarg :fasb :initarg :fasl))
(:documentation "Class For a system that is delivered as a precompiled fasl"))
(defclass prebuilt-system (system)
((build-pathname :initarg :static-library :initarg :lib
:accessor prebuilt-system-static-library))
(:documentation "Class for a system delivered with a linkable static library (.a/.lib)")))
;;;
;;; BUNDLE-OP
;;;
;;; This operation takes all components from one or more systems and
;;; creates a single output file, which may be
;;; a FASL, a statically linked library, a shared library, etc.
;;; The different targets are defined by specialization.
;;;
(when-upgrading (:version "3.2.0")
;; Cancel any previously defined method
(defmethod initialize-instance :after ((instance bundle-op) &rest initargs &key &allow-other-keys)
(declare (ignore initargs))))
(with-upgradability ()
(defgeneric trivial-system-p (component))
(defun user-system-p (s)
(and (typep s 'system)
(not (builtin-system-p s))
(not (trivial-system-p s)))))
(eval-when (#-lispworks :compile-toplevel :load-toplevel :execute)
(deftype user-system () '(and system (satisfies user-system-p))))
;;;
;;; First we handle monolithic bundles.
;;; These are standalone systems which contain everything,
;;; including other ASDF systems required by the current one.
;;; A PROGRAM is always monolithic.
;;;
;;; MONOLITHIC SHARED LIBRARIES, PROGRAMS, FASL
;;;
(with-upgradability ()
(defun direct-dependency-files (o c &key (test 'identity) (key 'output-files) &allow-other-keys)
;; This function selects output files from direct dependencies;
;; your component-depends-on method must gather the correct dependencies in the correct order.
(while-collecting (collect)
(map-direct-dependencies
o c #'(lambda (sub-o sub-c)
(loop :for f :in (funcall key sub-o sub-c)
:when (funcall test f) :do (collect f))))))
(defun pathname-type-equal-function (type)
#'(lambda (p) (equalp (pathname-type p) type)))
(defmethod input-files ((o gather-operation) (c system))
(unless (eq (bundle-type o) :no-output-file)
(direct-dependency-files
o c :key 'output-files
:test (pathname-type-equal-function (bundle-pathname-type (gather-type o))))))
;; Find the operation that produces a given bundle-type
(defun select-bundle-operation (type &optional monolithic)
(ecase type
((:dll :shared-library)
(if monolithic 'monolithic-dll-op 'dll-op))
((:lib :static-library)
(if monolithic 'monolithic-lib-op 'lib-op))
((:fasb)
(if monolithic 'monolithic-compile-bundle-op 'compile-bundle-op))
((:image)
'image-op)
((:program)
'program-op))))
;;;
;;; LOAD-BUNDLE-OP
;;;
;;; This is like ASDF's LOAD-OP, but using bundle fasl files.
;;;
(with-upgradability ()
(defmethod component-depends-on ((o load-bundle-op) (c system))
`((,o ,@(component-sideway-dependencies c))
(,(if (user-system-p c) 'compile-bundle-op 'load-op) ,c)
,@(call-next-method)))
(defmethod input-files ((o load-bundle-op) (c system))
(when (user-system-p c)
(output-files (find-operation o 'compile-bundle-op) c)))
(defmethod perform ((o load-bundle-op) (c system))
(when (input-files o c)
(perform-lisp-load-fasl o c)))
(defmethod mark-operation-done :after ((o load-bundle-op) (c system))
(mark-operation-done (find-operation o 'load-op) c)))
;;;
;;; PRECOMPILED FILES
;;;
;;; This component can be used to distribute ASDF systems in precompiled form.
;;; Only useful when the dependencies have also been precompiled.
;;;
(with-upgradability ()
(defmethod trivial-system-p ((s system))
(every #'(lambda (c) (typep c 'compiled-file)) (component-children s)))
(defmethod input-files ((o operation) (c compiled-file))
(list (component-pathname c)))
(defmethod perform ((o load-op) (c compiled-file))
(perform-lisp-load-fasl o c))
(defmethod perform ((o load-source-op) (c compiled-file))
(perform (find-operation o 'load-op) c))
(defmethod perform ((o operation) (c compiled-file))
nil))
;;;
;;; Pre-built systems
;;;
(with-upgradability ()
(defmethod trivial-system-p ((s prebuilt-system))
t)
(defmethod perform ((o link-op) (c prebuilt-system))
nil)
(defmethod perform ((o basic-compile-bundle-op) (c prebuilt-system))
nil)
(defmethod perform ((o lib-op) (c prebuilt-system))
nil)
(defmethod perform ((o dll-op) (c prebuilt-system))
nil)
(defmethod component-depends-on ((o gather-operation) (c prebuilt-system))
nil)
(defmethod output-files ((o lib-op) (c prebuilt-system))
(values (list (prebuilt-system-static-library c)) t)))
;;;
;;; PREBUILT SYSTEM CREATOR
;;;
(with-upgradability ()
(defmethod output-files ((o deliver-asd-op) (s system))
(list (make-pathname :name (coerce-filename (component-name s)) :type "asd"
:defaults (component-pathname s))))
;; because of name collisions between the output files of different
;; subclasses of DELIVER-ASD-OP, we cannot trust the file system to
;; tell us if the output file is up-to-date, so just treat the
;; operation as never being done.
(defmethod operation-done-p ((o deliver-asd-op) (s system))
(declare (ignorable o s))
nil)
(defmethod perform ((o deliver-asd-op) (s system))
"Write an ASDF system definition for loading S as a delivered system."
(let* ((inputs (input-files o s))
(fasl (first inputs))
(library (second inputs))
(asd (output-file o s))
(name (if (and fasl asd) (pathname-name asd) (return-from perform)))
(version (component-version s))
(dependencies
(if (operation-monolithic-p o)
;; We want only dependencies, and we use basic-load-op rather than load-op so that
;; this will keep working on systems that load dependencies with load-bundle-op
(remove-if-not 'builtin-system-p
(required-components s :component-type 'system
:keep-operation 'basic-load-op))
(while-collecting (x) ;; resolve the sideway-dependencies of s
(map-direct-dependencies
'prepare-op s
#'(lambda (o c)
(when (and (typep o 'load-op) (typep c 'system))
(x c)))))))
(depends-on (mapcar 'coerce-name dependencies)))
(when (pathname-equal asd (system-source-file s))
(cerror "overwrite the asd file"
"~/asdf-action:format-action/ is going to overwrite the system definition file ~S ~
which is probably not what you want; you probably need to tweak your output translations."
(cons o s) asd))
(with-open-file (s asd :direction :output :if-exists :supersede
:if-does-not-exist :create)
(format s ";;; Prebuilt~:[~; monolithic~] ASDF definition for system ~A~%"
(operation-monolithic-p o) name)
;; this can cause bugs in cases where one of the functions returns a multi-line
;; string
(let ((description-string (format nil ";;; Built for ~A ~A on a ~A/~A ~A"
(lisp-implementation-type)
(lisp-implementation-version)
(software-type)
(machine-type)
(software-version))))
;; ensure the whole thing is on one line
(print (remove-if #'(lambda (x) (member x (list #\newline #\return))) description-string) s)
(terpri s))
(let ((*package* (find-package :asdf-user)))
(pprint `(defsystem ,name
:class prebuilt-system
:version ,version
:depends-on ,depends-on
:components ((:compiled-file ,(pathname-name fasl)))
,@(when library `(:lib ,(file-namestring library))))
s)
(terpri s)))))
#-(or clasp ecl mkcl)
(defmethod perform ((o basic-compile-bundle-op) (c system))
(let* ((input-files (input-files o c))
(fasl-files (remove (compile-file-type) input-files :key #'pathname-type :test-not #'equalp))
(non-fasl-files (remove (compile-file-type) input-files :key #'pathname-type :test #'equalp))
(output-files (output-files o c)) ; can't use OUTPUT-FILE fn because possibility it's NIL
(output-file (first output-files)))
(assert (eq (not input-files) (not output-files)))
(when input-files
(when non-fasl-files
(error "On ~A, asdf/bundle can only bundle FASL files, but these were also produced: ~S"
(implementation-type) non-fasl-files))
(when (or (prologue-code c) (epilogue-code c))
(error "prologue-code and epilogue-code are not supported on ~A"
(implementation-type)))
(with-staging-pathname (output-file)
(combine-fasls fasl-files output-file)))))
(defmethod input-files ((o load-op) (s precompiled-system))
(bundle-output-files (find-operation o 'compile-bundle-op) s))
(defmethod perform ((o load-op) (s precompiled-system))
(perform-lisp-load-fasl o s))
(defmethod component-depends-on ((o load-bundle-op) (s precompiled-system))
`((load-op ,s) ,@(call-next-method))))
#| ;; Example use:
(asdf:defsystem :precompiled-asdf-utils :class asdf::precompiled-system :fasl (asdf:apply-output-translations (asdf:system-relative-pathname :asdf-utils "asdf-utils.system.fasl")))
(asdf:load-system :precompiled-asdf-utils)
|#
#+(or clasp ecl mkcl)
(with-upgradability ()
(defun system-module-pathname (module)
(let ((name (coerce-name module)))
(some
'file-exists-p
(list
#+clasp (compile-file-pathname (make-pathname :name name :defaults "sys:") :output-type :object)
#+ecl (compile-file-pathname (make-pathname :name name :defaults "sys:") :type :lib)
#+ecl (compile-file-pathname (make-pathname :name (strcat "lib" name) :defaults "sys:") :type :lib)
#+ecl (compile-file-pathname (make-pathname :name name :defaults "sys:") :type :object)
#+mkcl (make-pathname :name name :type (bundle-pathname-type :lib) :defaults #p"sys:")
#+mkcl (make-pathname :name name :type (bundle-pathname-type :lib) :defaults #p"sys:contrib;")))))
(defun make-prebuilt-system (name &optional (pathname (system-module-pathname name)))
"Creates a prebuilt-system if PATHNAME isn't NIL."
(when pathname
(make-instance 'prebuilt-system
:name (coerce-name name)
:static-library (resolve-symlinks* pathname))))
(defun linkable-system (x)
(or ;; If the system is available as source, use it.
(if-let (s (find-system x))
(and (output-files 'lib-op s) s))
;; If an ASDF upgrade is available from source, but not a UIOP upgrade to that,
;; then use the asdf/driver system instead of
;; the UIOP that was disabled by check-not-old-asdf-system.
(if-let (s (and (equal (coerce-name x) "uiop")
(output-files 'lib-op "asdf")
(find-system "asdf/driver")))
(and (output-files 'lib-op s) s))
;; If there was no source upgrade, look for modules provided by the implementation.
(if-let (p (system-module-pathname (coerce-name x)))
(make-prebuilt-system x p))))
(defmethod component-depends-on :around ((o image-op) (c system))
(let* ((next (call-next-method))
(deps (make-hash-table :test 'equal))
(linkable (loop* :for (do . dcs) :in next :collect
(cons do
(loop :for dc :in dcs
:for dep = (and dc (resolve-dependency-spec c dc))
:when dep
:do (setf (gethash (coerce-name (component-system dep)) deps) t)
:collect (or (and (typep dep 'system) (linkable-system dep)) dep))))))
`((lib-op
,@(unless (no-uiop c)
(list (linkable-system "cmp")
(unless (or (and (gethash "uiop" deps) (linkable-system "uiop"))
(and (gethash "asdf" deps) (linkable-system "asdf")))
(or (linkable-system "uiop")
(linkable-system "asdf")
"asdf")))))
,@linkable)))
(defmethod perform ((o link-op) (c system))
(let* ((object-files (input-files o c))
(output (output-files o c))
(bundle (first output))
(programp (typep o 'program-op))
(kind (bundle-type o)))
(when output
(apply 'create-image
bundle (append
(when programp (prefix-lisp-object-files c))
object-files
(when programp (postfix-lisp-object-files c)))
:kind kind
:prologue-code (when programp (prologue-code c))
:epilogue-code (when programp (epilogue-code c))
:build-args (when programp (extra-build-args c))
:extra-object-files (when programp (extra-object-files c))
:no-uiop (no-uiop c)
(when programp `(:entry-point ,(component-entry-point c))))))))
asdf-3.3.4/component.lisp 0000664 0000000 0000000 00000041047 13621551153 0015341 0 ustar 00root root 0000000 0000000 ;;;; -------------------------------------------------------------------------
;;;; Components
(uiop/package:define-package :asdf/component
(:recycle :asdf/component :asdf/find-component :asdf)
(:use :uiop/common-lisp :uiop :asdf/upgrade :asdf/session)
(:export
#:component #:component-find-path
#:find-component ;; methods defined in find-component
#:component-name #:component-pathname #:component-relative-pathname
#:component-parent #:component-system #:component-parent-pathname
#:child-component #:parent-component #:module
#:file-component
#:source-file #:c-source-file #:java-source-file
#:static-file #:doc-file #:html-file
#:file-type
#:source-file-type #:source-file-explicit-type ;; backward-compatibility
#:component-in-order-to #:component-sideway-dependencies
#:component-if-feature #:around-compile-hook
#:component-description #:component-long-description
#:component-version #:version-satisfies
#:component-inline-methods ;; backward-compatibility only. DO NOT USE!
#:component-operation-times ;; For internal use only.
;; portable ASDF encoding and implementation-specific external-format
#:component-external-format #:component-encoding
#:component-children-by-name #:component-children #:compute-children-by-name
#:component-build-operation
#:module-default-component-class
#:module-components ;; backward-compatibility. DO NOT USE.
#:sub-components
;; conditions
#:duplicate-names
;; Internals we'd like to share with the ASDF package, especially for upgrade purposes
#:name #:version #:description #:long-description #:author #:maintainer #:licence
#:components-by-name #:components #:children #:children-by-name
#:default-component-class #:source-file
#:defsystem-depends-on ; This symbol retained for backward compatibility.
#:sideway-dependencies #:if-feature #:in-order-to #:inline-methods
#:relative-pathname #:absolute-pathname #:operation-times #:around-compile
#:%encoding #:properties #:component-properties #:parent))
(in-package :asdf/component)
(with-upgradability ()
(defgeneric component-name (component)
(:documentation "Name of the COMPONENT, unique relative to its parent"))
(defgeneric component-system (component)
(:documentation "Top-level system containing the COMPONENT"))
(defgeneric component-pathname (component)
(:documentation "Pathname of the COMPONENT if any, or NIL."))
(defgeneric component-relative-pathname (component)
;; in ASDF4, rename that to component-specified-pathname ?
(:documentation "Specified pathname of the COMPONENT,
intended to be merged with the pathname of that component's parent if any, using merged-pathnames*.
Despite the function's name, the return value can be an absolute pathname, in which case the merge
will leave it unmodified."))
(defgeneric component-external-format (component)
(:documentation "The external-format of the COMPONENT.
By default, deduced from the COMPONENT-ENCODING."))
(defgeneric component-encoding (component)
(:documentation "The encoding of the COMPONENT. By default, only :utf-8 is supported.
Use asdf-encodings to support more encodings."))
(defgeneric version-satisfies (component version)
(:documentation "Check whether a COMPONENT satisfies the constraint of being at least as recent
as the specified VERSION, which must be a string of dot-separated natural numbers, or NIL."))
(defgeneric component-version (component)
(:documentation "Return the version of a COMPONENT, which must be a string of dot-separated
natural numbers, or NIL."))
(defgeneric (setf component-version) (new-version component)
(:documentation "Updates the version of a COMPONENT, which must be a string of dot-separated
natural numbers, or NIL."))
(defgeneric component-parent (component)
(:documentation "The parent of a child COMPONENT,
or NIL for top-level components (a.k.a. systems)"))
;; NIL is a designator for the absence of a component, in which case the parent is also absent.
(defmethod component-parent ((component null)) nil)
;; Deprecated: Backward compatible way of computing the FILE-TYPE of a component.
(with-asdf-deprecation (:style-warning "3.4")
(defgeneric source-file-type (component system)
(:documentation "DEPRECATED. Use the FILE-TYPE of a COMPONENT instead.")))
(define-condition duplicate-names (system-definition-error)
((name :initarg :name :reader duplicate-names-name))
(:report (lambda (c s)
(format s (compatfmt "~@")
(duplicate-names-name c))))))
(with-upgradability ()
(defclass component ()
((name :accessor component-name :initarg :name :type string :documentation
"Component name: designator for a string composed of portable pathname characters")
;; We might want to constrain version with
;; :type (and string (satisfies parse-version))
;; but we cannot until we fix all systems that don't use it correctly!
(version :accessor component-version :initarg :version :initform nil)
(description :accessor component-description :initarg :description :initform nil)
(long-description :accessor component-long-description :initarg :long-description :initform nil)
(sideway-dependencies :accessor component-sideway-dependencies :initform nil)
(if-feature :accessor component-if-feature :initform nil :initarg :if-feature)
;; In the ASDF object model, dependencies exist between *actions*,
;; where an action is a pair of an operation and a component.
;; Dependencies are represented as alists of operations
;; to a list where each entry is a pair of an operation and a list of component specifiers.
;; Up until ASDF 2.26.9, there used to be two kinds of dependencies:
;; in-order-to and do-first, each stored in its own slot. Now there is only in-order-to.
;; in-order-to used to represent things that modify the filesystem (such as compiling a fasl)
;; and do-first things that modify the current image (such as loading a fasl).
;; These are now unified because we now correctly propagate timestamps between dependencies.
;; Happily, no one seems to have used do-first too much (especially since until ASDF 2.017,
;; anything you specified was overridden by ASDF itself anyway), but the name in-order-to remains.
;; The names are bad, but they have been the official API since Dan Barlow's ASDF 1.52!
;; LispWorks's defsystem has caused-by and requires for in-order-to and do-first respectively.
;; Maybe rename the slots in ASDF? But that's not very backward-compatible.
;; See our ASDF 2 paper for more complete explanations.
(in-order-to :initform nil :initarg :in-order-to
:accessor component-in-order-to)
;; Methods defined using the "inline" style inside a defsystem form:
;; we store them here so we can delete them when the system is re-evaluated.
(inline-methods :accessor component-inline-methods :initform nil)
;; ASDF4: rename it from relative-pathname to specified-pathname. It need not be relative.
;; There is no initform and no direct accessor for this specified pathname,
;; so we only access the information through appropriate methods, after it has been processed.
;; Unhappily, some braindead systems directly access the slot. Make them stop before ASDF4.
(relative-pathname :initarg :pathname)
;; The absolute-pathname is computed based on relative-pathname and parent pathname.
;; The slot is but a cache used by component-pathname.
(absolute-pathname)
(operation-times :initform (make-hash-table)
:accessor component-operation-times)
(around-compile :initarg :around-compile)
;; Properties are for backward-compatibility with ASDF2 only. DO NOT USE!
(properties :accessor component-properties :initarg :properties
:initform nil)
(%encoding :accessor %component-encoding :initform nil :initarg :encoding)
;; For backward-compatibility, this slot is part of component rather than of child-component. ASDF4: stop it.
(parent :initarg :parent :initform nil :reader component-parent)
(build-operation
:initarg :build-operation :initform nil :reader component-build-operation)
;; Cache for ADDITIONAL-INPUT-FILES function.
(additional-input-files :accessor %additional-input-files :initform nil))
(:documentation "Base class for all components of a build"))
(defgeneric find-component (base path &key registered)
(:documentation "Find a component by resolving the PATH starting from BASE parent.
If REGISTERED is true, only search currently registered systems."))
(defun component-find-path (component)
"Return a path from a root system to the COMPONENT.
The return value is a list of component NAMES; a list of strings."
(check-type component (or null component))
(reverse
(loop :for c = component :then (component-parent c)
:while c :collect (component-name c))))
(defmethod print-object ((c component) stream)
(print-unreadable-object (c stream :type t :identity nil)
(format stream "~{~S~^ ~}" (component-find-path c))))
(defmethod component-system ((component component))
(if-let (system (component-parent component))
(component-system system)
component)))
;;;; Component hierarchy within a system
;; The tree typically but not necessarily follows the filesystem hierarchy.
(with-upgradability ()
(defclass child-component (component) ()
(:documentation "A CHILD-COMPONENT is a COMPONENT that may be part of
a PARENT-COMPONENT."))
(defclass file-component (child-component)
((type :accessor file-type :initarg :type)) ; no default
(:documentation "a COMPONENT that represents a file"))
(defclass source-file (file-component)
((type :accessor source-file-explicit-type ;; backward-compatibility
:initform nil))) ;; NB: many systems have come to rely on this default.
(defclass c-source-file (source-file)
((type :initform "c")))
(defclass java-source-file (source-file)
((type :initform "java")))
(defclass static-file (source-file)
((type :initform nil))
(:documentation "Component for a file to be included as is in the build output"))
(defclass doc-file (static-file) ())
(defclass html-file (doc-file)
((type :initform "html")))
(defclass parent-component (component)
((children
:initform nil
:initarg :components
:reader module-components ; backward-compatibility
:accessor component-children)
(children-by-name
:reader module-components-by-name ; backward-compatibility
:accessor component-children-by-name)
(default-component-class
:initform nil
:initarg :default-component-class
:accessor module-default-component-class))
(:documentation "A PARENT-COMPONENT is a component that may have children.")))
(with-upgradability ()
;; (Private) Function that given a PARENT component,
;; the list of children of which has been initialized,
;; compute the hash-table in slot children-by-name that allows to retrieve its children by name.
;; If ONLY-IF-NEEDED-P is defined, skip any (re)computation if the slot is already populated.
(defun compute-children-by-name (parent &key only-if-needed-p)
(unless (and only-if-needed-p (slot-boundp parent 'children-by-name))
(let ((hash (make-hash-table :test 'equal)))
(setf (component-children-by-name parent) hash)
(loop :for c :in (component-children parent)
:for name = (component-name c)
:for previous = (gethash name hash)
:do (when previous (error 'duplicate-names :name name))
(setf (gethash name hash) c))
hash))))
(with-upgradability ()
(defclass module (child-component parent-component)
(#+clisp (components)) ;; backward compatibility during upgrade only
(:documentation "A module is a intermediate component with both a parent and children,
typically but not necessarily representing the files in a subdirectory of the build source.")))
;;;; component pathnames
(with-upgradability ()
(defgeneric component-parent-pathname (component)
(:documentation "The pathname of the COMPONENT's parent, if any, or NIL"))
(defmethod component-parent-pathname (component)
(component-pathname (component-parent component)))
;; The default method for component-pathname tries to extract a cached precomputed
;; absolute-pathname from the relevant slot, and if not, computes it by merging the
;; component-relative-pathname (which should be component-specified-pathname, it can be absolute)
;; with the directory of the component-parent-pathname.
(defmethod component-pathname ((component component))
(if (slot-boundp component 'absolute-pathname)
(slot-value component 'absolute-pathname)
(let ((pathname
(merge-pathnames*
(component-relative-pathname component)
(pathname-directory-pathname (component-parent-pathname component)))))
(unless (or (null pathname) (absolute-pathname-p pathname))
(error (compatfmt "~@")
pathname (component-find-path component)))
(setf (slot-value component 'absolute-pathname) pathname)
pathname)))
;; Default method for component-relative-pathname:
;; combine the contents of slot relative-pathname (from specified initarg :pathname)
;; with the appropriate source-file-type, which defaults to the file-type of the component.
(defmethod component-relative-pathname ((component component))
;; SOURCE-FILE-TYPE below is strictly for backward-compatibility with ASDF1.
;; We ought to be able to extract this from the component alone with FILE-TYPE.
;; TODO: track who uses it in Quicklisp, and have them not use it anymore;
;; maybe issue a WARNING (then eventually CERROR) if the two methods diverge?
(parse-unix-namestring
(or (and (slot-boundp component 'relative-pathname)
(slot-value component 'relative-pathname))
(component-name component))
:want-relative t
:type (source-file-type component (component-system component))
:defaults (component-parent-pathname component)))
(defmethod source-file-type ((component parent-component) (system parent-component))
:directory)
(defmethod source-file-type ((component file-component) (system parent-component))
(file-type component)))
;;;; Encodings
(with-upgradability ()
(defmethod component-encoding ((c component))
(or (loop :for x = c :then (component-parent x)
:while x :thereis (%component-encoding x))
(detect-encoding (component-pathname c))))
(defmethod component-external-format ((c component))
(encoding-external-format (component-encoding c))))
;;;; around-compile-hook
(with-upgradability ()
(defgeneric around-compile-hook (component)
(:documentation "An optional hook function that will be called with one argument, a thunk.
The hook function must call the thunk, that will compile code from the component, and may or may not
also evaluate the compiled results. The hook function may establish dynamic variable bindings around
this compilation, or check its results, etc."))
(defmethod around-compile-hook ((c component))
(cond
((slot-boundp c 'around-compile)
(slot-value c 'around-compile))
((component-parent c)
(around-compile-hook (component-parent c))))))
;;;; version-satisfies
(with-upgradability ()
;; short-circuit testing of null version specifications.
;; this is an all-pass, without warning
(defmethod version-satisfies :around ((c t) (version null))
t)
(defmethod version-satisfies ((c component) version)
(unless (and version (slot-boundp c 'version) (component-version c))
(when version
(warn "Requested version ~S but ~S has no version" version c))
(return-from version-satisfies nil))
(version-satisfies (component-version c) version))
(defmethod version-satisfies ((cver string) version)
(version<= version cver)))
;;; all sub-components (of a given type)
(with-upgradability ()
(defun sub-components (component &key (type t))
"Compute the transitive sub-components of given COMPONENT that are of given TYPE"
(while-collecting (c)
(labels ((recurse (x)
(when (if-let (it (component-if-feature x)) (featurep it) t)
(when (typep x type)
(c x))
(when (typep x 'parent-component)
(map () #'recurse (component-children x))))))
(recurse component)))))
asdf-3.3.4/concatenate-source.lisp 0000664 0000000 0000000 00000013241 13621551153 0017114 0 ustar 00root root 0000000 0000000 ;;;; -------------------------------------------------------------------------
;;;; Concatenate-source
(uiop/package:define-package :asdf/concatenate-source
(:recycle :asdf/concatenate-source :asdf)
(:use :uiop/common-lisp :uiop :asdf/upgrade
:asdf/component :asdf/operation
:asdf/system
:asdf/action :asdf/lisp-action :asdf/plan :asdf/bundle)
(:export
#:concatenate-source-op
#:load-concatenated-source-op
#:compile-concatenated-source-op
#:load-compiled-concatenated-source-op
#:monolithic-concatenate-source-op
#:monolithic-load-concatenated-source-op
#:monolithic-compile-concatenated-source-op
#:monolithic-load-compiled-concatenated-source-op))
(in-package :asdf/concatenate-source)
;;;
;;; Concatenate sources
;;;
(with-upgradability ()
;; Base classes for both regular and monolithic concatenate-source operations
(defclass basic-concatenate-source-op (bundle-op) ())
(defmethod bundle-type ((o basic-concatenate-source-op)) "lisp")
(defclass basic-load-concatenated-source-op (basic-load-op selfward-operation) ())
(defclass basic-compile-concatenated-source-op (basic-compile-op selfward-operation) ())
(defclass basic-load-compiled-concatenated-source-op (basic-load-op selfward-operation) ())
;; Regular concatenate-source operations
(defclass concatenate-source-op (basic-concatenate-source-op non-propagating-operation) ()
(:documentation "Operation to concatenate all sources in a system into a single file"))
(defclass load-concatenated-source-op (basic-load-concatenated-source-op)
((selfward-operation :initform '(prepare-op concatenate-source-op) :allocation :class))
(:documentation "Operation to load the result of concatenate-source-op as source"))
(defclass compile-concatenated-source-op (basic-compile-concatenated-source-op)
((selfward-operation :initform '(prepare-op concatenate-source-op) :allocation :class))
(:documentation "Operation to compile the result of concatenate-source-op"))
(defclass load-compiled-concatenated-source-op (basic-load-compiled-concatenated-source-op)
((selfward-operation :initform '(prepare-op compile-concatenated-source-op) :allocation :class))
(:documentation "Operation to load the result of compile-concatenated-source-op"))
(defclass monolithic-concatenate-source-op
(basic-concatenate-source-op monolithic-bundle-op non-propagating-operation) ()
(:documentation "Operation to concatenate all sources in a system and its dependencies
into a single file"))
(defclass monolithic-load-concatenated-source-op (basic-load-concatenated-source-op)
((selfward-operation :initform 'monolithic-concatenate-source-op :allocation :class))
(:documentation "Operation to load the result of monolithic-concatenate-source-op as source"))
(defclass monolithic-compile-concatenated-source-op (basic-compile-concatenated-source-op)
((selfward-operation :initform 'monolithic-concatenate-source-op :allocation :class))
(:documentation "Operation to compile the result of monolithic-concatenate-source-op"))
(defclass monolithic-load-compiled-concatenated-source-op
(basic-load-compiled-concatenated-source-op)
((selfward-operation :initform 'monolithic-compile-concatenated-source-op :allocation :class))
(:documentation "Operation to load the result of monolithic-compile-concatenated-source-op"))
(defmethod input-files ((operation basic-concatenate-source-op) (s system))
(loop :with encoding = (or (component-encoding s) *default-encoding*)
:with other-encodings = '()
:with around-compile = (around-compile-hook s)
:with other-around-compile = '()
:for c :in (required-components ;; see note about similar call to required-components
s :goal-operation 'load-op ;; in bundle.lisp
:keep-operation 'basic-compile-op
:other-systems (operation-monolithic-p operation))
:append
(when (typep c 'cl-source-file)
(let ((e (component-encoding c)))
(unless (equal e encoding)
(let ((a (assoc e other-encodings)))
(if a (push (component-find-path c) (cdr a))
(push (list a (component-find-path c)) other-encodings)))))
(unless (equal around-compile (around-compile-hook c))
(push (component-find-path c) other-around-compile))
(input-files (make-operation 'compile-op) c)) :into inputs
:finally
(when other-encodings
(warn "~S uses encoding ~A but has sources that use these encodings:~{ ~A~}"
operation encoding
(mapcar #'(lambda (x) (cons (car x) (list (reverse (cdr x)))))
other-encodings)))
(when other-around-compile
(warn "~S uses around-compile hook ~A but has sources that use these hooks: ~A"
operation around-compile other-around-compile))
(return inputs)))
(defmethod output-files ((o basic-compile-concatenated-source-op) (s system))
(lisp-compilation-output-files o s))
(defmethod perform ((o basic-concatenate-source-op) (s system))
(let* ((ins (input-files o s))
(out (output-file o s))
(tmp (tmpize-pathname out)))
(concatenate-files ins tmp)
(rename-file-overwriting-target tmp out)))
(defmethod perform ((o basic-load-concatenated-source-op) (s system))
(perform-lisp-load-source o s))
(defmethod perform ((o basic-compile-concatenated-source-op) (s system))
(perform-lisp-compilation o s))
(defmethod perform ((o basic-load-compiled-concatenated-source-op) (s system))
(perform-lisp-load-fasl o s)))
asdf-3.3.4/contrib/ 0000775 0000000 0000000 00000000000 13621551153 0014100 5 ustar 00root root 0000000 0000000 asdf-3.3.4/contrib/debug-plan.lisp 0000664 0000000 0000000 00000017734 13621551153 0017023 0 ustar 00root root 0000000 0000000 (defpackage :asdf/contrib/plan (:use :cl)) ;; dummy, for use as package-inferred-system
(in-package :asdf/plan)
;; NB: Whenever compute-action-stamp is changed, this file must be updated
;; to insert the let-and-DBG statements in the current version of the function.
;; So if you find this file not working, it might be out of date.
(uiop:uiop-debug)
(progn
(defmethod compute-action-stamp (plan (o operation) (c component) &key just-done)
;; Given an action, figure out at what time in the past it has been done,
;; or if it has just been done, return the time that it has.
;; Returns two values:
;; 1- the TIMESTAMP of the action if it has already been done and is up to date,
;; or NIL is either hasn't been done or is out of date.
;; (An ASDF extension could use a cryptographic digest instead.)
;; 2- the DONE-IN-IMAGE-P boolean flag that is T if the action has already been done
;; in the current image, or NIL if it hasn't.
;; Note that if e.g. LOAD-OP only depends on up-to-date files, but
;; hasn't been done in the current image yet, then it can have a non-NIL timestamp,
;; yet a NIL done-in-image-p flag: we can predict what timestamp it will have once loaded,
;; i.e. that of the input-files.
;; If just-done is NIL, these values return are the notional fields of
;; a KEEP, REDO or TODO status (VOID is possible, but probably an error).
;; If just-done is T, they are the notional fields of DONE status
;; (or, if something went wrong, TODO).
(nest
(block ())
(let* ((dep-status ; collect timestamp from dependencies (or T if forced or out-of-date)
(reduce-direct-dependencies
o c
#'(lambda (do dc status)
;; out-of-date dependency: don't bother looking further
(let ((action-status (action-status plan do dc)))
(cond
((and action-status (or (status-keep-p action-status)
(and just-done (status-stamp action-status))))
(merge-action-status action-status status))
(just-done
;; It's OK to lose some ASDF action stamps during self-upgrade
(unless (equal "asdf" (primary-system-name dc))
(warn "Computing just-done stamp in plan ~S for action ~S, but dependency ~S wasn't done yet!"
plan
(action-path (make-action o c))
(action-path (make-action do dc))))
status)
(t
(DBG "compute-action-stamp: forced by out of date dependency" (action-path (make-action o c)) (action-path (make-action do dc)) action-status)
(return (values nil nil))))))
+status-good+))
(dep-stamp (status-stamp dep-status)))
;; DBG
(when (null dep-stamp)
(let* ((action-path (action-path (cons o c)))
(dep-statuses (loop for action in (direct-dependencies o c) for (o . c) = action collect
(list (action-path action) (action-status plan o c)))))
(DBG :nds action-path dep-statuses))))
(let* (;; collect timestamps from inputs, and exit early if any is missing
(in-files (input-files o c))
(in-stamps (mapcar #'get-file-stamp in-files))
(missing-in (loop :for f :in in-files :for s :in in-stamps :unless s :collect f))
(latest-in (timestamps-latest (cons dep-stamp in-stamps))))
(when (and missing-in (not just-done))
(DBG "compute-action-stamp: missing inputs" (cons o c) missing-in)
(return (values nil nil))))
(let* (;; collect timestamps from outputs, and exit early if any is missing
(out-files (remove-if 'null (output-files o c)))
(out-stamps (mapcar (if just-done 'register-file-stamp 'get-file-stamp) out-files))
(missing-out (loop :for f :in out-files :for s :in out-stamps :unless s :collect f))
(earliest-out (timestamps-earliest out-stamps)))
(when (and missing-out (not just-done))
(DBG "compute-action-stamp: missing outputs" (cons o c) missing-out)
(return (values nil nil))))
(let (;; Time stamps from the files at hand, and whether any is missing
(all-present (not (or missing-in missing-out)))
;; Has any input changed since we last generated the files?
;; Note that we use timestamp<= instead of timestamp< to play nice with generated files.
;; Any race condition is intrinsic to the limited timestamp resolution.
(up-to-date-p (timestamp<= latest-in earliest-out))
;; If everything is up to date, the latest of inputs and outputs is our stamp
(done-stamp (timestamps-latest (cons latest-in out-stamps))))
;; Warn if some files are missing:
;; either our model is wrong or some other process is messing with our files.
(when (and just-done (not all-present))
;; Shouldn't that be an error instead?
(warn "~A completed without ~:[~*~;~*its input file~:p~2:*~{ ~S~}~*~]~
~:[~; or ~]~:[~*~;~*its output file~:p~2:*~{ ~S~}~*~]"
(action-description o c)
missing-in (length missing-in) (and missing-in missing-out)
missing-out (length missing-out))))
(let (;; There are three kinds of actions:
(out-op (and out-files t)) ; those that create files on the filesystem
;;(image-op (and in-files (null out-files))) ; those that load stuff into the image
;;(null-op (and (null out-files) (null in-files))) ; placeholders that do nothing
))
;; Status of the action as previously performed in the image
(progn ;; DBG
(multiple-value-bind (perform-stamp perform-done-p)
(if just-done
(values done-stamp t)
(component-operation-time o c))
(let* ((forced (action-forced-p (forcing (or plan *asdf-session*)) o c))
(already-done-p (and all-present up-to-date-p (operation-done-p o c)
(not forced)))
(matching-stamp-p (and perform-done-p (eql perform-stamp done-stamp)))
(action-path (action-path (cons o c))))
(DBG "compute-action-stamp"
action-path
in-files
in-stamps
dep-stamp
out-files
out-stamps
latest-in
earliest-out
up-to-date-p
perform-stamp
perform-done-p
done-stamp
all-present
forced
already-done-p
just-done
out-op
matching-stamp-p))))
(if (or just-done ;; The done-stamp is valid: if we're just done, or
(and all-present ;; if all filesystem effects are up-to-date
up-to-date-p
(operation-done-p o c) ;; and there's no invalidating reason.
(not (action-forced-p (forcing (or plan *asdf-session*)) o c))))
(values done-stamp ;; return the hard-earned timestamp
(or just-done
out-op ;; A file-creating op is done when all files are up to date.
;; An image-effecting operation is done when
(and (status-done-p dep-status) ;; all the dependencies were done, and
(multiple-value-bind (perform-stamp perform-done-p)
(component-operation-time o c)
(and perform-done-p ;; the op was actually run,
(equal perform-stamp done-stamp)))))) ;; with a matching stamp.
;; done-stamp invalid: return a timestamp in an indefinite future, action not done yet
(values nil nil)))))
asdf-3.3.4/contrib/debug.lisp 0000777 0000000 0000000 00000000000 13621551153 0022660 2../uiop/contrib/debug.lisp ustar 00root root 0000000 0000000 asdf-3.3.4/contrib/detect-multiply-used-files.lisp 0000664 0000000 0000000 00000002354 13621551153 0022160 0 ustar 00root root 0000000 0000000 (uiop:define-package :detect-multiply-used-files
(:nicknames :asdf/contrib/detect-multiply-used-files)
(:use :asdf/component :asdf/system-registry :uiop :common-lisp)
(:export #:find-fishy-components #:register-component-files #:*file-components*))
(in-package :detect-multiply-used-files)
(defparameter *file-components* (make-hash-table :test 'equal))
(defun register-component-files (component)
(let ((c (find-component () component)))
(if-let (p (component-pathname c))
(pushnew (component-find-path c) (gethash (namestring p) *file-components*)))
(when (typep c 'parent-component)
(dolist (cc (component-children c))
(register-component-files cc)))))
(defun table-keys (table)
(loop :for s :being :the :hash-keys :of table :collect s))
(defun find-fishy-components ()
(clrhash *file-components*)
(map () 'register-component-files (table-keys *registered-systems*))
(loop :for p :in (sort (table-keys *file-components*) 'string<)
:for l = (gethash p *file-components*)
:when (and (file-pathname-p p) (not (length=n-p l 1)))
:do (format t "~&~S =>~{ ~S~}~%" p l)))
#| ;; Use it like that:
(asdf:load-systems system1 system2 ...)
(detect-multiply-used-files:find-fishy-components)
|#
asdf-3.3.4/contrib/fasl-op.lisp 0000664 0000000 0000000 00000002336 13621551153 0016336 0 ustar 00root root 0000000 0000000 (uiop:define-package :asdf/contrib/fasl-op
(:use :common-lisp :uiop
:asdf :asdf/component :asdf/operation :asdf/lisp-action :asdf/bundle))
(in-package :asdf/contrib/fasl-op)
;;; Backward compatibility with pre-3.1.2 names
(eval-when (:compile-toplevel :load-toplevel :execute)
(defun frob-symbol (sym)
(loop :for dest :in '(:asdf/bundle :asdf/interface) :do
(uiop/package::ensure-import
(symbol-name sym) (find-package dest) (symbol-package sym)
(make-hash-table :test 'equal) (make-hash-table :test 'equal)))))
(defmacro declare-ops (&rest ops)
`(progn
,@(loop :for (compat-name current-name) :in ops :append
`((defclass ,compat-name (selfward-operation)
((selfward-operation :initform ',current-name :allocation :class)))
(defmethod output-files ((o ,compat-name) (c component))
(output-files (find-operation o ',current-name) c))
(frob-symbol ',compat-name)))))
(declare-ops
(fasl-op compile-bundle-op)
(load-fasl-op load-bundle-op)
(binary-op deliver-asd-op)
(monolithic-fasl-op monolithic-compile-bundle-op)
(monolithic-load-fasl-op monolithic-load-bundle-op)
(monolithic-binary-op monolithic-deliver-asd-op))
asdf-3.3.4/contrib/fast-compile-op.lisp 0000664 0000000 0000000 00000002335 13621551153 0017773 0 ustar 00root root 0000000 0000000 ;; fast-compile-op: compile just one file in the current process,
;; loading all dependencies as source.
;; How to use it:
;; (1) your build system compiles all your system's dependencies as bundle.
;; (2) For each component in the system, invoke a process that
;; (a) loads all the transitive dependencies as bundles
;; (b) use register-preloaded-system
;; to tell ASDF the direct dependencies are loaded
;; (c) use fast-compile-op on each of the components in the system
;; (3) when they are all done, combine the fasls in a bundle.
#+sbcl (setf sb-ext:*evaluator-mode* :interpret)
(defclass fast-compile-op (basic-compile-op selfward-operation)
((selfward-operation :initform 'prepare-source-op)))
(defmethod action-description ((o fast-compile-op) (c component))
(declare (ignorable o))
(format nil (compatfmt "~@") c))
(defmethod perform ((o fast-compile-op) (c component))
(let (#+sbcl (sb-ext:*evaluator-mode* :compile))
(perform (make-operation 'compile-op) c)))
(defmethod output-files ((o fast-compile-op) (c component))
(output-files (make-operation 'compile-op) c))
(defmethod input-files ((o fast-compile-op) (c component))
(input-files (make-operation 'compile-op) c))
asdf-3.3.4/contrib/fiveam-asdf/ 0000775 0000000 0000000 00000000000 13621551153 0016262 5 ustar 00root root 0000000 0000000 asdf-3.3.4/contrib/fiveam-asdf/code.lisp 0000664 0000000 0000000 00000011160 13621551153 0020064 0 ustar 00root root 0000000 0000000 (in-package :asdf)
(defclass fiveam-tester-system (system)
((test-names
:initarg :test-names
:reader test-names
:documentation "A list whose elements are either
cons cells of symbol and package designators or
simply a symbol designator.
In the latter case, the symbols will be interned
in the package designated by the TEST-PACKAGE slot,
which must be bound.")
(test-package
:initarg :default-test-package
:initarg :test-package
:documentation "If all the tests are in one package, you can just
have a list of test names in test-names, and get the package name from
here.")
(num-checks
:initarg :num-checks
:reader num-checks
:type (or null (integer 0))
:initform nil
:documentation "How many tests do you expect to run when
you invoke the test-op on this system. For backwards compatibility,
this slot is ignored if it's NIL. If bound, then when running the
test-op, we will fail if the expected number of checks are not run.")
))
(define-condition fiveam-asdf-failure (error)
((failed-asdf-component
:initarg :failed-asdf-component
:reader failed-asdf-component
))
(:documentation "Superclass of error conditions that indicate that
an ASDF test-op has failed."))
(define-condition fiveam-test-fail (fiveam-asdf-failure)
((failed
:initarg :failed
:reader failed
))
(:report (lambda (x s)
(format s "Tests on system ~a failed: ~{~t~a~%~}"
(component-name (failed-asdf-component x))
(failed x)))))
(define-condition fiveam-wrong-number-of-checks (fiveam-asdf-failure)
((expected-num-checks
:initarg :expected
:initarg :expected-num-checks
:reader expected-num-checks
)
(actual-num-checks
:initarg :actual-num-checks
:initarg :actual
:reader actual-num-checks
))
(:report (lambda (x s)
(format s "Unexpected number of tests on system ~a: Expected ~d got ~d."
(component-name (failed-asdf-component x))
(expected-num-checks x)
(actual-num-checks x)))))
(defgeneric test-package (x)
(:method ((x fiveam-tester-system))
(if (slot-boundp x 'test-package)
(slot-value x 'test-package)
(error "If package is not specified with each test-name, system's TEST-PACKAGE slot must be set."))))
(defmethod perform ((op test-op) (sys fiveam-tester-system))
(let* ((test-syms
(loop for x in (test-names sys)
with test-name and package-name and test-sym and package
if (symbolp x)
do (setf test-name x
package-name (test-package sys))
else
do (assert (and (consp x)
(or (symbolp (car x)) (stringp (car x)))
(or (symbolp (cdr x)) (stringp (cdr x)))))
(setf test-name (car x) package-name (cdr x))
do (setf package (or (find-package package-name)
(error "Unable to find package ~a" package-name)))
(setf test-sym
(intern
(etypecase test-name
(string test-name)
(symbol (symbol-name test-name)))
package))
collect test-sym))
(runner (intern (symbol-name '#:run) :fiveam))
(tester (intern (symbol-name '#:results-status) :fiveam))
(explainer (intern (symbol-name '#:explain!) :fiveam))
(results (loop for test in test-syms
appending (funcall runner test))))
(funcall explainer results)
;; if there's an expected number of checks, verify that we have run
;; exactly that number.
(when (num-checks sys)
(let ((actual-num-checks (length results)))
(unless (= actual-num-checks (num-checks sys))
(error 'fiveam-wrong-number-of-checks
:failed-asdf-component sys
:actual actual-num-checks
:expected (num-checks sys)))))
(multiple-value-bind (success failures)
(funcall tester results)
(unless success
(error 'fiveam-test-fail :failed-asdf-component sys :failed failures)))))
(defmethod component-depends-on ((op load-op) (sys fiveam-tester-system))
(cons '(load-op "fiveam") (call-next-method)))
(defmethod component-depends-on ((op compile-op) (sys fiveam-tester-system))
(cons '(load-op "fiveam") (call-next-method)))
(eval-when (:compile-toplevel :load-toplevel :execute)
(export 'fiveam-tester-system :asdf))
asdf-3.3.4/contrib/fiveam-asdf/fiveam-asdf.asd 0000664 0000000 0000000 00000002501 13621551153 0021133 0 ustar 00root root 0000000 0000000 ;;;---------------------------------------------------------------------------
;;; Copyright (c) 2012-2018 Smart Information Flow Technologies, d/b/a SIFT, LLC and
;;; Robert P. Goldman
;;; All rights reserved.
;;;
;;; The developers make this software available according to the terms
;;; of the Lisp Lesser GNU Public License (LLGPL):
;;; http://opensource.franz.com/preamble.html.
;;; See the accompanying file, license.txt
;;;
;;;---------------------------------------------------------------------------
;;;
;;; This system provides functionality to support integrating FiveAM tests with
;;; an ASDF system definition in such a way that invocation of the
;;; ASDF:TEST-SYSTEM function will cause the FiveAM tests to run. An error will
;;; be raised if there are test failures.
;;;
;;;---------------------------------------------------------------------------
(defpackage :fiveam-asdf-asd
(:use :common-lisp :asdf)
)
(in-package :fiveam-asdf-asd)
(defsystem fiveam-asdf
:long-description
"System that defines a new system class FIVEAM-TESTER
that provides functionality for running tests using
FIVEAM and raising an error if the tests fail
\(useful for incorporation in a Jenkins or Hudson
build\)."
:depends-on (:asdf)
:components ((:file "code"))
:author "Robert P. Goldman"
:version "2.0"
:license "Lisp LGPL"
)
asdf-3.3.4/contrib/fiveam-asdf/license.txt 0000664 0000000 0000000 00000001036 13621551153 0020445 0 ustar 00root root 0000000 0000000 FIVEAM-ASDF is a library enabling suites of FiveAM tests to be
associated with ASDF systems in such a way that ASDF:TEST-SYSTEM will
cause the tests to be run and will raise an exception if something
unexpected happens.
FIVEAM-ASDF is licensed under the terms of the Lisp Lesser GNU
Public License (http://opensource.franz.com/preamble.html), known as
the LLGPL. The LLGPL consists of a preamble (see above URL) and the
LGPL. Where these conflict, the preamble takes precedence.
FIVEAM-ASDF is referenced in the preamble as the "LIBRARY."
asdf-3.3.4/contrib/wild-modules.lisp 0000664 0000000 0000000 00000002733 13621551153 0017403 0 ustar 00root root 0000000 0000000 (in-package :asdf)
(defclass wild-module (module)
((component-class :accessor wild-module-component-class
:initform 'static-file :initarg :component-class)
(component-options :accessor wild-module-component-options
:initform nil :initarg :component-options)))
(defmethod (setf component-children) (new-value (module wild-module))
(when new-value
(sysdef-error "Cannot explicitly set wild-module ~A's children components. Please ~
use a wild pathname instead." module)))
(defmethod reinitialize-instance :after ((self wild-module) &key)
(let ((pathname (component-pathname self)))
(unless (and pathname (wild-pathname-p pathname))
(sysdef-error "Wild-module ~A specified with non-wild pathname ~A."
self pathname))
(setf (slot-value self 'components)
(let* ((files (directory* pathname))
(class (wild-module-component-class self))
(options (wild-module-component-options self)))
(mapcar (lambda (file)
(apply #'make-instance class
:name (namestring file)
:pathname file
:parent self
options))
files)))
(compute-children-by-name self)
(values)))
(defmethod input-files ((o compile-op) (c wild-module)) ())
(defmethod input-files ((o load-op) (c wild-module)) ())
(export 'wild-module)
asdf-3.3.4/doc/ 0000775 0000000 0000000 00000000000 13621551153 0013205 5 ustar 00root root 0000000 0000000 asdf-3.3.4/doc/.htaccess 0000664 0000000 0000000 00000000121 13621551153 0014775 0 ustar 00root root 0000000 0000000 Redirect /project/asdf/manual.html http://common-lisp.net/project/asdf/asdf.html
asdf-3.3.4/doc/Changelog 0000664 0000000 0000000 00000226327 13621551153 0015033 0 ustar 00root root 0000000 0000000 cl-asdf (2:3.3.4-1) unstable; urgency=low
Bug fix release:
* SBCL compatibility: support local nicknames in package-inferred-system,
address upgrade issues in SBCL 2.x (thanks to Eric Timmons).
* Clasp compatibility: fixes from Karsten Poeck.
* Lispworks compatibility: fixes from Martin Simmons.
* Documentation: multiple user-contributed fixes: Jan Moringen and
Rommel Martinez.
* Bundle bug fixes: thanks to Guillaume Le Vaillant and François-René Rideau.
* Miscellaneous bug fixes.
* Tests: miscellaneous fixes and improvements.
-- Robert P. Goldman Thu, 13 Feb 2020 17:09:39 -0600
cl-asdf (2:3.3.3-1) unstable; urgency=low
Bug fix release:
* Dependency tracking: fix bugs in handling misnamed secondary systems.
We now distinguish between "syntactic" and "semantic" primariness,
properly warn in case a secondary system is misnamed, yet properly
recompile or avoid spurious recompilation depending on whether
there or not is a conflict or redefinition.
Similarly handle package-inferred-system (thanks to Eric Timmons).
Better warning in a fishy case of compute-action-stamp.
* UIOP: Fix loading, allow the user to specify UIOP location from which
to load.
* SBCL compatibility: Fix issue with deferred warnings on SBCL.
* Allegro compatibility: Fix issue detecting "modern" lisp.
* Genera compatibility: Fix minor issues. Not fully tested.
* ECL compatibility: Bundling fixes.
* Fiveam-ASDF: Added to contrib/ example system for integrating FiveAM
tests with ASDF's test-op.
* Miscellaneous fixes: Avoid an infinite loop parsing :perform options,
quash warnings for known bad system names that won't be fixed.
* Documentation: Multiple user-contributed documentation fixes.
* Tests: Miscellaneous improvements.
-- Francois-Rene Rideau Wed, 27 Mar 2019 17:33:42 -0400
cl-asdf (2:3.3.2-1) unstable; urgency=low
Bug fix release:
* Dependency tracking: fix bugs in handling misnamed secondary systems.
We now distinguish between "syntactic" and "semantic" primariness,
properly warn in case a secondary system is misnamed, yet properly
recompile or avoid spurious recompilation depending on whether
there or not is a conflict or redefinition.
Similarly handle package-inferred-system (thanks to Eric Timmons).
Better warning in a fishy case of compute-action-stamp.
* UIOP: Add package location information to define-package on SBCL.
* Upgrade: fix issue with asdf/bundle.
* Portability: add support for Mezzano (thanks to E. Housel, H. Harrington)
* Documentation: add discussion of best practices.
* Package-inferred system: Improve source file handling.
* Test and documentation improvements.
-- Francois-Rene Rideau Thu, 03 May 2018 22:46:19 -0400
cl-asdf (2:3.3.1-1) unstable; urgency=low
New milestone:
* UIOP compatibility fix: Introduced new replacement "timestamp"
comparison functions, because of inadvertent change in the
API. Functions that are compatible with the old semantics are retained
as "stamp" comparison functions, but will eventually be deprecated.
* Upgrade fix: Upgrade from 3.2.1 needed repair.
* Syntax manipulation: Fix for bugs that could be introduced when the
default readtable was manipulated during the loading of a
defsystem-depends-on system.
* Tests: tests for new capabilities and bugs
* Documentation: a number of improvements and clarifications.
-- Robert P. Goldman Sun, 12 Nov 2017 17:39:04 -0600
cl-asdf (2:3.3.0-1) unstable; urgency=low
New milestone:
* Build-plan: Extensively revised the build plan process so that
:DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems
change (which didn't work before). See our ELS demonstration about it:
"Delivering Common Lisp Applications with ASDF 3.3"
< https://github.com/fare/asdf2017 >
* Internals: to support the above, many ASDF internals have changed.
ASDF now has the notion of multiple build phases to a common build session
(which generalizes the previous build cache). ASDF considers loading a .asd
file as an operation DEFINE-OP, and tracks as dependencies files mentioned
during in :LOAD-FILE-FORM statements, etc. Some code has moved to new
files or among old files, and between packages. Actions are now
uniformly represented as a CONS of an OPERATION and a COMPONENT, where
in some cases previously only the class of the operation was
preserved. Forcing is constrained to be uniform across all phases of a
top level ASDF operation invocation. Fixed the protocol for
resetting systems being (re)defined, allowing subclasses to define
default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current
maintainer of ECL, for which it was originally designed, decided
that it could never be made to work properly, after all.
* ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP
circularity, asdf.asd with no longer causes uiop.asd to be loaded.
A standalone UIOP won't be loaded at all unless it's strictly more recent
than ASDF.
* Tests: tests for new capabilities and bugs. Test backtraces can be disabled.
* Documentation: a number of improvements and clarifications.
* Feature: a new feature :asdf3.3
* ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0,
in a way that works on top of supported APIs (we still recommend you migrate
to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME.
* Deprecation: starting to emit STYLE-WARNINGs for deprecated
functions. Will gradually escalate to true WARNINGs and then ERRORs.
-- Robert P. Goldman Sun, 20 August 2017 21:00:00 -0500
cl-asdf (2:3.2.1-1) unstable; urgency=low
New release:
* source-registry: resolve conflicts in a way compatible with Quicklisp.
* Upgrade: make the upgrade logic more robust, especially on CCL.
* Require-system: better normalize module vs system names on CMUCL MKCL SBCL.
* Logical pathnames: fix bad-system-name warning behavior when using LPNs.
* XDG: skip empty entries, for compatibility with Ubuntu
* Bundles: numerous fixes for bundles especially so for ECL and MKCL.
Don't try to combine .a's as it's not portable; only ever combine but .o's.
Getting rid of the *load-system-operation*, now it's always load-op.
* launch-program: more fixes, notably for ECL, clasp.
* Deprecation: fix issues with the deprecation schedule of some functions.
* Test and Release: fixes to the release process and to a few tests.
* Documentation: a document describing best practices when using ASDF.
-- Francois-Rene Rideau Sun, 03 Avril 2017 14:49:29 +0100
cl-asdf (2:3.2.0-1) unstable; urgency=low
New milestone:
* launch-program: new UIOP API for asynchronous subprocesses, now available
on: abcl allegro clozure cmucl ecl (and lispworks os-unix) mkcl sbcl scl.
Big thanks to Elias Pipping for this significant contribution!
* parameter-error, not-implemented-error: new UIOP functions to better signal
abuse of parameters in function calls, or lack of function implementation.
* with-deprecation macro in UIOP signals style-warnings, then warnings,
then errors when deprecated functions are used. This macro is now used
for all deprecated functions in ASDF.
* require-system, component-loaded-p fixed to not reload .asd files,
and to work in presence of preloaded-systems, that are now eagerly loaded.
* registered-system added as an abstraction for internals and extensions.
* make-operation is now the only supported way to create an operation;
calling make-instance directly will raise an error. Update your software!
* Removal of several obsolete backward-compatible internals:
if-component-dep-fails, operation-forced. Update SLIME!
* Robustness and portability fixes all around uiop, notably dealing with
directory access, bundles on ECL and MKCL or with cffi-toolchain,
dealing with a fatal-condition, surviving use of "logical" pathnames, etc.
* Tests improved and extensively run on Linux, macOS and, notably, Windows,
with recent versions of all the maintained CL implementations.
* Internals of ASDF systematically cleaned up and documented.
* Build, test, release infrastructure improved, both classic and asdf-tools.
* Documentation updated.
-- Francois-Rene Rideau Sun, 08 Jan 2017 20:45:29 -0500
cl-asdf (2:3.1.7-1) unstable; urgency=low
Bug fix and portability release:
* Fix compilation on Genera.
* Fix UIOP:FILE-EXISTS-P for dotfiles on CCL.
* Fix infinite loop in source registry configuration that can occur when
there are cycles in the filesystem (typically caused by symlinks)
on some CL implementations.
* Miscellaneous bug fixes.
* Documentation improvements.
* Restore original Makefile.
-- Robert P. Goldman Wed, 23 Mar 2016 09:34:14 -0500
cl-asdf (2:3.1.6-1) unstable; urgency=low
Bug fix and portability release:
* Fix backtrace on SBCL.
* Fix RUN-PROGRAM of string (shell command) on Windows SBCL (ticket
#1501373).
* Fix a number of issues with bundle operations (especially on
non-C-compiler-based implementations).
* Fix component-finding in package-inferred-system.
* Fix race condition between multiple concurrent lisp processes
doing ASDF builds (ticket #1483948).
* Fix misplaced fasl cache on Windows.
* Miscellaneous bug fixes.
* Documentation improvements.
-- Robert P. Goldman Sat, 17 Oct 2015 15:01:34 -0500
cl-asdf (2:3.1.5-1) unstable; urgency=low
Bug fix and portability release:
* Add immutable-system support (thanks to Dave Cooper). This support
should be regarded as preliminary and subject to change.
* Substantially improved operation on Windows: many bugfixes and improve-
ments to UIOP functions that interface with the operating system.
* Add CLASP support.
* Many miscellaneous fixes for issues on individual implementations,
notably UIOP incompatibility introduced by SBCL 1.2.12, support for
LispWorks 7 character types, fixes to chdir on ABCL, improvements
to run-program on Windows.
* Added OS-COND to UIOP to paper over some incompatibilities about when
and how operating system can be detected on different implementations.
Made OS predicates run test at runtime so you can bind *features* from
a target system and determine its OS.
* Fixes to XDG configuration directory handling. Try to stick to the
XDG spec, rather than guessing what it should be on different platforms.
To recognize this, change UIOP functions about XDG files to "XDG-"
prefixes.
* Documentation improvements.
-- François-René Rideau Sat, 18 Jul 2015 16:51:50 -0500
cl-asdf (2:3.1.4-1) unstable; urgency=low
[ Robert P. Goldman ]
Bug fix release:
* Remove compatibility stubs for old bundle classes (not working
properly, anyway), these are now available in a contrib.
* Add INPUT-STRING function to UIOP.
* For developer and tester convenience, bring all the external
dependencies into the git repo as submodules. See target make ext
* Optionally speed up registry search by providing a cache for
the SOURCE-REGISTRY. See the cache-generating script in:
asdf/tools/cl-source-registry-cache.lisp
* Fixes to tests and documentation.
* Many minor bugfixes.
-- François-René Rideau Thu, 09 Oct 2014 21:18:21 -0400
cl-asdf (2:3.1.3-1) unstable; urgency=low
Bug fix release:
* A bug in 3.1.2 caused errors when hot-upgrading from 3.1.2 ASDF.
* Fix bugs in ASDF component search caching. In some circumstances,
aggressive caching (particularly of negative results) interfered with
error-handling through restarts. Also, in some cases use of caching
interfered with error-checking. Some of these issues are discussed in
ticket #1335323 on launchpad.
* Miscellaneous bug fixes and tweaks to UIOP.
* Documentation improvements.
-- Francois-Rene Rideau Mon, 14 Jul 2014 16:54:49 -0400
cl-asdf (2:3.1.2-2) unstable; urgency=low
New release:
* ~/common-lisp/ is now present by default in the source-registry, so
you don't need to configure anything if you put source code there.
* package-inferred-system implements the one-file, one-package, one-system
paradigm of quick-build and faslpath as an extension to ASDF 3.
* non-propagating-operation replaces OPERATION for operations as a base class
to inherit from for operations that do not propagate,
whereas for backward compatibility with ASDF 1 and 2,
subclasses of OPERATION implicitly propagate DOWNWARD and SIDEWAYs.
Failure to explicitly inherit from one of the explicitly propagating
or non-propagating classes will result in a WARNING for now.
* Accept strings as operation class designators in DEFSYSTEM, which
provides better integration of ASDF extensions loaded using
DEFSYSTEM-DEPENDS-ON.
* force-not now takes precedence over force, and systems named in the
*immutable-systems* set (represented as an equal hash-table) are always
forced-not, and even their .asd is not refreshed from the filesystem.
* portability is much improved, with support for the latest GCL, and
fixes for ABCL, CLISP, ECL, LispWorks, MKCL, SBCL, XCL, etc.
* bundle support was refactored, with many fixes to previously uncommon cases.
ECL support is fixed, MKCL added, with a common extension to build programs
without pulling in UIOP and with it the compiler.
image-op was added to create heap images for use with e.g. cl-launch.
load-fasl-op was renamed to load-bundle-op, fasl-op to compile-bundle-op,
binary-op to deliver-asd-op, and so forth for the monolithic- variants;
previous names remain available for backward compatibility.
* robustness: Test improvements and new tests.
Added missing dependencies in asdf.asd itself(!).
Fixes to version-satisfies (thanks to stassats), to the file-stamp cache.
Fix to regression from 3.0.2.12 whereby ASDF failed to avoid downgrading.
Many cleanups. Many explanatory updates to source code comments.
* run-program tweaked again, notably on Windows, on CLISP, and
on implementations without a native run-program. On Windows, we
punt on trying to ensure no final space is ever echo'ed by CMD.EXE " ".
* provide both "asdf" and "ASDF" to play nicer with various Lisps.
* upgrading from a sufficiently forward-compatible version (currently: 2.33)
will be less disruptive of ASDF data and enhancements in the current image:
previously loaded systems will not be cleared anymore,
variables defined with defparameter* will not be reset.
Punting on upgrades from ASDF 1 for more robust behavior.
* make is the new name for build-system, as an experimental alternative
interface to building software with ASDF — it operates with build-op,
which itself delegates to *load-system-operation* by default.
Prepare-op also delegates to *load-system-operation* on systems.
You might bind that variable to load-bundle-op instead of load-op.
* uiop much improved so as to be used with Google's build system blaze:
with-temporary-file, dump-image / restore-image, ensure-pathname,
compile-file*, with-saved-deferred-warnings.
* Added portable API to optimization settings.
* Refine detection of operating systems. os-macosx-p and os-unix-p no
longer mutually exclusive.
* asdf3.1 feature pushed, to signal the slew of significant improvements
in over a year since initial ASDF 3.0 pre-release (i.e. version 2.27).
* Substantially rewritten, updated, and expanded manual.
* TODO updated.
-- Francois-Rene Rideau Mon, 19 May 2014 20:07:40 -0400
cl-asdf (2:3.0.3-1) unstable; urgency=low
New release:
* Run-program much improved, with a slight backward incompatibility.
See the new documentation about it.
* Portability enhanced, with more robust Windows support,
plus patches for CCL, CLISP, LispWorks, XCL.
* UIOP improved, with a README, more docstrings, a few new functions
(println, writeln, stripln, ensure-gethash, vomit-output-stream),
and bugfixes (to ensure-function, with-temporary-file, split-string).
* Debian installations that don't export XDG_DATA_DIRS will benefit
from the fix to split-string, as the bug was basically disabling
the default source-registry entry for /usr/share/common-lisp/source//
Closes: #723977
* Minor tweaks to the defsystem, mostly to print more information
in some situations, less in other situations, but also to better
handle systems with secondary names like foo/bar, a fix for user
functions in output-translation, and to :version (:read-file-...)
* Documentation somewhat updated.
-- Francois-Rene Rideau Tue, 22 Oct 2013 22:30:12 -0500
cl-asdf (2:3.0.2.4-1) unstable; urgency=low
UIOP:DIRECTORY* fixed to NOT follow symbolic links on LispWorks.
Fix handling of :at key in :read-file-form.
Fix package issue for system-definition-error (lp #1206173).
Some docstring updates. Also documentation updates.
-- Francois-Rene Rideau Tue, 03 Sep 2013 12:17:21 -0500
cl-asdf (2:3.0.2-1) unstable; urgency=low
Improve support for CMUCL, ABCL, restore MCL support.
TRAVERSE is deprecated (moved to BACKWARD-INTERFACE), use
MAKE-PLAN instead.
Added DLL-OP and MONOLITHIC-DLL-OP for ECL.
-- Robert P. Goldman Tue, 02 Jul 2013 12:05:57 -0500
cl-asdf (2:3.0.1.3-1) unstable; urgency=low
Add some backward-compatibility to the debian package,
with a symlink from asdf.lisp to build/asdf.lisp.
-- Francois-Rene Rideau Sun, 02 Jun 2013 00:56:50 +0200
cl-asdf (2:3.0.1.2-1) unstable; urgency=low
ASDF 3.0.1.2 fixes issues with the debian package itself.
It also includes fixes to run-program and run-shell-command.
-- Francois-Rene Rideau Mon, 27 May 2013 22:44:50 -0400
cl-asdf (2:3.0.1-1) unstable; urgency=low
ASDF 3.0.1 is an emergency release for better compatibility with Quicklisp.
* version-satisfies now uses uiop:version<= for comparison,
and does not check for a same major version number,
like version-compatible-p does, which was the
undocumented behavior since ASDF 1.
-- Francois-Rene Rideau Mon, 16 May 2013 19:20:28 -0400
cl-asdf (2:3.0.0-1) unstable; urgency=low
ASDF 3.0.0 is the first official release of ASDF 3;
ASDF 2.27 to 2.33 were pre-releases.
Since 2.33, the following changes were done:
* Portability: have *uninteresting-conditions* be empty by default.
Move stuff to *usual-uninteresting-conditions*, unused by default.
Will make the SBCL team happy. Also, fix tests on ABCL.
Fix regression of program-op on ECL, by implicitly linking in UIOP or ASDF.
* UIOP: improvements to slurp-input-stream and thus run-program,
notably accepting T as alias for *standard-output*,
for better backward-compatibility of the deprecated run-shell-command.
New macro with-output-file.
* POIU support enhanced with various tweaks.
* Build cleanup so make and concatenate-source-op create the same asdf.lisp
-- Francois-Rene Rideau Mon, 15 May 2013 23:57:22 -0400
cl-asdf (2:2.33-1) unstable; urgency=low
ASDF 2.33 is a set of cleanups since 2.32.
Since previous release 2.32, it includes the following changes:
* Portability tweaks for ABCL, Allegro, CCL, CLISP, ECL, LispWorks, SBCL.
* deferred-warning received yet more improvements for CCL.
* upgrade is made more robust in many cases, notably for ECL, SBCL,
or when using UIOP with an old ASDF<=2.26.
* Packages have been tweaked to pass more tests,
notably wrt what symbols are exported.
* Image lifecycle support is improved, thanks to deploying ASDF3 for QRes.
More options for dump-image on CCL; handle reentrance in restore-image.
* delete-directory-tree, delete-empty-directory, copy-file,
directory-exists-p, file-exists-p were added to UIOP,
also better strcat, with reduce/strcat, base-string-p, etc.
* Recompilation avoided for things already done by defsystem-depends-on.
* monolithic-fasl-op was fixed in cases when the main system has components.
* fasl-op and monolithic-fasl-op now work on ABCL trunk and upcoming 1.2.0,
and will eventually replace the ABCL-JAR contrib.
* *uninteresting-conditions* was added as a common list of conditions
shared between the compile-time and load-time muffled conditions.
-- Francois-Rene Rideau Thu, 04 Apr 2013 01:54:26 -0400
cl-asdf (2:2.32-1) unstable; urgency=low
ASDF 2.31 is yet another bug fix release in preparation of an upcoming ASDF 3.
Since previous release 2.31, it includes the following changes:
* deferred-warning checks are now disabled by default,
to enhance backward compatibility with ASDF 2.26 and earlier.
In the future, we will enable them by default,
but not until we implement a smoother transition plan.
* UIOP is the new official name for ASDF-DRIVER.
"Utilities for Implementation- and OS- Portability".
Old names remain as package and system nicknames:
. ASDF/DRIVER ASDF-DRIVER ASDF-UTILS
* require-system so systems may depend on implementation-provided modules.
* auto-upgrade attempt in operate *before* the implicit find-system.
* class specification for components can now be a string to be read as a symbol.
* feature conditional dependencies are now debugged and tested:
. :depends-on ("some-system" (:feature :foo "other-system))
we only recommend them for dependencies between systems;
within systems, we recommend you use feature-conditional components with
. :if-feature :foo
and we only provide limited support for the deprecated legacy way of using
feature-conditionals with a module having :if-component-dep-fails :ignore
while its components specify things like:
. :in-order-to ((compile-op (feature :foo)))
* read-from-file for :version specification is made more useful by using
the ASDF-USER package rather than CL (into which interning is forbidden)
to read the files.
-- Francois-Rene Rideau Tue, 05 Mar 2013 19:35:43 -0500
cl-asdf (2:2.31-1) unstable; urgency=low
ASDF 2.31 is another bug fix release in preparation of an upcoming ASDF 3.
Since previous release 2.30, it includes the following changes:
* *default-encoding* is now UTF-8. As tested with cl-test-grid,
This is a boon for most programs,
that will compile in a more predictable way in a wider range of settings.
A handful of unmaintained outliers still need to be fixed.
* Downgrade is now explicitly avoided. ASDF will issue a warning
if your system is misconfigured in a way that specifies downgrade,
but will then ignore the specified ASDF downgrade.
* version specifications, when invalid, will lead only to a warning for now;
a future ASDF3 may restore the behavior of ASDF 2.27,
that raises an errors when there is a bad :version specification,
but for now, backward compatibility prevails.
* ECL support received several bug fixes.
* precompiled-system support was notably fixed, enabling single-fasl
deployment of SBCL contribs.
-- Francois-Rene Rideau Mon, 25 Feb 2013 19:02:14 -0500
cl-asdf (2:2.30-1) unstable; urgency=low
ASDF 2.30 is another bug fix release in preparation of an upcoming ASDF 3.
Since previous release 2.29, it includes:
* syntax around loading .asd files made more backward-compatible,
by *not* (for now) binding *readtable* and *print-pprint-dispatch*
to standard values, because it breaks some indelicate libraries.
We intend to reinstate these bindings at some point in the future,
but only after more implementations enforce the immutability
of these standard values like SBCL does,
and after fixed libraries have been released.
This notably unbreaks iolib 0.7.3 (for readtable) and
defdoc (for the pprint-dispatch table).
* portability fixes for CCL and CMUCL.
On CCL, punt on package upgrade, and on reify-simple-sexp.
On CMUCL, fix raw-print-backtrace and hostname.
* exported symbols cleaned up somewhat.
-- Francois-Rene Rideau Fri, 20 Feb 2013 17:53:32 -0500
cl-asdf (2:2.29-1) unstable; urgency=low
ASDF 2.29 is a bug fix release in preparation of an upcoming ASDF 3.
Since previous release 2.28, it includes:
* deferred-warnings support for Allegro, CMUCL, SCL;
fixes to the CCL support.
* Upgrade fixes regarding fallback system versions;
making it possible (via massive use of eval-when)
to compile ASDF without loading it first.
* Compatibility with private use of :D package nickname
by not claiming it for package ASDF/DRIVER anymore.
Also explicitly handle NIL in safe-file-write-date,
in case the implementation doesn't issue a file-error in that case;
make UTF-8 the default encoding for with-input-file.
Be portable to #+(and sbcl (not sb-eval)).
* Bugfixes to old bugs: inline-methods can now be unqualified (lp#485393),
defsystem-depends-on accepts arbitrary specs, not just names (lp#1027521).
-- Francois-Rene Rideau Fri, 16 Feb 2013 15:07:24 +0100
cl-asdf (2:2.28-1) unstable; urgency=low
ASDF 2.28 is a quick patch to ASDF 2.27 to make it work better with
systems that specify a relative pathname, then at runtime (e.g. in tests)
use merge-pathnames or merge-pathnames* against it expecting a directory.
-- Francois-Rene Rideau Fri, 01 Feb 2013 17:07:53 -0500
cl-asdf (2:2.27-1) unstable; urgency=low
ASDF 2.27 is actually an almost complete rewrite of ASDF, and
should be considered a pre-release for an upcoming ASDF 3.
It nevertheless maintains backward compatibility with the current practice,
and is tested against the software in Quicklisp.
* ASDF-BUNDLE was merged into ASDF.
This notably means fewer headaches for users of ECL;
it also means a new load-fasl-op feature for all users of a modern CL,
making it easier to deliver software as a single fasl.
After release, I plan to offer a patch so SBCL use that for its contrib's.
All remnants of asdf-bundle's predecessor asdf-ecl were removed.
* DECADES-OLD bugs of notable significance were fixed:
(a) changes in dependencies now trigger a rebuild across systems, and
https://bugs.launchpad.net/asdf/+bug/479522
(b) timestamps are now correctly propagated (they weren't at all!)
https://bugs.launchpad.net/asdf/+bug/1087609
Fixing them required a complete rewrite of ASDF's dependency tracking.
In olden days, some have argued for not rebuilding systems that :depend-on
a modified one as a "feature". It really isn't. On the other hand,
it is now possible to explicitly prevent a system from being rebuilt, using
an actual feature, :force-not, which was released in 2.21 in April 2012.
* PREPARE-OP was introduced to fix a conceptual bug in the ASDF object model.
It corresponds to "loading the dependencies of a component and its parents"
and is explicitly depends-on'ed by LOAD-OP and COMPILE-OP of the component,
instead of their implicitly depending on it via the TRAVERSE algorithm,
which implicit dependency proved fatal in cases revealed by the above bugs.
It propagates upward in the component hierarchy, rather than downward,
like the TRAVERSE algorithm used to systematically propagate dependencies.
* TRAVERSE was gutted out and factored into reusable higher-order functions
and objects, which not only fixes the above conceptual bug, but makes for
semantics that are simpler to implement, possible to understand,
easier to extend, and less limited in expressivity.
TRAVERSE doesn't automatically propagate operations
downward the component hierarchy anymore;
propagation is now implemented through methods on COMPONENT-DEPENDS-ON.
* COMPONENT-DEPENDS-ON is now more powerful:
it can express dependencies on arbitrary operation objects
(i.e. operations of the same class can have different options)
acting on arbitrary component objects
(i.e. not necessarily siblings of the current component).
The ASDF object model can now express arbitrary build graphs, with
no more special magic for children components vs other dependencies.
* COMPONENT-DO-FIRST is no more. It used to specify some dependencies
that were skipped if no re-build was triggered based on local timestamps;
except that ASDF 1 didn't let the users control it,
and ASDF 2 only let you control it since 2.017 or so.
In ASDF 3, COMPONENT-DEPENDS-ON is used for all dependencies,
and all are consulted to correctly propagate timestamps.
However actions meant for in-image side-effects are included
only if needed, and might be visited twice by TRAVERSE,
first without the needed-in-image-p flag, another time with.
You can use :IN-ORDER-TO everywhere you used to use :DO-FIRST, if ever.
* FORCE and FORCE-NOT now correctly distinguish T from :ALL in addition to
a list of system name specifiers, as per the original specification
(which was never implemented in ASDF 1). Additionally,
builtin systems (such as SB-BSD-SOCKETS on SBCL) cannot be forced
(which doesn't work on SBCL).
* IF-FEATURE is a new attribute of components that accepts an arbitrary
feature expression such as (:and :sbcl (:or :x86 :x86-64)),
which when defined is a precondition to the component being enabled;
when the expression is false, the component is disabled,
and dependencies to it are removed.
It replaces the misguided :if-component-dep-fails attribute of modules
and the accompanying :feature feature, which were dropped.
They were not very expressive, clunky to use, and relied on baking
conceptually dubious non-local behavior in the old TRAVERSE algorithm,
which belied the object model and defeated other features.
Unhappily, this breaks backwards compatibility for the few who used it,
namely sb-grovel, nibbles and ironclad.
A minimal compatibility layer is included that allows ASDF 3 or later
to load the SB-GROVEL of old versions of SBCL; but it won't suffice
to load an old version of nibbles or ironclad; please upgrade them
a recent version that was updated to support ASDF 3.
* CONCATENATE-SOURCE-OP is a new operation that builds a single Lisp file
from all the source files in a system,
which allows you to develop in a structured way with many compact files,
yet deliver a large single file. Other related operations allow you
to load that source file, or compile and load it,
or do the same while including all other system dependencies.
ASDF was broken up into lots of small files, to be delivered that way.
* FOO/BAR/BAZ names will be recognized by defsystem as having to be located
in a file called foo.asd. This is backward compatible in the case where
you somehow arranged to load foo.asd before to use the other subsystems,
except now ASDF can find the subsystems by name without the main system
definition having been loaded. See uses of function PRIMARY-SYSTEM-NAME.
* BUILD-OP is a generic operation that can do the "right thing" for
each system, without users having to maintain the knowledge of
what the right thing is for each system they may indirectly depend on.
* Convenience methods were added to most exported generic functions,
so you can (input-files 'compile-op '(system1 "file1")) instead of
(input-files (make-instance 'compile-op) (find-component 'system1 "file1"))
This notably makes it much easier to interact with ASDF at the REPL
and debug your system definitions or ASDF extensions (or modifications).
* Packages were introduced as ASDF was broken up into small files.
Each file now has its own package, importing and exporting functionality,
following the style made popular by faslpath and quick-build.
ASDF does not yet include builtin support for quick-build or faslpath
systems and dependencies, however. Possibly in ASDF 2.28.
* ASDF-DRIVER is a separately-usable library for Common Lisp runtime support.
It is transcluded in asdf.lisp (i.e. when delivering ASDF as a separate
bootstrap file, the contents of ASDF-DRIVER have been included in it),
but can also be used as a separate ASDF system on top of an old ASDF
(within limits: CLISP and XCL still need a recent ASDF).
The package ASDF/DRIVER (with short nickname :D) re-exports
all the functions that ASDF needed to run portably.
* Pathnames are a notable part of ASDF-DRIVER, required to deal
portably with pathnames despite the many bugs and variations
from platform to platform. See notably in pathname.lisp,
MERGE-PATHNAMES*, SUBPATHNAME, PARSE-UNIX-NAMESTRING,
PARSE-NATIVE-NAMESTRING, ENSURE-PATHNAME, and many many more.
* Pathname use by ASDF was also improved in countless small ways,
closing more buglets that appeared in as many corner cases.
For instance, system pathname defaulting was improved,
and systems not associated with a file will now have NIL as their pathname,
which will otherwise be correctly treated.
Many things that would vary depending on implementation will work better.
Also, although we cannot strongly enough disrecommend the use of so-called
"logical pathnames", especially where portability matters in any way, we
support them better than ever within the limitations of the implementation.
* Image lifecycle support is included in ASDF-DRIVER (and thus ASDF);
this standardizes things like access to *COMMAND-LINE-ARGUMENTS*,
declaring an entry-point to a program, hook functions and/or a prelude
to run before to start the main entry, and a postlude and/or hook functions
to run before to dump an image, dumping or creating an image, etc.
* PROGRAM-OP allows you to create standalone executables on implementations
that support it: CLISP, Clozure CL, CMUCL ECL, LispWorks, SBCL, SCL.
A hello-world-example system shows demonstrates how to use it.
* Run-program is a replacement for the old run-shell-command.
Unlike run-shell-command, it is portable to Windows as well as Unix,
it can avoid going through a shell and will sensibly escape arguments
when it does go through a shell, and it has a usable interface
to either capture program output or run the program interactively.
This supersedes run-program/ previously available from xcvb-driver,
including several improvements and portability fixes.
* Conditions can be selectively muffled around compilation thanks to
the an around-compile hook and the *UNINTERESTING-COMPILER-CONDITIONS*
parameter, and around loading with *UNINTERESTING-LOADER-CONDITIONS*
which is _appended_ to the former during loading.
This supersedes the functionality previously available from xcvb-driver
and its thin wrapper asdf-condition-control, which was retired.
* Deferred warnings for yet undefined functions, that in a single-session
build are usually signaled at the end of a compilation unit, will be
saved and reassembled to make each system a compilation unit of its own,
even when compilation of file happens across multiple sessions;
only CCL and SBCL support this feature at this time.
I welcome patches for other compilers, for which ASDF will _not_
wrap an implicit WITH-COMPILATION-UNIT around its operate method anymore.
* COMPILE-FILE* was beefed up to support all these features and more,
and the Right Thing(tm) on all implementations, including
support for their various extensions.
* Internals have been refactored, and some sorry features were excised.
The semantics of OPERATION-DONE-P is simplified and now well-specified.
FIND-COMPONENT will pass component objects through, and
a corresponding FIND-OPERATION replaces MAKE-SUB-OPERATION.
Many internal accessors were renamed, after checking on Quicklisp
that no one was using them.
* Portability updates were done for each and every implementation.
Working support for GCL 2.6 was restored, with notable limitations
including lack of support for output-translations or logical-pathnames.
* TRUENAME resolution can be reliably turned off in all cases where
ASDF was using them by setting the variable *RESOLVE-SYMLINKS* to NIL.
This is useful if your operating system makes that operation slow,
or if your build system uses symlinks to content-addressed storage
in which case TRUENAME just does the wrong thing.
* PERFORMANCE of ASDF3 is somewhat slower (about 70%) than ASDF2
when *RESOLVE-SYMLINKS* is true, and slightly faster when it is false;
but underneath ASDF3 does much more work than ASDF2.
* VERSION strings can now be specified as having to be fetched
from a file using a (:read-file-form ) specification,
that can use an optional :at keyword argument to specify
a form or subform other than the first form in the file,
as per the utility asdf-driver:access-at. For instance,
if your file specials.lisp is a defpackage, an in-package
and a defparameter of the version, then you could use:
(:read-file-form "specials.lisp" :at (2 2))
This makes it easier for developers to manage versioning
of one or multiple systems with a single master version location.
* COMPONENT-PROPERTY and the :PROPERTIES initarg of defsystem are deprecated;
though they are still supported for now, we intend to retire them
in a hypothetical future ASDF 4. To replace them, we recommend you instead
define a subclass of asdf:system, with new slots and/or initargs, and
use them with the :defsystem-depends-on and :class options of defsystem.
We looked at usage of in Quicklisp systems, and added to asdf:system
these slots corresponding to the general-purpose metadata we saw:
:homepage :bug-tracker :mailto :long-name
* Self-Upgrade of ASDF will happen automatically as the first thing
before any attempt to build anything, as it was determined that
doing it in the midst of a build breaks everything, and it is not
otherwise possible to reliably detect in advance whether ASDF may
be needed in such midst. If you don't want an ASDF upgrade, just
don't configure your source-registry to include any copy of ASDF.
* DEFINE-PACKAGE is provided as a replacement to DEFPACKAGE that supports
hot upgrade of software where some packages have changed.
It also provides new forms :MIX and :REEXPORT which can be quite practical.
* ASDF-USER is now the shared package in which all .asd files are loaded.
There will be no more temporary packages created
around the loading of each .asd file. This shouldn't change much for users:
you should probably still define your own private package whenever you
define new classes, functions, or variables, to avoid namespace conflict;
except now, when you don't, you can still access your defined symbols
after the file is loaded.
ASDF is not the right place to fix Common Lisp namespace issues, and
these temporary packages were never a successful fix anyway;
indeed, users were still required to define their own package as soon
as they wanted to define variables, functions and classes
in the system file.
* ASDF3 was added to the *features* so you can detect the presence of
this massively updated ASDF and its new features with #+asdf3.
* Documentation received some updates, though by no means comparable
to the complete rewrite of the code base.
* Tests were updated, notably including support for bundles, encodings,
run-program, and more. They were successfully run on
abcl allegro allegromodern ccl clisp cmucl
ecl ecl_bytecodes lispworks sbcl scl xcl
Manual tests were run on gcl2.6 genera lispworks-personal-edition.
Untested remain cormancl mkcl rmcl.
The internal test system itself was massively improved.
* ASDF-DEBUG is a simple utility to make your favorite debugging primitives
available in the package you're debugging. See contrib/debug.lisp
and the asdf/utility:*asdf-debug-utility* variable.
* ASDF-UTILS is now but an empty shell that depends-on ASDF-DRIVER.
The ASDF-DRIVER package has the ASDF-UTILS nickname, and exports
all the functionality that used to be in ASDF-UTILS, and much more,
minus a few misdesigned things from ASDF1 that you ought not
to have been using, and for which there are non-broken replacements.
ASDF-UTILS was distributed separately from ASDF; ASDF-DRIVER is available
both as part of ASDF 3 and later and separately.
* POIU was updated. This extension is still distributed separately from ASDF.
It is now much simplified and made correct by construction by
reusing the new TRAVERSE infrastructure of ASDF and now being able to
assume the ASDF object model is a complete description of dependencies.
On SBCL it will handle deferred warnings from background compilations.
Where forking is not supported or not possible because of threads,
it will gracefully fall back to serial compilation.
* INFERIOR-SHELL (distributed separately) was updated to use asdf-driver
instead of xcvb-driver. It notably provides a richer interface to
the RUN-PROGRAM functionality.
* SLIME support for ASDF was significantly enhanced.
It is distributed with SLIME, separately from ASDF.
See latest slime checkin from 2013-01-29.
It requires ASDF 2.014.6 or later (as used by 2011 quicklisp releases).
We recommend that you should include slime-asdf in your slime-setup
and that in your ~/.swank.lisp you should include:
(in-package :swank)
(pushnew 'try-compile-file-with-asdf *compile-file-for-emacs-hook*)
-- Francois-Rene Rideau Fri, 01 Feb 2013 13:27:12 -0500
cl-asdf (2:2.26-1) unstable; urgency=low
* Package change: removed the old ASDF-UTILITIES package nickname for ASDF.
Please use the separate ASDF-UTILS system and package for utilities.
* compile-file-pathname* bug fix for :output-file nil. Fixes lp#1067617.
* get-folder-path factored out of various functions, thanks Martin Simmons.
* Lispworks: enable sys:get-folder-path on Personal Edition for Windows.
* ECL: add proper wrapping-source-registry
-- Francois-Rene Rideau Thu, 30 Oct 2012 08:09:06 +0900
cl-asdf (2:2.25-1) unstable; urgency=low
* Lispworks: avoid professional edition functions in personal edition.
* CormanLisp: improve support a little bit.
* Exports: don't export utilities anymore. Please use asdf-utils.
-- Francois-Rene Rideau Thu, 27 Sep 2012 18:35:21 -0400
cl-asdf (2:2.24-1) unstable; urgency=low
* ACL: handle SMP vs non-SMP builds in Allegro 9.0
* MKCL: add support for ManKai Common Lisp
* ECL: merge improvements from ECL git. Refactor ECL support somewhat.
* Remove broken-fasl-support: first, cormanlisp is supposed to have fixed it;
second, cormanlisp is dead;
third, one can now (setf *load-system-operation* 'load-source-op) instead
while using asdf:load-system.
* renaming ends-with to string-suffix-p to avoid conflict with alexandria.
* Refactor load-system to use *load-system-operation*,
and change require-system and module-provide-asdf to use that.
Also note:
* We recommend you use asdf-utils to access the utilities in asdf.
Some time next year, we may stop exporting the utilities from asdf itself.
* To avoid conflicts between alexandria, fare-utils, xcvb-driver,
asdf-utils, etc., you can use xcvb-utils that solves the conflicts.
Or you can use fare-utils:define-package-mix that will help you
automatically resolve them.
-- Francois-Rene Rideau Sat, 25 Aug 2012 08:05:21 -0400
cl-asdf (2:2.23-1) unstable; urgency=low
* add new :compile-check argument to compile-file* and around-compile-hook.
This allows for consistency check of .fasl output before the file can
possibly be seen by other builds (i.e. no race condition).
* export more utilities for dealing with pathnames from environment.
-- Francois-Rene Rideau Tue, 17 Jul 2012 11:03:32 -0400
cl-asdf (2:2.22-1) unstable; urgency=low
* require is now mapped to the recently defined require-system,
not to load-system anymore.
* more sensible inheritance semantics for default-component-class,
which can be either a class or a class name.
* accept wildcards in directory-files for physical pathnames. lp#1000842
-- Francois-Rene Rideau Tue, 12 Jun 2012 11:22:33 -0400
cl-asdf (2:2.21-1) unstable; urgency=low
* New features:
* Most importantly, encodings.
ASDF now lets you specify an :encoding for a system, module or component,
that is used when loading or compiling Lisp files. See the documentation.
By default, the only useful value is :utf-8, and
we recommend you use UTF-8 everywhere.
We intend to make UTF-8 the default in the future
(current default is the legacy behavior of using whichever implicit
default your underlying implementation is currently configured to use).
An extension asdf-encodings is available that supports more encodings,
including autodetection of encoding from either emacs-style declaration
-*- Mode: Lisp ; coding: utf-8 -*- or content.
* require-system works like load-system, but won't try to load or update
systems that have already been loaded, as listed by loaded-systems.
More generally, you can specify a list of systems as :force-not argument
to load-system and the specified systems won't be loaded or updated.
* You can specify :force-not and a list of systems when loading a system,
* You can now specify :hostname in your asdf-output-translations,
so you can easily share a home directory via the network
yet split its fasl cache between several subtly different machines.
* Bug Fixes:
* lp#982285. since 2.014.4, the default source-registry
was skipping anything from /usr or XDG_DATA_DIRS,
because of a missing test in getenv-absolute-pathnames. Fixed in .15.
* In 2.019.9 aka 2.20, ECL support was broken by using
a function in the wrong package (defined in cl-user). Fixed in .1.
* logical-pathname support was somewhat broken since 2.017.6,
due to the way most implementations fail to read physical namestrings
when *default-pathname-defaults* is a logical-pathname.
Fixed, together with other logical-pathname issues, and
a test case was added to the test suite to ensure no further regression.
Works great modulo quirks around implementation bugs on CLISP and Allegro.
* Make upgrading ASDF more robust on CMUCL, LispWorks, SBCL.
* Minor tweaks:
* Use :unspecific in pathname components on more implementations.
* export and/or document more utilities.
* add a few missing compatfmt for Genera.
-- Francois-Rene Rideau Sat, 28 Apr 2012 23:55:23 -0400
cl-asdf (2:2.20-1) unstable; urgency=low
* Portability: support the new CCL fasl numbering API
* Bug fixes: handle various configuration corner cases better
(thanks to Sergey Katrevich and Rupert Warwick).
* Feature: Robert Goldman fixed and documented WEAKLY-DEPENDS-ON.
-- Francois-Rene Rideau Fri, 13 Jan 2012 14:40:12 -0500
cl-asdf (2:2.019-1) unstable; urgency=low
* UI: Create and use a load-systems abstraction,
in view of using it in a system-granular parallelizing backend. (.15)
* Usability: when a system can't be found, there's now a restart to retry
finding a system after reinitializing the source-registry (.10).
* Feature: :around-compile now accepts lambda expressions, and also strings,
so you can specify future wrappers that can't even be read yet. (.11, .12).
* Filesystem: recursing through logical pathnames in LispWorks (.2, .3),
on SBCL as on CMUCL, have asdf:subdirectories follow symlinks (.8., .9)
* Configuration: modify user-configuration-directories and
system-configuration-directories to return all valid directory names
even when they don't exist yet so you may create them (.6), also output
name of non-existing configuration file when opening them for writing (.7),
* Internals: strcat (.5), split locate-systems from find-systems (.6)
* Portability: Debugged CormanLisp support (.1).
Fix type declaration for SCL (.17).
* Bug fix: don't drop pathname components without a / at the end
when reading a path using GETENV (.18). (Bug from 2.017.27)
Closes: #647544.
* Bug fix: don't redefine reinitialize-instance in ways that break
its contract and its clients (such as asdf-dependency-grovel).
Use change-class to reset slots (.16), but not to 'standard-object,
which breaks ecl, rather to a proto-system class (.19), and not
using keys with breaks genera (.21). (Bug from 2.017.3)
* Bug fix: buglet in maybe-add-tree (.4)
* Upgrade: unintern internals of signature changed in 2.017.12 (.13),
have *system-definition-search-functions* not be a defparameter,
but a defvar with a fixup (.14), clear *systems-being-defined* when
upgrading asdf but re-find them immediately because they may be needed
as part of a higher operation (.14).
Unintern some more functions that have changed signature (.20).
-- Francois-Rene Rideau Sun, 27 Nov 2011 16:09:42 -0500
cl-asdf (2:2.018-1) unstable; urgency=low
Bugs:
* Solved a bug due to ASDF reusing components even when the ASDF definition
has changed wildly, leading to bad behavior in incremental compilation
and sometimes total failure of compilation of a new version.
(Thanks to Xach for reporting and RPGoldman for fixing.)
* Fix an issue with ASDF doing the wrong thing in case of a clock skew,
thanks to Andreas Fuchs.
* Simplification of the internals of perform-with-restarts and
traverse's do-dep, that should fix some corner cases and make it
easier to extend or further fix. There scarily doesn't remain
any unedited code from Dan Barlow's original ASDF, though
much of the interface design is preserved.
* Upgrade code slightly simplified, with a particular fix for CLISP;
it is now tested on all supported implementations, not just SBCL.
* Improvements to tests and documentation.
Portability:
* Many implementation specific improvements for ECL:
merge with the ECL upstream version, support for the bytecode compiler.
* Because it is required at least on ABCL, made the Unix vs Windows detection
a runtime rather than compile-time distinction
No more asdf-unix or asdf-windows feature, but
(asdf::os-unix-p) and (asdf::os-windows-p) functions (not exported for now).
Also recognize darwin as Unix ECL.
* Also small improvements for SCL.
Features:
* Bind *default-pathname-defaults* around load-sysdef,
to increase chances of successful pathname parsing in defsystem.
* Fixed run-shell-command on allegro/unix and clisp,
documented the function, noted how it mightn't do what you think on Windows,
marked it as obsolete, promoted as an official replacement my new
xcvb-driver:run-program/process-output-stream
* New :around-compile hook so you can control the syntax, optimization,
and warning level, rename packages and balance compile-time side-effects,
etc., around the compilation of files in your own modules.
* Now exporting function subpathname, to portably make subpathnames.
-- Francois-Rene Rideau Sat, 29 Oct 2011 12:46:22 -0400
cl-asdf (2:2.017-1) unstable; urgency=low
Promoting 2.016.3 as 2.017. Since 2.016, we have the following improvements:
* ABCL: jar translation happier with recent compile-file-pathname* change.
* CCL: see truenamize change below.
* GCL: vain partially reverted attempts at making GCL 2.6 and 2.7 fail less.
* LispWorks: use probe-file for probe-file*
* RMCL: location strings are now POSIX namestrings.
You can thus share configuration files and environment variables
between RMCL and other Lisp implementations on same host.
Use #p"" syntax when you insist on using MacOS 9 style MCL pathnames.
* truenamize: happier when e.g. the *default-pathname-defaults* is #p"",
which is the case notably on CCL.
* Logical pathnames: now preserved by the source-registry's tree directive.
* Upgrade: instead of unintern'ing symbols, use fmakunbound;
however, treat compilation of asdf specially, by always making sure
it is loaded as source before it is compiled,
so that compilation is never an upgrade and never calls fmakunbound, thus
ensuring functions in the continuation of compilation are always fbound.
* Obsolete: dropped support for *system-cache* and get-uid.
* Internals: refactored resolve-relative-location-component.
* Documentation: update wrt to the location DSL.
-- Francois-Rene Rideau Tue, 26 Jul 2011 12:52:49 -0400
cl-asdf (2:2.016-1) unstable; urgency=low
Promoting 2.015.12 as 2.016. Since 2.015, we have the following improvements:
* Portability: fixes for ECL, RMCL, CLISP.
Improvements to Windows configuration.
* Fix to load-source-op (broken in 2.014.13).
* Avoid infinite loops in defsystem in cases of bad interference
between quicklisp and your source-registry.
* Small fixes regarding upgrade, compile-file* :output-file.
* Make defsystem-depends-on much more useful by allowing a system
thus depended on to define the class of the system depending on it.
* Some documentation updates.
Notably, for the sake of CLISP, (require "asdf") is the new canonical way
to load ASDF, instead of (require :asdf). Sigh.
* Better tests, notably wrt hot upgrade.
-- Francois-Rene Rideau Tue, 07 Jun 2011 17:46:15 -0400
cl-asdf (2:2.015-1) unstable; urgency=low
Promoting 2.014.17 as 2.015. Since 2.014, we have the following improvements:
* Portability: support cormanlisp, xcl;
fixes for cmucl, ecl; tweaks for abcl, allegro, clisp, genera, lispworks.
* Feature: un-cerror and actually fix the :force '(sys1 sys2 sys3) feature,
introduced in 2002 and never working before.
* Feature: classes asdf:cl-source-file.cl and asdf:cl-source-file.lsp
for people who use these file type extensions.
* Semantic change: the source-registry eagerly gathers a list of .asd,
rather than querying the filesystem over and over again.
* API change: exposing function asdf:search-for-system-definition as looking
through asdf:*system-definition-search-functions* for either pathnames *or*
(new feature) system objects. Should make quicklisp happier.
* Better support for asdf upgrading itself, with new function
asdf:upgrade-asdf that knows to invalidate old systems when necessary,
and is magically invoked before to build any system that :depends-on asdf.
Make upgrade smoother some cases that were previously broken.
* More robust handling of version strings.
* Declaring function asdf:system-definition-pathname obsolete, but still
supporting it for now, as an alias for asdf:system-source-file.
* Various refactorings of internals. Splitting a function asdf::perform-plan
out of the default asdf:operate method.
asdf::register-system now takes only one argument.
* Tests to prevent the regressions experienced during this development cycle
* Tried and reverted: attempts to make asdf more verbose when it's verbose,
but not verbose by default.
-- Francois-Rene Rideau Tue, 07 Jun 2011 17:38:50 -0400
cl-asdf (2:2.014.3-1) unstable; urgency=low
* yet another debian package attempt
* update to 2.014.3, workaround for ABCL make-pathname bug (same as on XCL).
-- Francois-Rene Rideau Mon, 04 Apr 2011 23:27:30 -0400
cl-asdf (2:2.014.2-1) unstable; urgency=low
* yet another attempt at a debian package.
* update to 2.014.2, adds XCL support.
-- Francois-Rene Rideau Thu, 31 Mar 2011 14:08:09 -0400
cl-asdf (2:2.014.1-1) unstable; urgency=low
* new attempt for a debian package.
* while I'm at it, update to 2.014.1 which will make CMUCL happy.
-- Francois-Rene Rideau Tue, 29 Mar 2011 18:19:19 -0400
cl-asdf (2:2.014-3) unstable; urgency=low
* another attempt with my new GPG key
-- Francois-Rene Rideau Sun, 27 Mar 2011 19:33:43 -0400
cl-asdf (2:2.014-2) unstable; urgency=low
* tweak Makefile for debian packaging.
-- Francois-Rene Rideau Sun, 27 Mar 2011 17:17:15 -0400
cl-asdf (2:2.014-1) unstable; urgency=low
* Blessing 2.013.7 as 2.014.
* Fixed bug preventing upgrade from 2.000 to 2.008 (test added)
* Better support for URL pathnames on SCL (test added)
* Robustified defsystem-depends-on
* Cosmetic changes:
* better more portably readable error messages.
* remove forward references, again (test added)
* canonicalize system names earlier (slight robustness improvement)
-- Francois-Rene Rideau Sun, 27 Mar 2011 16:45:58 -0400
cl-asdf (2:2.013.3-1) unstable; urgency=low
* Packaging 2.013.3 because 2.013 had important issues.
* Fix important upgradability issue with 2.013 (unable to upgrade from
versions 2.00[0-8] that have a separate ASDF-UTILITIES)
* Fix minor verbosity issue (forward reference makes sbcl noisy
when loading asdf.lisp directly as does quicklisp.)
* Also, enhance support for SCL.
-- Francois-Rene Rideau Mon, 21 Mar 2011 16:24:27 -0400
cl-asdf (2:2.013-1) unstable; urgency=low
* Blessing 2.012.12: many small improvements since 2.012.
* Fixes and cleanups for CLISP, ECL, SBCL.
* Added support for two legacy platforms: (R)MCL, Genera
* Cleanup features: now using #+asdf-unix and #+asdf-window
* Many cleanups and improvements regarding our portable pathname layer
* Fixes a regression in source-registry scanning from 2.011.4
* Remember *source-registry-parameter* and *output-translations-parameter*
* Export and document coerce-pathname (f.k.a merge-component-name-type)
* allow description and long-description for all components
* Several documentation updates
-- Francois-Rene Rideau Sat, 19 Mar 2011 20:01:34 -0400
cl-asdf (2:2.012-1) unstable; urgency=low
* Blessing 2.011.9: more fixes to corner cases.
* Added :here directive to pathname DSL,
robustified ECL support,
fixed infinite loop when filesystem clock is in the future,
extended the AOT DSL and made it more futureproof,
fixed how clear-system interacts with map-systems,
fixed use of directory under old SBCLs,
fixed run-shell-command status and version string under clisp,
fixed error messages.
* Synchronized version of asdf.asd and asdf.lisp, automatically.
-- Francois-Rene Rideau Mon, 03 Jan 2011 06:59:17 +0100
cl-asdf (2:2.011-1) unstable; urgency=low
* Mostly same as 2.010.9: several minor tweaks and bug fixes since 2.010.
* Will be happier: users of implementations ACL, GCL; users of libraries
CL-Launch, XCVB; future former users of ASDF-Binary-Locations; people
with missing dependencies (in lieu of error-in-error); people extending
ASDF (notably Stelian Ionescu), who'd like to use keywords to name
component classes.
-- Francois-Rene Rideau Sun, 28 Nov 2010 13:21:34 -0500
cl-asdf (2:2.010-1) unstable; urgency=low
* same as 2.146
-- Francois-Rene Rideau Thu, 28 Oct 2010 15:58:36 -0700
cl-asdf (2:2.009-1) unstable; urgency=low
* new upstream release 2.009, identical to 2.134 from master.
-- Francois-Rene Rideau Wed, 06 Oct 2010 13:26:36 -0400
cl-asdf (2:2.008-1) unstable; urgency=low
* new upstream: removes unwanted exports,
plays nicer with sbcl, cmucl, old clisp.
-- Francois-Rene Rideau Fri, 10 Sep 2010 17:16:06 -0400
cl-asdf (2:2.007-1) unstable; urgency=low
* new upstream, fixes lp#623992 introduced in 2.006, allows upgrade on SBCL.
-- Francois-Rene Rideau Wed, 25 Aug 2010 23:22:13 -0400
cl-asdf (2:2.006-1) unstable; urgency=low
* new upstream, with bug fixes and API changes.
-- Francois-Rene Rideau Tue, 24 Aug 2010 18:43:48 -0400
cl-asdf (2:2.005-1) unstable; urgency=low
* New upstream.
* Don't use dh-lisp
-- Francois-Rene Rideau Tue, 17 Aug 2010 13:57:04 -0400
cl-asdf (2:2.004-1) unstable; urgency=low
* Imported new upstream, try not to diverge from it.
* Remove cl-cclan which was removed from the upstream repository.
* Updated Debian configuration and documentation.
-- Francois-Rene Rideau Wed, 14 Jul 2010 14:06:50 -0400
cl-asdf (2:1.704-1) unstable; urgency=low
* Imported new upstream.
* We now have a makefile for Documentation, use it
* Add debian/source/format for the stupid quilt mess
-- Peter Van Eynde Mon, 19 Apr 2010 21:37:48 +0200
cl-asdf (2:1.627-1) unstable; urgency=low
* New upstream release.
* Added dh_installinfo for info files. (Closes: #560290)
* Incorporated run-shell-command patch for LispWorks. Thanks tianchun!
(Closes: #457919)
* Added info that this version breaks clc
* Fix conflict with clc
* Small patch to make :implementation-type work for clc
-- Peter Van Eynde Thu, 25 Feb 2010 18:36:16 +0100
cl-asdf (2:1.502-1) unstable; urgency=low
* new upstream, back to version numbers.
* added /etc/common-lisp/source-registry.conf.d/ directory
* Added README's to documentation
* it's debian/*.dirs not debian/*.dir\!
* Updated standard version, no real changes
* Added lintian overrides for cl-cclan
-- Peter Van Eynde Mon, 01 Feb 2010 07:31:06 +0100
cl-asdf (1:20091221-1) unstable; urgency=low
* New upstream, version 1.374
-- Peter Van Eynde Thu, 31 Dec 2009 08:36:15 +0100
cl-asdf (1:20090819-3) unstable; urgency=low
* Fixed the loop construct again. (Closes: #546205)
-- Peter Van Eynde Sat, 12 Sep 2009 10:08:23 +0100
cl-asdf (1:20090819-2) unstable; urgency=low
* Fix the loop contruct. This makes ecl fail. (Closes: #545768)
-- Peter Van Eynde Thu, 10 Sep 2009 14:20:11 +0100
cl-asdf (1:20090819-1) unstable; urgency=low
* New upstream, New homepage and new upstream repository.
* changed section to lisp
* now using debhelper v7
* added debian/README.building
* remove cvs2cl from dependencies
* remove upstream ChangeLog
* added dummy watch file
* added ${misc:Depends} to cl-asdf Depends
* Updated Standards-Version no real changes
* fixed Section of cl-asdf.doc-base
-- Peter Van Eynde Tue, 01 Sep 2009 08:20:28 +0100
cl-asdf (1.111-1) unstable; urgency=low
* New upstream release.
* Updated standard version without real changes
* Corrected Vcs-Bzr field
* Move to using dh-lisp
* Fixed Vcs-Git field
* Changed to group maintanance
* recreated upstream changelog with git2cl
* Changed directory, so we depend on a newer clc
-- Peter Van Eynde Sat, 09 Feb 2008 10:07:21 +0100
cl-asdf (1.109-2) unstable; urgency=low
* stop trying to dump the package, use the package name instead.
(Closes: #436129)
-- Peter Van Eynde Thu, 27 Sep 2007 05:42:20 +0200
cl-asdf (1.109-1) unstable; urgency=low
* New upstream. Major changes:
+ main change is the addition of system-relative-pathname function. This takes a
system name and a partial pathname and combines them to return a new pathname
_relative_ to the system. This is exported and lightly documented.
+ this patch also updates preference-file-for-system/operation in an effort
to prevent it from being confused by *default-pathname-defaults* that include
a specific name and type.
+ Removes inline component methods more carefully (and, I believe, correctly!). Helps keep LispWorks happy.
+ Reworked asdf tests to make them more robust and perhaps more flexible too.
* Now use texlive to build.
-- Peter Van Eynde Sun, 16 Sep 2007 14:45:57 +0200
cl-asdf (1.107-1) unstable; urgency=low
* New upstream release, adding the system-relative-pathname
function.
-- Peter Van Eynde Sun, 08 Apr 2007 23:05:18 +0200
cl-asdf (1.106-1) experimental; urgency=low
* New upstream. Major changes:
+ Minor patch in class-for-type that evaluates only *package* at read
time rather than (package-name *package*); this keeps case sensitive Lisps
happy all the time and keeps case insensitive lisps happily insensitive.
+ A patch from Richard Kreuter that allows pathname defaulting to work
better with *load-truename* and *default-pathname-defaults*; this makes it
easier to work with defsystems in the REPL.
-- Peter Van Eynde Wed, 14 Mar 2007 09:18:25 +0100
cl-asdf (1.104-1) experimental; urgency=low
* Added XS-X-Vcs-Darcs header
* modified S-X-Vcs-Darcs to XS-Vcs-Darcs field
* New upstream. Major changes:
+ add a better docstring for component-depends-on (via #lisp and Robert
Goldman)
+ ASDF now sends output to *standard-output* (thanks to Richard M.
Kreuter).
+ Slightly better SBCL_HOME treatement for SBCL.
* upload to experimental during the freeze
-- Peter Van Eynde Tue, 6 Feb 2007 08:21:06 +0100
cl-asdf (1.101-1) unstable; urgency=low
* New upstream version.
-- Peter Van Eynde Wed, 20 Sep 2006 07:08:57 +0200
cl-asdf (1.99-3) unstable; urgency=low
* Added tetex-bin to Build-Depends-Indep (Closes: #379532)
-- Peter Van Eynde Mon, 24 Jul 2006 19:34:49 +0200
cl-asdf (1.99-2) unstable; urgency=low
* Move asdf.info files from sbcl to this package.
* move texinfo to BuildDependsIndep
* we build something build-indep
-- Peter Van Eynde Fri, 30 Jun 2006 23:18:40 +0200
icl-asdf (1.99-1) unstable; urgency=low
* New upstream.
-- Peter Van Eynde Mon, 19 Jun 2006 05:28:12 +0200
cil-asdf (1.97-1) unstable; urgency=low
* New upstream release
* Moved debhelper to build-depeneds
* increased standards-version without real changes.
-- Peter Van Eynde Sat, 20 May 2006 19:28:58 +0200
cl-asdf (1.89-1) unstable; urgency=low
* Noticed that I actually increased the version with the CVS commit
* Updated the standards version
* Remove the prepare build stuff, build through darcs
* Improve duplicate names test: use equal instead of equalp.
From a comment from Faré.
* Remove CVS cruft
* Separate CVS version of asdf.lisp from version of package. The tag
is not the version of the package
-- Peter Van Eynde Thu, 22 Sep 2005 12:52:31 +0200
cl-asdf (1.86-5) unstable; urgency=low
* Fixed duplicate components patch to better handle reloading
defsystem files. Now works again with McClim. Closes: #310640
* Corrected dependencies.
* Added postinst rebuild of all clc-enabled lisps so the new version
actually gets loaded.
-- Peter Van Eynde Wed, 25 May 2005 08:22:17 +0200
cl-asdf (1.86-4) unstable; urgency=low
* My release script stripped the patch. So this should really contain the
patch. Damn.
-- Peter Van Eynde Tue, 10 May 2005 14:17:51 +0200
cl-asdf (1.86-3) unstable; urgency=low
* Now checks if components names are unique Closes: #304972, #304970
* Fix dependency on common-lisp-controller Closes: #308385
-- Peter Van Eynde Tue, 10 May 2005 07:50:25 +0200
cl-asdf (1.86-2) unstable; urgency=low
* New maintainer. (Closes: #297349: O: cl-asdf -- Another System
Definition Facility)
* Adopted by Peter Van Eynde
-- Peter Van Eynde Tue, 1 Mar 2005 10:11:55 +0100
cl-asdf (1.86-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Wed, 4 Aug 2004 21:19:16 -0600
cl-asdf (1.84-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Wed, 12 May 2004 12:43:58 -0600
cl-asdf (1.81-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Tue, 30 Dec 2003 12:12:38 -0700
cl-asdf (1.80-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Fri, 5 Dec 2003 14:55:43 -0700
cl-asdf (1.79-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Tue, 11 Nov 2003 16:12:07 -0700
cl-asdf (1.78-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Thu, 9 Oct 2003 16:46:38 -0600
cl-asdf (1.77.2-1) unstable; urgency=low
* Don't export asdf:wild-module as can cause a full warning when
reloading asdf
-- Kevin M. Rosenberg Mon, 11 Aug 2003 21:55:16 -0600
cl-asdf (1.77.1-1) unstable; urgency=low
* cclan.lisp: conditionalize for sbcl (closes: 201822)
-- Kevin M. Rosenberg Thu, 17 Jul 2003 23:30:57 -0600
cl-asdf (1.77-1) unstable; urgency=low
* New upstream
* Add automated [cvs2cl] ChangeLog
-- Kevin M. Rosenberg Thu, 17 Jul 2003 10:27:27 -0600
cl-asdf (1.76) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Thu, 10 Jul 2003 16:42:48 -0600
cl-asdf (1.75) unstable; urgency=low
* New upstream
* Use compat rather than DH_COMPAT
-- Kevin M. Rosenberg Thu, 5 Jun 2003 00:15:11 -0600
cl-asdf (1.73b) unstable; urgency=low
* Update README
* export two variables
-- Kevin M. Rosenberg Wed, 28 May 2003 11:19:40 -0600
cl-asdf (1.73) unstable; urgency=low
* Update README to mention asdf::*compile-file-warnings-behaviour*
(closes:194957)
-- Kevin M. Rosenberg Tue, 27 May 2003 16:00:36 -0600
cl-asdf (1.72) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Tue, 20 May 2003 14:07:10 -0600
cl-asdf (1.71) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Tue, 13 May 2003 09:33:51 -0600
cl-asdf (1.70) unstable; urgency=low
* Add another check in check-component-values.
* Signal a generalized instance of SYSTEM-DEFINITION-ERROR
from check-component-values
-- Kevin M. Rosenberg Tue, 6 May 2003 09:32:16 -0600
cl-asdf (1.69) unstable; urgency=low
* Add check-component-values function with partial checking of components
-- Kevin M. Rosenberg Tue, 6 May 2003 08:26:11 -0600
cl-asdf (1.68) unstable; urgency=low
* New upstream with 'asdf:test-op
-- Kevin M. Rosenberg Wed, 19 Mar 2003 10:16:01 -0700
cl-asdf (1.66) unstable; urgency=low
* New upstream version, added changes to dependent system
compilations with :force option.
-- Kevin M. Rosenberg Mon, 17 Mar 2003 12:50:00 -0700
cl-asdf (1.62) unstable; urgency=low
* New upstream, fixes a sbcl-specific directory name
-- Kevin M. Rosenberg Fri, 7 Mar 2003 09:23:11 -0700
cl-asdf (1.61-1) unstable; urgency=low
* New upstream, fixes 'load-source-op
-- Kevin M. Rosenberg Tue, 4 Mar 2003 09:48:40 -0700
cl-asdf (1.60-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Mon, 3 Mar 2003 12:40:27 -0700
cl-asdf (1.59-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Fri, 14 Feb 2003 09:24:59 -0700
cl-asdf (1.58-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Sun, 9 Feb 2003 11:55:03 -0700
cl-asdf (1.57-1) unstable; urgency=low
* New upstream
-- Kevin M. Rosenberg Tue, 4 Feb 2003 10:23:03 -0700
cl-asdf (1.55-1) unstable; urgency=low
* New upstream.version (closes: 172074)
-- Kevin M. Rosenberg Mon, 9 Dec 2002 10:23:21 -0700
cl-asdf (1.54-1) unstable; urgency=low
* New upstream.
-- Kevin M. Rosenberg Fri, 8 Nov 2002 07:30:41 -0700
cl-asdf (1.49-1) unstable; urgency=low
* Remove clc-reregister-all-impl from postinst
-- Kevin M. Rosenberg Sat, 5 Oct 2002 09:38:18 -0600
cl-asdf (1.49) unstable; urgency=low
* New upstream release, fixes run-shell-command for allegro. Code
refactoring for run-shell-code.
* Support new CLC reregister command
-- Kevin M. Rosenberg Wed, 25 Sep 2002 23:57:23 -0600
cl-asdf (1.47) unstable; urgency=low
* Return numeric exit status for openmcl's run-shell-command
-- Kevin M. Rosenberg Fri, 20 Sep 2002 10:22:36 -0600
cl-asdf (1.46) unstable; urgency=low
* New upstream version, adds run-shell-command for openmcl
-- Kevin M. Rosenberg Fri, 20 Sep 2002 10:11:48 -0600
cl-asdf (1.45) unstable; urgency=low
* Changes to improve clisp support
-- Kevin M. Rosenberg Fri, 20 Sep 2002 07:12:21 -0600
cl-asdf (1.44.1-1) unstable; urgency=low
* Make cclan.asd a symlink, remove :pathname keyword
-- Kevin M. Rosenberg Wed, 18 Sep 2002 00:19:26 -0600
cl-asdf (1.44-1) unstable; urgency=low
* New upstream version
-- Kevin M. Rosenberg Tue, 17 Sep 2002 12:24:27 -0600
cl-asdf (1.43-1) unstable; urgency=low
* New upstream version
-- Kevin M. Rosenberg Tue, 17 Sep 2002 10:34:57 -0600
cl-asdf (1.42-2) unstable; urgency=low
* Add reregister-common-lisp-implementations call when installing cl-asdf.
-- Kevin M. Rosenberg Mon, 16 Sep 2002 08:31:13 -0600
cl-asdf (1.42-1) unstable; urgency=low
* Remove Depends on lisp-compiler for cl-asdf (fixes problem with
circular dependencies)
-- Kevin M. Rosenberg Sat, 14 Sep 2002 11:59:58 -0600
cl-asdf (1.42) unstable; urgency=low
* New upstream.
-- Kevin M. Rosenberg Fri, 13 Sep 2002 08:40:58 -0600
cl-asdf (1.41) unstable; urgency=low
* Same release as 1.40, but with proper version number.
-- Kevin M. Rosenberg Fri, 13 Sep 2002 08:38:30 -0600
cl-asdf (1.40) unstable; urgency=low
* New upstream version.
-- Kevin M. Rosenberg Fri, 13 Sep 2002 07:31:27 -0600
cl-asdf (1.39) unstable; urgency=low
* New upstream version.
-- Kevin M. Rosenberg Wed, 11 Sep 2002 19:21:32 -0600
cl-asdf (1.38) unstable; urgency=low
* New upstream version
* Re-add register and unregister clc-source for cclan
-- Kevin M. Rosenberg Wed, 11 Sep 2002 13:39:51 -0600
cl-asdf (1.35-1) unstable; urgency=low
* Comment call to register and unregister clc-source until new
version of clc is released. (closes: 158697)
-- Kevin M. Rosenberg Wed, 28 Aug 2002 18:58:59 -0600
cl-asdf (1.35) unstable; urgency=high
* New upstream version, fixes important bugs.
-- Kevin M. Rosenberg Wed, 28 Aug 2002 09:36:58 -0600
cl-asdf (1.34) unstable; urgency=low
* New upstream version.
-- Kevin M. Rosenberg Wed, 28 Aug 2002 07:18:57 -0600
cl-asdf (0.0+cvs.2002.08.26-1) unstable; urgency=low
* Add Common Lisp Controller registration functions for cl-cclan
-- Kevin M. Rosenberg Mon, 26 Aug 2002 04:21:32 -0600
cl-asdf (0.0+cvs.2002.08.26) unstable; urgency=low
* New upstream version
-- Kevin M. Rosenberg Mon, 26 Aug 2002 01:23:48 -0600
cl-asdf (0.0+cvs.2002.08.22) unstable; urgency=low
* Add new binary package: cl-cclan
-- Kevin M. Rosenberg Thu, 22 Aug 2002 12:43:21 -0600
cl-asdf (0.0+cvs.2002.08.18) unstable; urgency=low
* New upstream version
* Expand description in control file.
* Change version numbering scheme since upstream has native debian
directory
-- Kevin M. Rosenberg Sat, 17 Aug 2002 14:25:33 -0600
cl-asdf (0.0+cvs.2002.08.15-1) unstable; urgency=low
* Initial Release (closes: 157009)
-- Kevin M. Rosenberg Fri, 16 Aug 2002 23:14:49 -0600
asdf-3.3.4/doc/Makefile 0000664 0000000 0000000 00000002360 13621551153 0014646 0 ustar 00root root 0000000 0000000 #user=frideau
ifeq (${user},)
userat :=
else
userat := ${user}@
endif
website:=${userat}common-lisp.net:/project/asdf/public_html/
output = asdf.html asdf asdf.pdf asdf.info
webfiles = index.html .htaccess style.css cclan.png lisp-logo120x80.png favicon.ico ${output}
intermediate = asdf.cps asdf.log asdf.vr asdf.aux asdf.fn asdf.toc asdf.vrs \
asdf.cp asdf.fns asdf.ky asdf.pg asdf.tp asdf.tps
all: asdf.html asdf.info asdf.pdf manual-html
manual-html: asdf.texinfo
makeinfo --html asdf.texinfo \
2>&1 > manual-html.log || { echo "failed. See log in manual-html.log" ; exit 1 ;}
asdf.html: asdf.texinfo
makeinfo --html --no-split --no-headers -o asdf.html asdf.texinfo \
2>&1 > asdf.html.log || { echo "failed. See log in asdf.html.log" ; exit 1 ;}
asdf.info: asdf.texinfo
makeinfo asdf.texinfo
asdf.pdf: asdf.texinfo
texi2pdf asdf.texinfo \
2>&1 > asdf.pdf.log || { echo "failed. See log in asdf.pdf.log" ; exit 1 ;}
website: all
rsync -lt --no-g ${webfiles} ${website}
rsync --recursive --no-g --delete asdf ${website}
rsync -lt --no-g Changelog ${website}/changelog
.PHONY: clean intermediate-clean manual-html
intermediate-clean:
rm -f ${intermediate}
clean: intermediate-clean
rm -f asdf.html asdf.pdf asdf.info
rm -rf asdf/ asdf.t2d/
asdf-3.3.4/doc/asdf.texinfo 0000664 0000000 0000000 00001036521 13621551153 0015530 0 ustar 00root root 0000000 0000000 \input texinfo @c -*- mode: texinfo; coding: utf-8 -*-
@c %**start of header
@documentencoding UTF-8
@setfilename asdf.info
@settitle ASDF Manual
@c %**end of header
@c We use @&key, etc to escape & from TeX in lambda lists --
@c so we need to define them for info as well.
@macro AallowOtherKeys
&allow-other-keys
@end macro
@macro Aoptional
&optional
@end macro
@macro Arest
&rest
@end macro
@macro Akey
&key
@end macro
@macro Abody
&body
@end macro
@c for install-info
@dircategory Software development
@direntry
* asdf: (asdf). Another System Definition Facility (for Common Lisp)
@end direntry
@copying
This manual describes ASDF, a system definition facility
for Common Lisp programs and libraries.
You can find the latest version of this manual at
@url{https://common-lisp.net/project/asdf/asdf.html}.
ASDF Copyright @copyright{} 2001-2019 Daniel Barlow and contributors.
This manual Copyright @copyright{} 2001-2019 Daniel Barlow and contributors.
This manual revised @copyright{} 2009-2019 Robert P. Goldman and Francois-Rene Rideau.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
``Software''), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
@end copying
@titlepage
@title ASDF: Another System Definition Facility
@subtitle Manual for Version 3.3.4
@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
@c Output the table of contents at the beginning.
@contents
@c -------------------
@ifnottex
@node Top, Introduction, (dir), (dir)
@top ASDF: Another System Definition Facility
@ifnottex
Manual for Version 3.3.4
@end ifnottex
@insertcopying
@menu
* Introduction::
* Quick start summary::
* Loading ASDF::
* Configuring ASDF::
* Using ASDF::
* Defining systems with defsystem::
* The object model of ASDF::
* Controlling where ASDF searches for systems::
* Controlling where ASDF saves compiled files::
* Error handling::
* Miscellaneous additional functionality::
* Getting the latest version::
* FAQ::
* Ongoing Work::
* Bibliography::
* Concept Index::
* Function and Macro Index::
* Variable Index:: @c @detailmenu
* Class and Type Index:: @c
@detailmenu
--- The Detailed Node Listing ---
Loading ASDF
* Loading a pre-installed ASDF::
* Checking whether ASDF is loaded::
* Upgrading ASDF::
* Replacing your implementation's ASDF::
* Loading ASDF from source::
Configuring ASDF
* Configuring ASDF to find your systems::
* Configuring ASDF to find your systems --- old style::
* Configuring where ASDF stores object files::
* Resetting the ASDF configuration::
Using ASDF
* Loading a system::
* Convenience Functions::
* Moving on::
Defining systems with defsystem
* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
* The package-inferred-system extension::
The Object model of ASDF
* Operations::
* Components::
* Dependencies::
* Functions::
Operations
* Predefined operations of ASDF::
* Creating new operations::
Components
* Common attributes of components::
* Pre-defined subclasses of component::
* Creating new component types::
properties
* Pre-defined subclasses of component::
* Creating new component types::
Controlling where ASDF searches for systems
* Configurations::
* Truenames and other dangers::
* XDG base directory::
* Backward Compatibility::
* Configuration DSL::
* Configuration Directories::
* Shell-friendly syntax for configuration::
* Search Algorithm::
* Caching Results::
* Configuration API::
* Introspection::
* Status::
* Rejected ideas::
* TODO::
* Credits for the source-registry::
Configuration Directories
* The here directive::
Introspection
* *source-registry-parameter* variable::
* Information about system dependencies::
Controlling where ASDF saves compiled files
* Output Configurations::
* Output Backward Compatibility::
* Output Configuration DSL::
* Output Configuration Directories::
* Output Shell-friendly syntax for configuration::
* Semantics of Output Translations::
* Output Caching Results::
* Output location API::
* Credits for output translations::
Miscellaneous additional functionality
* Controlling file compilation::
* Controlling source file character encoding::
* Miscellaneous Functions::
* Some Utility Functions::
FAQ
* Where do I report a bug?::
* Mailing list::
* What has changed between ASDF 1 ASDF 2 and ASDF 3?::
* Issues with installing the proper version of ASDF::
* Issues with configuring ASDF::
* Issues with using and extending ASDF to define systems::
* ASDF development FAQs::
``What has changed between ASDF 1, ASDF 2, and ASDF 3?''
* What are ASDF 1 2 3?::
* How do I detect the ASDF version?::
* ASDF can portably name files in subdirectories::
* Output translations::
* Source Registry Configuration::
* Usual operations are made easier to the user::
* Many bugs have been fixed::
* ASDF itself is versioned::
* ASDF can be upgraded::
* Decoupled release cycle::
* Pitfalls of the transition to ASDF 2::
* Pitfalls of the upgrade to ASDF 3::
* What happened to the bundle operations::
Issues with installing the proper version of ASDF
* My Common Lisp implementation comes with an outdated version of ASDF. What to do?::
* I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?::
* After upgrading ASDF, ASDF (and Quicklisp) can't find my systems: After upgrading ASDF.
Issues with configuring ASDF
* How can I customize where fasl files are stored?::
* How can I wholly disable the compiler output cache?::
* How can I debug problems finding ASDF systems::
Issues with using and extending ASDF to define systems
* How can I cater for unit-testing in my system?::
* How can I cater for documentation generation in my system?::
* How can I maintain non-Lisp (e.g. C) source files?::
* I want to put my module's files at the top level. How do I do this?::
* How do I create a system definition where all the source files have a .cl extension?::
* How do I mark a source file to be loaded only and not compiled?::
* How do I work with readtables?::
* How can I capture ASDF's output?::
* LOAD-PATHNAME has a weird value::
ASDF development FAQs
* How do I run the tests interactively in a REPL?::
@end detailmenu
@end menu
@end ifnottex
@c -------------------
@node Introduction, Quick start summary, Top, Top
@comment node-name, next, previous, up
@chapter Introduction
@cindex ASDF-related features
@vindex *features*
@cindex Testing for ASDF
@cindex ASDF versions
@cindex :asdf
@cindex :asdf2
@cindex :asdf3
ASDF, or Another System Definition Facility, is a @emph{build system}:
a tool for specifying how systems of Common Lisp software
are made up of components (sub-systems and files),
and how to operate on these components in the right order
so that they can be compiled, loaded, tested, etc.
If you are new to ASDF, @pxref{Quick start summary,,the quick start
guide}.
ASDF presents three faces:
one for users of Common Lisp software who want to reuse other people's code,
one for writers of Common Lisp software who want to specify how to build their systems,
and one for implementers of Common Lisp extensions who want to extend
the build system.
For more specifics,
@pxref{Using ASDF},
to learn how to use ASDF to load a system.
@xref{Defining systems with defsystem},
to learn how to define a system of your own.
@xref{The object model of ASDF}, for a description of
the ASDF internals and how to extend ASDF.
Note that
ASDF is @emph{not} a tool for library and system @emph{installation};
it plays a role like @code{make} or @code{ant}, not like a package manager.
In particular, ASDF should not to be confused with Quicklisp or ASDF-Install,
that attempt to find and download ASDF systems for you.
Despite what the name might suggest,
ASDF-Install was never a part of ASDF; it was always a separate piece of software.
ASDF-Install has also been unmaintained and obsolete for a very long time.
We recommend you use Quicklisp
(@uref{http://www.quicklisp.org/}) instead,
a Common Lisp package manager which works well and is being actively maintained.
If you want to download software from version control instead of tarballs,
so you may more easily modify it,
we recommend clbuild (@uref{http://common-lisp.net/project/clbuild/}).
As for where on your filesystem to install Common Lisp software,
we recommend subdirectories of @file{~/common-lisp/}:
starting with ASDF 3.1.2 (2014), this hierarchy is included
in the default source-registry configuration.
Finally, note that this manual is incomplete.
All the bases are covered,
but many advanced topics are only barely alluded to,
and there is not much in terms of examples.
The source code remains the ultimate source of information,
free software systems in Quicklisp remain the best source of examples,
and the mailing-list the best place to ask for help.
@node Quick start summary, Loading ASDF, Introduction, Top
@chapter Quick start summary
@itemize
@item To load an ASDF system:
@itemize
@item
Load ASDF itself into your Lisp image, using
@code{(require "asdf")}.
Check that you have a recent version using @code{(asdf:asdf-version)}.
For more details, or if any of the above fails, @pxref{Loading ASDF}.
@item
Make sure software is installed where ASDF can find it.
The simplest way is to put all your Lisp code in subdirectories of
@file{~/common-lisp/} (starting with ASDF 3.1.2),
or @file{~/.local/share/common-lisp/source/}
(for ASDF 2 and later, or if you want to keep source in a hidden directory).
For more details, @pxref{Configuring ASDF to find your systems}.
@item
Load your system with @code{(asdf:load-system "@var{my-system}")}.
@xref{Using ASDF}.
@end itemize
@item To make your own ASDF system:
@itemize
@item
As above, load and configure ASDF.
@item
Make a new directory for your system, @code{@var{my-system}/},
again in a location where ASDF can find it.
All else being equal, the easiest location is probably
@file{~/common-lisp/my-system/}.
@xref{Configuring ASDF to find your systems}.
@item
Create an ASDF system definition listing the dependencies of
your system, its components, and their interdependencies,
and put it in @file{@var{my-system}.asd}.
This file must have the same name as your system, all lowercase.
@xref{Defining systems with defsystem}.
@item
Use @code{(asdf:load-system "@var{my-system}")}
to make sure it's all working properly. @xref{Using ASDF}.
@end itemize
@end itemize
@c FIXME: (1) add a sample project that the user can cut and paste to
@c get started. (2) discuss the option of starting with Quicklisp.
@node Loading ASDF, Configuring ASDF, Quick start summary, Top
@comment node-name, next, previous, up
@chapter Loading ASDF
@menu
* Loading a pre-installed ASDF::
* Checking whether ASDF is loaded::
* Upgrading ASDF::
* Replacing your implementation's ASDF::
* Loading ASDF from source::
@end menu
@node Loading a pre-installed ASDF, Checking whether ASDF is loaded, Loading ASDF, Loading ASDF
@section Loading a pre-installed ASDF
The recommended way to load ASDF is via:
@lisp
(require "asdf")
@end lisp
All actively maintained Lisp implementations now include a copy of ASDF 3
that you can load this way using Common Lisp's @code{require} function.@footnote{
NB: all implementations except GNU CLISP also accept
@code{(require "ASDF")}, @code{(require 'asdf)} and @code{(require :asdf)}.
For portability's sake, you should use @code{(require "asdf")}.
}
If the implementation you are using doesn't provide a recent ASDF 3,
we recommend you upgrade it.
If for some reason you would rather not upgrade it,
we recommend you replace your implementation's ASDF.
@xref{Replacing your implementation's ASDF}.
If all else fails, see @pxref{Loading ASDF from source} below.
If you use an actively maintained implementation that fails to provide
an up-to-date enough stable release of ASDF,
you may also send a bug report to your Lisp vendor and complain about it
--- or you may fix the issue yourself if it's free software.
As of the writing of this manual,
the following implementations provide ASDF 3 this way:
ABCL, Allegro CL, CLASP, Clozure CL, CMUCL, ECL, GNU CLISP, LispWorks, MKCL, SBCL.
The following implementations only provide ASDF 2:
MOCL, XCL.
The following implementations don't provide ASDF:
Corman CL, GCL, Genera, MCL, SCL.
The latter implementations are not actively maintained (except maybe GCL);
if some of them are ever released again, they probably will include ASDF 3.
For maximum convenience you might want to have ASDF loaded
whenever you start your Lisp implementation,
for example by loading it from the startup script or dumping a custom core
--- check your Lisp implementation's manual for details.
SLIME notably sports a @code{slime-asdf} contrib that makes life easier with ASDF.
@node Checking whether ASDF is loaded, Upgrading ASDF, Loading a pre-installed ASDF, Loading ASDF
@section Checking whether ASDF is loaded
To check that ASDF is properly loaded, you can run this form:
@lisp
(asdf:asdf-version)
@end lisp
If it returns a string,
that is the version of ASDF that is currently installed.
If that version is suitably recent (say, 3.1.2 or later),
then you can skip directly to next chapter: @xref{Configuring ASDF}.
If it raises an error,
then either ASDF is not loaded, or
you are using a very old version of ASDF,
and need to install ASDF 3.
For more precision in detecting versions old and new,
@pxref{How do I detect the ASDF version?}.
If you are experiencing problems with ASDF,
please try upgrading to the latest released version,
using the method below,
before you contact us and raise an issue.
@node Upgrading ASDF, Replacing your implementation's ASDF, Checking whether ASDF is loaded, Loading ASDF
@section Upgrading ASDF
@c FIXME: tighten this up a bit -- there's a lot of stuff here that
@c doesn't matter to almost anyone. Move discussion of updating antique
@c versions of ASDF down, or encapsulate it.
If your implementation already provides ASDF 3 or later (and it should),
but you want a more recent ASDF version than your implementation provides, then
you just need to ensure the more recent ASDF is installed in a configured path,
like any other system.
We recommend you download an official tarball or checkout a release from git into
@file{~/common-lisp/asdf/}.
(@pxref{Configuring ASDF to find your systems}).
Once the source code for ASDF is installed,
you don't need any extra step to load it beyond the usual @code{(require "asdf")}:
ASDF 3 will automatically look whether an updated version of itself is available
amongst the regularly configured systems, before it compiles anything else.
If your implementation fails to provide ASDF 3 or later,
@pxref{Replacing your implementation's ASDF}.
@node Replacing your implementation's ASDF, Loading ASDF from source, Upgrading ASDF, Loading ASDF
@section Replacing your implementation's ASDF
All maintained implementations now provide ASDF 3 in their latest release.
If yours doesn't, we recommend you upgrade it.
Now, if you insist on using an old implementation
that didn't provide ASDF or provided an old version,
we recommend installing a recent ASDF, as explained below,
into your implementation's installation directory.
Thus your modified implementation will now provide ASDF 3.
This requires proper write permissions and
may necessitate execution as a system administrator.
The ASDF source repository contains a tool to
help you upgrade your implementation's ASDF.
You can invoke it from the shell command-line as
@code{tools/asdf-tools install-asdf lispworks}
(where you can replace @code{lispworks} by the name of the relevant implementation),
or you can @code{(load "tools/install-asdf.lisp")} from your Lisp REPL.
This script works on
Allegro CL, Clozure CL, CMU CL, ECL, GCL, GNU CLISP, LispWorks, MKCL, SBCL, SCL, XCL.
It doesn't work on ABCL, Corman CL, Genera, MCL, MOCL.
Happily, ABCL is usually pretty up to date and shouldn't need that script.
GCL requires a very recent version, and hasn't been tested much.
Corman CL, Genera, MCL are obsolete anyway.
MOCL is incomplete.
@node Loading ASDF from source, , Replacing your implementation's ASDF, Loading ASDF
@section Loading ASDF from source
If you write build scripts that must remain portable to old machines with old implementations
that you cannot ensure have been upgraded or modified to provide a recent ASDF,
you may have to install the file @file{asdf.lisp}
somewhere and load it with:
@lisp
(load "/path/to/your/installed/asdf.lisp")
@end lisp
The single file @file{asdf.lisp} is all you normally need to use ASDF.
You can extract this file from latest release tarball on the
@url{https://common-lisp.net/project/asdf/,ASDF website}.
If you are daring and willing to report bugs, you can get
the latest and greatest version of ASDF from its git repository.
@xref{Getting the latest version}.
For scripts that try to use ASDF simply via @code{require} at first, and
make heroic attempts to load it the hard way if at first they don't succeed,
see @file{tools/load-asdf.lisp} distributed with the ASDF source repository,
or the code of @url{https://cliki.net/cl-launch,@code{cl-launch}}.
@node Configuring ASDF, Using ASDF, Loading ASDF, Top
@comment node-name, next, previous, up
@chapter Configuring ASDF
For standard use cases, ASDF should work pretty much out of the box.
We recommend you skim the sections on configuring ASDF to find your systems
and choose the method of installing Lisp software that works best for you.
Then skip directly to @xref{Using ASDF}. That will probably be enough.
You are unlikely to have to worry about the way ASDF stores object files,
and resetting the ASDF configuration is usually only needed in corner cases.
@menu
* Configuring ASDF to find your systems::
* Configuring ASDF to find your systems --- old style::
* Configuring where ASDF stores object files::
* Resetting the ASDF configuration::
@end menu
@node Configuring ASDF to find your systems, Configuring ASDF to find your systems --- old style, Configuring ASDF, Configuring ASDF
@section Configuring ASDF to find your systems
In order to compile and load your systems, ASDF must be configured to find
the @file{.asd} files that contain system definitions.
There are a number of different techniques for setting yourself up with
ASDF, starting from easiest to the most complex:
@itemize @bullet
@item
Put all of your systems in one of the standard locations,
subdirectories of
@itemize
@item
@file{~/common-lisp/} or
@item
@file{~/.local/share/common-lisp/source/}.
@end itemize
If you install software there, you don't need further
configuration.@footnote{
@file{~/common-lisp/} is only included in
the default configuration
starting with ASDF 3.1.2 or later.
If your implementation provides an earlier variant of ASDF,
you may need to explicitly configure it to use this path,
as further explained.
}
You can then skip to the next section. @xref{Loading a system}.
@item
If you're using some tool to install software (e.g. Quicklisp),
the authors of that tool should already have configured ASDF.
@item
If you have more specific desires about how to lay out your software on
disk, the preferred way to configure where ASDF finds your systems is
the @code{source-registry} facility,
fully described in its own chapter of this manual.
@xref{Controlling where ASDF searches for systems}.
Here is a quick recipe for getting started.
First create the directory
@file{~/.config/common-lisp/source-registry.conf.d/}@footnote{
For Windows users, and starting with ASDF 3.1.5, start from your
@file{%LOCALAPPDATA%}, which is usually @file{~/AppData/Local/}
(but you can ask in a @code{CMD.EXE} terminal
@code{echo %LOCALAPPDATA%} to make sure)
and underneath create a subpath
@file{config/common-lisp/source-registry.conf.d/}.
};
there create a file with any name of your choice
but with the type @file{conf}@footnote{
By requiring the @file{.conf}
extension, and ignoring other files, ASDF allows you to have disabled files,
editor backups, etc. in the same directory with your active
configuration files.
ASDF will also ignore files whose names start with a @file{.} character.
It is customary to start the filename with two digits, to control the
sorting of the @code{conf} files in the source registry directory, and
thus the order in which the directories will be scanned.
},
for instance @file{50-luser-lisp.conf};
in this file, add the following line
to tell ASDF to recursively scan all the subdirectories under @file{/home/luser/lisp/}
for @file{.asd} files:
@kbd{(:tree "/home/luser/lisp/")}
That's enough. You may replace @file{/home/luser/lisp/} by wherever you want to install your source code.
You don't actually need to specify anything if you use the default @file{~/common-lisp/} as above
and your implementation provides ASDF 3.1.2 or later.
If your implementation provides an earlier variant of ASDF 3,
you might want to specify @kbd{(:tree (:home "common-lisp/"))} for bootstrap purposes,
then install a recent source tree of ASDF under @file{~/common-lisp/asdf/}.
If you prefer to use a ``link farm'', which is faster to use but costlier to manage than a recursive traversal,
say at @file{/home/luser/.asd-link-farm/}, then
you may instead (or additionally) create a file @file{42-asd-link-farm.conf}, containing the line:
@kbd{(:directory "/home/luser/.asd-link-farm/")}
ASDF will automatically read your configuration
the first time you try to find a system.
If necessary, you can reset the source-registry configuration with:
@lisp
(asdf:clear-source-registry)
@end lisp
@item
In earlier versions of ASDF, the system source registry was configured
using a global variable, @code{asdf:*central-registry*}.
For more details about this, see the following section,
@ref{Configuring ASDF to find your systems --- old style}.
Unless you need to understand this,
skip directly to @ref{Configuring where ASDF stores object files}.
@end itemize
Note that your Operating System distribution or your system administrator
may already have configured system-managed libraries for you.
@node Configuring ASDF to find your systems --- old style, Configuring where ASDF stores object files, Configuring ASDF to find your systems, Configuring ASDF
@section Configuring ASDF to find your systems --- old style
@c FIXME: this section should be moved elsewhere. The novice user
@c should not be burdened with it. [2014/02/27:rpg]
Novices may skip this section.
Please @emph{do not} use the central-registry if you are a novice,
and @emph{do not} instruct novices to use the central-registry.
@c ``Experts may read it then proceed to ...''
@c some better section explaining
@c *central-registry* vs source-registry vs *system-definition-search-functions*,
@c and .../asdf/tools/cl-source-registry-cache.lisp
The old way to configure ASDF to find your systems is by
@code{push}ing directory pathnames onto the variable
@code{asdf:*central-registry*}.
You @emph{must} configure this variable @emph{after} you load ASDF 3 or later,
yet @emph{before} the first time you try to use it.
This loading and configuring of ASDF must happen
as part of some initialization script:
typically, either a script you maintain that builds your project,
or your implementation's initialization script
(e.g. @file{~/.sbclrc} for SBCL).
Also, if you are using an ancient ASDF 2 or earlier to load ASDF 3 or later,
then after it loads the ancient ASDF, your script @emph{must} configure
the central-registry a first time to tell ASDF 1 or 2 where to find ASDF 3,
then load ASDF 3 with e.g. @code{(asdf:operate 'asdf:load-op "asdf")},
then configure the central-registry again, because
ASDF 3 will not preserve the central-registry from ASDF 2 when upgrading.
You should probably be using the source-registry instead, which will be preserved
(unless you manually called @code{asdf:initialize-source-registry} with an argument,
in which case you will have to do it again indeed).
However, if you are using an ancient ASDF 2 or earlier,
we @emph{strongly} recommend that you should instead upgrade your implementation,
or overwrite the ancient ASDF installation with a more recent one:
@xref{Replacing your implementation's ASDF}.
The @code{asdf:*central-registry*} is empty by default in ASDF 2 or ASDF 3,
but is still supported for compatibility with ASDF 1.
When used, it takes precedence over the above source-registry.@footnote{
It is possible to further customize
the system definition file search.
That's considered advanced use, and covered later:
search forward for
@code{*system-definition-search-functions*}.
@xref{Defining systems with defsystem}.}
For example, let's say you want ASDF to find the @file{.asd} file
@file{/home/me/src/foo/foo.asd}.
In your Lisp initialization file, you could have the following:
@lisp
(require "asdf")
(push "/home/me/src/foo/" asdf:*central-registry*)
@end lisp
Note the trailing slash: when searching for a system,
ASDF will evaluate each entry of the central registry
and coerce the result to a pathname.@footnote{
ASDF will indeed call @code{eval} on each entry.
It will skip entries that evaluate to @code{nil}.
Strings and pathname objects are self-evaluating,
in which case the @code{eval} step does nothing;
but you may push arbitrary s-expressions onto the central registry.
These s-expressions may be evaluated to compute context-dependent
entries, e.g. things that depend
on the value of shell variables or the identity of the user.
The variable @code{asdf:*central-registry*} is thus a list of
``system directory designators''.
A @dfn{system directory designator} is a form
which will be evaluated whenever a system is to be found,
and must evaluate to a directory to look in (or @code{nil}).
By ``directory'', we mean
``designator for a pathname with a non-empty DIRECTORY component''.
}
The trailing directory name separator
is necessary to tell Lisp that you're discussing a directory
rather than a file. If you leave it out, ASDF is likely to look in
@code{/home/me/src/} instead of @code{/home/me/src/foo/} as you
intended, and fail to find your system definition.
Modern versions of ASDF will issue an error and offer you to
remove such entries from the central-registry.
Typically there are a lot of @file{.asd} files, and
a common idiom was to put
@emph{symbolic links} to all of one's @file{.asd} files
in a common directory
and push @emph{that} directory (the ``link farm'')
onto
@code{asdf:*central-registry*},
instead of pushing each individual system directory.
ASDF knows to follow @emph{symlinks}
to the actual location of the systems.@footnote{
On Windows, you can use Windows shortcuts instead of POSIX symlinks.
if you try aliases under MacOS, we are curious to hear about your experience.
}
For example, if @code{#p"/home/me/cl/systems/"}
is an element of @code{*central-registry*}, you could set up the
system @var{foo} as follows:
@example
$ cd /home/me/cl/systems/
$ ln -s ~/src/foo/foo.asd .
@end example
This old style for configuring ASDF is not recommended for new users,
but it is supported for old users, and for users who want a simple way to
programmatically control what directories are added to the ASDF search path.
@node Configuring where ASDF stores object files, Resetting the ASDF configuration, Configuring ASDF to find your systems --- old style, Configuring ASDF
@section Configuring where ASDF stores object files
@findex clear-output-translations
ASDF lets you configure where object files will be stored.
Sensible defaults are provided and
you shouldn't normally have to worry about it.
This allows the same source code repository to be shared
between several versions of several Common Lisp implementations,
between several users using different compilation options,
with users who lack write privileges on shared source directories, etc.
This also keeps source directories from being cluttered
with object/fasl files.
Starting with ASDF 2, the @code{asdf-output-translations} facility
was added to ASDF itself. This facility controls where object files will be stored.
This facility is fully described in a chapter of this manual,
@ref{Controlling where ASDF saves compiled files}.
@c FIXME: possibly this should be moved elsewhere. It's redundant here,
@c and makes this section of the manual too long and daunting for the
@c new user. [2014/02/27:rpg]
@c The simplest way to add a translation to your search path,
@c say from @file{/foo/bar/baz/quux/}
@c to @file{/where/i/want/my/fasls/}
@c is to create the directory
@c @file{~/.config/common-lisp/asdf-output-translations.conf.d/}
@c and there create a file with any name of your choice and the type @file{conf},
@c for instance @file{42-bazquux.conf}
@c containing the line:
@c @kbd{("/foo/bar/baz/quux/" "/where/i/want/my/fasls/")}
@c To disable output translations for source under a given directory,
@c say @file{/toto/tata/}
@c you can create a file @file{40-disable-toto.conf}
@c with the line:
@c @kbd{("/toto/tata/")}
@c To wholly disable output translations for all directories,
@c you can create a file @file{00-disable.conf}
@c with the line:
@c @kbd{(t t)}
@c Note that your Operating System distribution or your system administrator
@c may already have configured translations for you.
@c In absence of any configuration, the default is to redirect everything
@c under an implementation-dependent subdirectory of @file{~/.cache/common-lisp/}.
@c @xref{Controlling where ASDF searches for systems}, for full details.
@c The required @file{.conf} extension allows you to have disabled files
@c or editor backups (ending in @file{~}), and works portably
@c (for instance, it is a pain to allow both empty and non-empty extension on CLISP).
@c Excluded are files the name of which start with a @file{.} character.
@c It is customary to start the filename with two digits
@c that specify the order in which the directories will be scanned.
@c ASDF will automatically read your configuration
@c the first time you try to find a system.
@c You can reset the source-registry configuration with:
@c @lisp
@c (asdf:clear-output-translations)
@c @end lisp
@c And you probably should do so before you dump your Lisp image,
@c if the configuration may change
@c between the machine where you save it at the time you save it
@c and the machine you resume it at the time you resume it.
@c (Once again, you should use @code{(asdf:clear-configuration)}
@c before you dump your Lisp image, which includes the above.)
Note that before ASDF 2,
other ASDF add-ons offered the same functionality,
each in subtly different and incompatible ways:
ASDF-Binary-Locations, cl-launch, common-lisp-controller.
ASDF-Binary-Locations is now not needed anymore and should not be used.
cl-launch 3.000 and common-lisp-controller 7.2 have been updated
to delegate object file placement to ASDF.
@node Resetting the ASDF configuration, , Configuring where ASDF stores object files, Configuring ASDF
@section Resetting the ASDF configuration
@c FIXME: this should probably be moved out of the "quickstart" part of
@c the manual. [2014/02/27:rpg]
When you dump and restore an image, or when you tweak your configuration,
you may want to reset the ASDF configuration.
For that you may use the following function:
@defun clear-configuration
Undoes any ASDF configuration
regarding source-registry or output-translations.
@end defun
@vindex *image-dump-hook*
This function is pushed onto the @code{uiop:*image-dump-hook*} by default,
which means that if you save an image using @code{uiop:dump-image},
or via @code{asdf:image-op} and @code{asdf:program-op},
it will be automatically called to clear your configuration.
If for some reason you prefer to call your implementation's underlying functionality,
be sure to call @code{clear-configuration} manually,
or push it into your implementation's equivalent of @code{uiop:*image-dump-hook*},
e.g. @code{sb-ext:*save-hooks*} on SBCL, or @code{ext:*before-save-initializations*}
on CMUCL and SCL, etc.
@node Using ASDF, Defining systems with defsystem, Configuring ASDF, Top
@chapter Using ASDF
@menu
* Loading a system::
* Convenience Functions::
* Moving on::
@end menu
@node Loading a system, Convenience Functions, Using ASDF, Using ASDF
@section Loading a system
The system @var{foo} is loaded (and compiled, if necessary)
by evaluating the following Lisp form:
@example
(asdf:load-system :@var{foo})
@end example
On some implementations (@pxref{Convenience Functions}),
ASDF hooks into the @code{cl:require} facility and you can just use:
@example
(require :@var{foo})
@end example
Note that the canonical name of a system is a string, in @emph{lowercase}.
System names can also be specified as symbols (including keyword
symbols).
If a symbol is given as argument, its package is ignored,
its @code{symbol-name} is taken, and converted to lowercase.
The name must be a suitable value for the @code{:name} initarg
to @code{make-pathname} in whatever filesystem the system is to be found.
Using lowercase as canonical is unconventional,
but was selected after some consideration.
The type of file systems we support
either have lowercase as customary case (Unix, Mac, Windows)
or silently convert lowercase to uppercase (lpns).
@c so this makes more sense than attempting to use @code{:case :common},
@c which is reported not to work on some implementations
@node Convenience Functions, Moving on, Loading a system, Using ASDF
@section Convenience Functions
@c I believe thes are all unnecessary because of the function macros
@c below [2016/01/30:rpg]
@c @findex load-system
@c @findex compile-system
@c @findex test-system
@c @findex require-system
@c @findex make
ASDF provides three commands for the most common system operations:
@code{load-system}, @code{compile-system}, and @code{test-system}.
ASDF also provides @code{require-system}, a variant of @code{load-system}
that skips loading systems that are already loaded. This is sometimes
useful, for example, in order to avoid re-loading libraries that come
pre-loaded into your lisp implementation.
ASDF also provides @code{make}, a way of allowing system developers to
choose a default operation for their systems. For example, a developer
who has created a system intended to format a specific document, might
make document-formatting the default operation invoked by @code{make},
instead of loading. If the system developer doesn't specify in the
system definition, the default operation will be loading.
@c FIXME: We seem to export @findex bundle-system also, that some ECL users seem to rely on.
@c But it's probably better that bundle operations have their own manual chapter at some point.
@c FIXME: There should be a @defun for OPERATE, but there isn't. Not
@c sure where it belongs... The discussion here is just confusing if
@c the reader doesn't understand how ASDF works. [2016/01/30:rpg]
@findex operate
@findex oos
Because ASDF is an extensible system
for defining @emph{operations} on @emph{components},
it also provides a generic function @code{operate},
so you may arbitrarily operate on your systems beyond the default operations.
(At the interactive REPL, users often use its shorter alias @code{oos},
which stands for operate-on-system, a name inherited from @code{mk-defsystem}.)
You'll use @code{operate} whenever you want to do something beyond
compiling, loading and testing.
@c Reminder: before ASDF can operate on a system, however,
@c it must be able to find and load that system's definition.
@c @xref{Configuring ASDF to find your systems}.
@c FIXME: the following is too complicated for here, especially since
@c :force hasn't been defined yet. Move it. [2014/02/27:rpg]
@defun load-system system @Arest{} keys @Akey{} force force-not verbose version @AallowOtherKeys{}
Apply @code{operate} with the operation @code{load-op}, the
@var{system}, and any provided keyword arguments. Calling
@code{load-system} is the regular, recommended way to load a system
into the current image.
@end defun
@defun compile-system system @Arest{} keys @Akey{} force force-not verbose version @AallowOtherKeys{}
Apply @code{operate} with the operation @code{compile-op},
the @var{system}, and any provided keyword arguments.
This will make sure all the files in the system are compiled,
but not necessarily load any of them in the current image;
on most systems, it will @emph{not} load all compiled files in the current image.
This function exists for symmetry with @code{load-system} but is not recommended
unless you are writing build scripts and know what you're doing.
But then, you might be interested in @code{program-op} rather than @code{compile-op}.
@end defun
@defun test-system system @Arest{} keys @Akey{} force force-not verbose version @AallowOtherKeys{}
Apply @code{operate} with the operation @code{test-op},
the @var{system}, and any provided keyword arguments.
@xref{test-op}.
@end defun
@defun make system @Arest{} keys @Akey{} @AallowOtherKeys{}
Do ``The Right Thing'' with your system.
Starting with ASDF 3.1, this function @code{make} is also available.
The default behaviour is to load the system as if by @code{load-system};
but system authors can override this default in their system definition
they may specify an alternate operation as the intended use of their system,
with a @code{:build-operation} option in the @code{defsystem} form
(@pxref{Build-operation}),
and an intended output pathname for that operation with
@code{:build-pathname}.
@c Document :build-operation in the defsystem section.
@c Document in the extension section that for richer programmatic access, you may instead use an overriding
@c @code{(defmethod component-depends-on ((o build-op) (s system))
@c ...)}.
This function is experimental and largely untested. Use at your own risk.
@end defun
@cindex build-operation
@defun require-system system @Arest{} keys @Akey{} @AallowOtherKeys{}
@code{require-system} skips any update to systems that have already been loaded,
in the spirit of @code{cl:require}.
It does it by calling @code{load-system} with a keyword option
excluding already loaded systems.@footnote{
For the curious, the option is @code{:force-not (already-loaded-systems)}.
}.
On actively maintained free software implementations
(namely recent versions of ABCL, Clozure CL, CMUCL, ECL, GNU CLISP, MKCL and SBCL),
once ASDF itself is loaded, @code{cl:require} too can load ASDF systems,
by falling back on @code{require-system}
for module names not recognized by the implementation.
(Note however that @code{require-system} does @emph{not} fall back on @code{cl:require};
that would introduce an ``interesting'' potential infinite loop to break somehow.)
@code{cl:require} and @code{require-system} are appropriate to load code
that is not being modified during the current programming session.
@code{cl:require} will notably load the implementation-provided extension modules;
@code{require-system} won't, unless they are also defined as systems somehow,
which SBCL and MKCL do.
@code{require-system} may also be used to load any number of ASDF systems
that the user isn't either developing or debugging,
for which a previously installed version is deemed to be satisfactory;
@code{cl:require} on the above-mentioned implementations will delegate to @code{require-system}
and may load them as well.
But for code that you are actively developing, debugging, or otherwise modifying,
you should use @code{load-system}, so ASDF will pick on your modifications
and transitively re-build the modified files and everything that depends on them
(that the requested @var{system} itself depends on ---
ASDF itself never builds anything unless
it's an explicitly requested system or the dependencies thereof).
@end defun
@defun already-loaded-systems
Returns a list of names of the systems that have been successfully
loaded so far.
@end defun
@node Moving on, , Convenience Functions, Using ASDF
@section Moving on
That's all you need to know to use ASDF to load systems written by others.
The rest of this manual deals with writing system definitions
for Common Lisp software you write yourself,
including how to extend ASDF to define new operation and component types.
@node Defining systems with defsystem, The object model of ASDF, Using ASDF, Top
@comment node-name, next, previous, up
@chapter Defining systems with defsystem
This chapter describes how to use ASDF to define systems and develop
software.
@menu
* The defsystem form::
* A more involved example::
* The defsystem grammar::
* Other code in .asd files::
* The package-inferred-system extension::
@end menu
@node The defsystem form, A more involved example, Defining systems with defsystem, Defining systems with defsystem
@comment node-name, next, previous, up
@section The defsystem form
@findex defsystem
@cindex asdf-user
@findex load-asd
This section begins with an example of a system definition,
then gives the full grammar of @code{defsystem}.
Let's look at a simple system.
This is a complete file that should be saved as @file{hello-lisp.asd}
(in order that ASDF can find it
when ordered to operate on the system named @code{"hello-lisp"}).
@lisp
;; Usual Lisp comments are allowed here
(defsystem "hello-lisp"
:description "hello-lisp: a sample Lisp system."
:version "0.0.1"
:author "Joe User "
:licence "Public Domain"
:depends-on ("optima.ppcre" "command-line-arguments")
:components ((:file "packages")
(:file "macros" :depends-on ("packages"))
(:file "hello" :depends-on ("macros"))))
@end lisp
Some notes about this example:
@itemize
@item
The @code{defsystem} form defines a system named @code{hello-lisp}
that contains three source files:
@file{packages.lisp}, @file{macros.lisp} and @file{hello.lisp}.
@item
The @file{.lisp} suffix is implicit for Lisp source files.
The source files are located in the same directory
as the @code{.asd} file with the system definition.
@c FIXME: the following should live somewhere, but not in the quickstart
@c page. [2014/05/03:rpg]
@c ASDF resolves symbolic links (or Windows shortcuts)
@c before loading the system definition file and
@c stores its location in the resulting system@footnote{
@c It is possible, though almost never necessary, to override this behaviour.}.
@c This is a good thing because the user can move the system sources
@c without having to edit the system definition.
@c FIXME: The first example system should probably use just :serial T.
@item
The file @file{macros} depends on @file{packages}
(presumably because the package it's in is defined in @file{packages}),
and the file @file{hello} depends on @file{macros}
(and hence, transitively on @file{packages}).
This means that ASDF will compile and load @file{packages} then @file{macros}
before starting the compilation of file @file{hello}.
@item
This example system has external dependencies on two other systems,
@code{optima.ppcre} (that provides a friendly interface to matching regular expressions),
and @code{command-line-arguments} (that provides a way to parse arguments passed from the shell command line).
To use this system, ASDF must be configured to find installed copies of these systems;
it will load them before it tries to compile and load @code{hello-lisp}.
@item
This system also defines a bunch of metadata.
While it is optional to define these fields
(and other fields like @code{:bug-tracker}, @code{:mailto}, @code{:long-name},
@code{:long-description}, @code{:source-control}),
it is strongly recommended to define the fields @code{:description}, @code{:version}, @code{:author}, and @code{:licence},
especially if you intend your software to be eventually included in Quicklisp.
@c FIXME: Should have cross-reference to "Version specifiers" in the
@c defsystem grammar, but the cross-referencing is so broken by
@c insufficient node breakdown that I have not put one in.
@c FIXME: this is way too detailed for the first example!
@c move it!
@item
Make sure you know how the @code{:version} numbers will be parsed!
Only period-separated non-negative integers are accepted at present.
@xref{Version specifiers}.
@item
This file contains a single form, the @code{defsystem} declaration.
No @code{in-package} form, no @code{asdf:} package prefix, no nothing.
Just the one naked @code{defsystem} form.
This is what we recommend.
More complex system definition files are possible with arbitrary Lisp code,
but we recommend that you keep it simple if you can.
This will make your system definitions more robust and more future-proof.
@cindex :version
@end itemize
This is all you need to know to define simple systems.
The next example is much more involved, to give you a glimpse of how you can do more complex things.
However, since it's ultimately arbitrary Lisp code, there is no bottom to the rabbit hole.
@c FIXME: divide the next example into many examples, to introduce fewer concepts at once.
@node A more involved example, The defsystem grammar, The defsystem form, Defining systems with defsystem
@comment node-name, next, previous, up
@section A more involved example
@findex defsystem
Let's illustrate some more involved uses of @code{defsystem} via a
slightly convoluted example:
@lisp
(in-package :asdf-user)
(defsystem "foo"
:version (:read-file-form "variables" :at (3 2))
:components
((:file "package")
(:file "variables" :depends-on ("package"))
(:module "mod"
:depends-on ("package")
:serial t
:components ((:file "utils")
(:file "reader")
(:file "cooker")
(:static-file "data.raw"))
:output-files (compile-op (o c) (list "data.cooked"))
:perform (compile-op :after (o c)
(cook-data
:in (component-pathname (find-component c "data.raw"))
:out (first (output-files o c)))))
(:file "foo" :depends-on ("mod"))))
(defmethod action-description
((o compile-op) (c (eql (find-component "foo" "mod"))))
"cooking data")
@end lisp
Here are some notes about this example:
@itemize
@item
The main thing this file does is define a system @code{foo}.
It also contains other Lisp forms, which we'll examine below.
@item
Besides Lisp source files, this system contains a @code{:module} component
named @code{"mod"}, which is a collection of three Lisp source files
@file{utils.lisp}, @file{reader.lisp}, @file{cooker.lisp} and @file{data.raw}
@item
Note that the @code{:static-file} does not have an implicit file type,
unlike the Lisp source files.
@item
This files will be located in a subdirectory of the main code directory named
@file{mod/} (this location could have been overridden to be
in the same directory, or in a different subdirectory;
see the discussion of the @code{:pathname} option in @ref{The defsystem grammar}).
@item
The @code{:serial t} says that each sub-component of @code{mod} depends on the previous components,
so that @file{cooker.lisp} depends-on @file{reader.lisp}, which depends-on @file{utils.lisp}.
Also @file{data.raw} depends on all of them, but that doesn't matter since it's a static file;
on the other hand, if it appeared first, then all the Lisp files would be recompiled
when the data is modified, which is probably not what is desired in this case.
@item
The method-form tokens provide a shorthand for defining methods on
particular components. This part
@lisp
:output-files (compile-op (o c) (list "data.cooked"))
:perform (compile-op :after (o c)
(cook-data
:in (component-pathname (find-component c "data.raw"))
:out (first (output-files o c))))
@end lisp
has the effect of
@lisp
(defmethod output-files ((o compile-op) (c (eql ...)))
(list "data.cooked"))
(defmethod perform :after ((o compile-op) (c (eql ...)))
(cook-data
:in (component-pathname (find-component c "data.raw"))
:out (first (output-files o c))))
@end lisp
where @code{...} is the component in question.
In this case @code{...} would expand to something like
@lisp
(find-component "foo" "mod")
@end lisp
For more details on the syntax of such forms,
@pxref{The defsystem grammar}.
For more details on what these methods do, @pxref{Operations} in
@ref{The object model of ASDF}.
@item
There is an additional @code{defmethod} with a similar effect,
because ASDF (as of ASDF 3.1.5)
fails to accept inline-methods as above for @code{action-description},
instead only supporting the deprecated @code{explain} interface.
@c FIXME: The following plunge into detail weeds is not appropriate in this
@c location. [2010/10/03:rpg]
@c note that although this also supports @code{:before} methods,
@c they may not do what you want them to ---
@c a @code{:before} method on perform @code{((op compile-op) (c (eql ...)))}
@c will run after all the dependencies and sub-components have been processed,
@c but before the component in question has been compiled.
@item
In this case, these methods describe how this module defines code
that it then uses to cook some data.
@item
Importantly, ASDF is told about the input and output files
used by the data cooker,
and to make sure everyone agrees,
the cooking function explicitly uses ASDF to access pathnames
to the input and output data.
@c FIXME: move most of this package discussion to its own section,
@c and leave only a reference here.
@item
The file starts with a form @code{(in-package :asdf-user)},
but it is actually redundant, not necessary and not recommended.
But yet more complex cases (also not recommended) may usefully use an @code{in-package} form.
@item
Indeed, ASDF does not load @file{.asd} files simply with @code{cl:load},
and neither should you.
You should let ASDF find and load them when you operate on systems.
If you somehow @emph{must} load a @file{.asd} file,
use the same function @code{asdf:load-asd} that ASDF uses.
Among other things, it already binds the @code{*package*} to @code{asdf-user}.
Recent versions of SLIME (2013-02 and later) know to do that when you @kbd{C-c C-k}
when you use the @code{slime-asdf} contrib.
@item
You shouldn't use an @code{in-package} form
if you're keeping things simple.
You should only use @code{in-package} (and before it, a @code{defpackage})
when you're going to define new classes, functions, variables, macros, etc.,
in the @code{.asd} file, and want to thereby avoid name clashes.
Manuals for old versions of ASDF recommended use of such an idiom in @file{.asd} files,
but as of ASDF 3, we recommend that you don't do that anymore,
and instead define any ASDF extensions in their own system,
on which you can then declare a dependency using @code{:defsystem-depends-on}.
@xref{The defsystem grammar}.
@item
More generally, you can always rely on symbols
from packages @code{asdf}, @code{common-lisp} and @code{uiop}
being available in @code{.asd} files ---
most importantly including @code{defsystem}.
It is therefore redundant and in bad taste to use a package-prefixed @code{asdf:defsystem} symbol
in a @file{.asd} file.
Just use @code{(defsystem ...)}.
Only package-prefix it when somehow dynamically generating system definitions
from a package that doesn't already use the ASDF package.
@item
@code{asdf-user} is actually only available starting since ASDF 3, but then again,
ASDF 1 and 2 did crazy things with packages that ASDF 3 has stopped doing@footnote{
ASDF 1 and 2 (up until 2.26)
used to dynamically create and delete temporary packages @code{asdf@emph{N}},
one for each @file{.asd} file, in a misguided attempt to thereby reduce name clashes;
but it failed at that goal and only made things more complex.
ASDF 3 just uses a shared package @code{asdf-user} instead,
and relies on the usual Common Lisp conventions to avoid clashes.
As far as package oddities go, you may just notice that
the @code{asdf-user} package also uses @code{uiop/common-lisp},
a variant of the @code{common-lisp} package that papers over
deficiencies in more obscure Common Lisp implementations;
but unless you care about Corman Lisp, GCL, Genera or MCL, you shouldn't be concerned.
},
and since all implementations provide ASDF 3, you shouldn't care about compatibility with ASDF 2.
We do not support ASDF 2 anymore, and we recommend that neither should you.
@item
Starting with ASDF 3.1, @code{asdf-user} uses @code{uiop},
whereas in earlier variants of ASDF 3 it only used @code{uiop/package}.
We recommend you either prefix use of UIOP functions with the package prefix @code{uiop:},
or make sure your system @code{:depends-on ((:version "asdf" "3.1.2"))}
or has a @code{#-asdf3.1 (error "MY-SYSTEM requires ASDF 3.1.2")}.
@item
Finally, we elided most metadata, but showed how you can have ASDF automatically extract
the system's version from a source file. In this case, the 3rd subform of the 4th form
(note that Lisp uses 0-based indexing, English uses 1-based indexing).
Presumably, the 4th form looks like @code{(defparameter *foo-version* "5.6.7")}.
@end itemize
@node The defsystem grammar, Other code in .asd files, A more involved example, Defining systems with defsystem
@comment node-name, next, previous, up
@section The defsystem grammar
@findex defsystem
@cindex DEFSYSTEM grammar
@macro defrule {NAME}
@anchor{rule-\NAME\}\NAME\ :=
@end macro
@ifhtml
@macro refrule {NAME}
@ref{rule-\NAME\,\NAME\}
@end macro
@end ifhtml
@ifinfo
@macro refrule {NAME}
@ref{rule-\NAME\,\NAME\,\NAME\,\NAME\}
@end macro
@end ifinfo
@ifnothtml
@ifnotinfo
@macro refrule {NAME}
\NAME\
@end macro
@end ifnotinfo
@end ifnothtml
@example
@defrule{system-definition} ( defsystem @refrule{system-designator} @refrule{system-option}* )
@defrule{system-designator} @refrule{simple-component-name}
| @refrule{complex-component-name}
# NOTE: Underscores are not permitted.
# @pxref{Simple component names,Simple component names,Simple component names}
@defrule{simple-component-name} @var{lower-case string} | @var{symbol}
# @pxref{Complex component names,Complex component names,Complex component names}
@defrule{complex-component-name} @var{string} | @var{symbol}
@defrule{system-option} :defsystem-depends-on @refrule{system-list}
| :weakly-depends-on @refrule{system-list}
| :class @var{class-name} # @pxref{System class names}
| :build-pathname @refrule{pathname-specifier}
| :build-operation @refrule{operation-name}
| @refrule{system-option/asdf3}
| @refrule{module-option}
| @refrule{option}
# These are only available since ASDF 3 (actually its alpha release
# 2.27)
@defrule{system-option/asdf3} :homepage @var{string}
| :bug-tracker @var{string}
| :mailto @var{string}
| :long-name @var{string}
| :source-control @refrule{source-control}
| :version @refrule{version-specifier}
| :entry-point @var{object} # @pxref{Entry point}
@defrule{source-control} ( @var{keyword} @var{string} )
@defrule{module-option} :components @refrule{component-list}
| :serial [ t | nil ]
@defrule{option} :description @var{string}
| :long-description @var{string}
| :author @refrule{person-or-persons}
| :maintainer @refrule{person-or-persons}
| :pathname @refrule{pathname-specifier}
| :default-component-class @var{class-name}
| :perform @refrule{method-form}
| :explain @refrule{method-form}
| :output-files @refrule{method-form}
| :operation-done-p @refrule{method-form}
| :if-feature @refrule{feature-expression}
| :depends-on ( @refrule{dependency-def}* )
| :in-order-to ( @refrule{dependency}+ )
@defrule{person-or-persons} @var{string} | ( @var{string}+ )
@defrule{system-list} ( @refrule{simple-component-name}* )
@defrule{component-list} ( @refrule{component-def}* )
@defrule{component-def} ( @refrule{component-type} @refrule{simple-component-name} @refrule{option}* )
@defrule{component-type} :module | :file | :static-file | @refrule{other-component-type}
@defrule{other-component-type} symbol-by-name # @pxref{Component types}
# This is used in :depends-on, as opposed to "dependency", which is used
# in :in-order-to
@defrule{dependency-def} @refrule{simple-component-name}
| ( :feature @refrule{feature-expression} @refrule{dependency-def} ) # @pxref{Feature dependencies}
| ( :version @refrule{simple-component-name} @refrule{version-specifier} )
| ( :require @var{module-name} )
# "dependency" is used in :in-order-to, as opposed to "dependency-def"
@defrule{dependency} ( @refrule{dependent-op} @refrule{requirement}+ )
@defrule{requirement} ( @refrule{required-op} @var{required-component}+ )
@defrule{dependent-op} @refrule{operation-name}
@defrule{required-op} @refrule{operation-name}
# NOTE: pathnames should be all lower case, and have no underscores,
# although hyphens are permitted.
@defrule{pathname-specifier} @var{pathname} | @var{string} | @var{symbol}
@defrule{version-specifier} @var{string}
| ( :read-file-form @refrule{pathname-specifier} @refrule{form-specifier}? )
| ( :read-file-line @refrule{pathname-specifier} @refrule{line-specifier}? )
@defrule{line-specifier} :at @var{integer} # base zero
@defrule{form-specifier} :at [ @var{integer} | ( @var{integer}+ ) ]
@defrule{method-form} ( @refrule{operation-name} @refrule{qual} @var{lambda-list} @Arest{} @var{body} )
@defrule{qual} @refrule{method-qualifier}?
@defrule{method-qualifier} :before | :after | :around
@defrule{feature-expression} @var{keyword}
| ( :and @refrule{feature-expression}* )
| ( :or @refrule{feature-expression}* )
| ( :not @refrule{feature-expression} )
@defrule{operation-name} @var{symbol}
@end example
@subsection System designators
System designators are either simple component names, or
complex (``slashy'') component names.
@subsection Simple component names (@code{simple-component-name})
@anchor{Simple component names}
Simple component names may be written as either strings or symbols.
When using strings, use lower case exclusively.
Symbols will be interpreted as convenient shorthand for the string
that is their @code{symbol-name}, converted to lower case. Put
differently, a symbol may be a simple component name @emph{designator},
but the simple component name itself is the string.
@strong{Never} use underscores in component names, whether written as
strings or symbols.
@strong{Never} use slashes (``/'') in simple component names. A slash
indicates a @emph{complex} component name; see below. Using a slash
improperly will cause ASDF to issue a warning.
Violating these constraints by mixing case, or including underscores in
component names, may lead to systems or components being impossible to
find, because component names are interpreted as file names. These
problems will @emph{definitely} occur for users who have configured ASDF
using logical pathnames.
@subsection Complex component names
@anchor{Complex component names}
A complex component name is a master name followed by a slash, followed
by a subsidiary name. This allows programmers to put multiple system
definitions in a single @code{.asd} file, while still allowing ASDF to
find these systems.
The master name of a complex system @strong{must} be the same as the
name of the @code{.asd} file.
The file @code{foo.asd} will contain the definition of the system
@code{"foo"}. However, it may @emph{also} contain definitions of
subsidiary systems, such as @code{"foo/test"}, @code{"foo/docs"}, and so
forth. ASDF will ``know'' that if you ask it to load system
@code{"foo/test"} it should look for that system's definition in @code{foo.asd}.
@subsection Component types
@anchor{Component types}
Component type names, even if expressed as keywords, will be looked up
by name in the current package and in the asdf package, if not found in
the current package. So a component type @code{my-component-type}, in
the current package @code{my-system-asd} can be specified as
@code{:my-component-type}, or @code{my-component-type}.
@code{system} and its subclasses are @emph{not}
allowed as component types for such children components.
@subsection System class names
@anchor{System class names}
A system class name will be looked up
in the same way as a Component type (see above),
except that only @code{system} and its subclasses are allowed.
Typically, one will not need to specify a system
class name, unless using a non-standard system class defined in some
ASDF extension, typically loaded through @code{DEFSYSTEM-DEPENDS-ON},
see below. For such class names in the ASDF package, we recommend that
the @code{:class} option be specified using a keyword symbol, such as
@example
:class :MY-NEW-SYSTEM-SUBCLASS
@end example
This practice will ensure that package name conflicts are avoided.
Otherwise, the symbol @code{MY-NEW-SYSTEM-SUBCLASS} will be read into
the current package @emph{before} it has been exported from the ASDF
extension loaded by @code{:defsystem-depends-on}, causing a name
conflict in the current package.
@subsection Defsystem depends on
@cindex :defsystem-depends-on
The @code{:defsystem-depends-on} option to @code{defsystem} allows the
programmer to specify another ASDF-defined system or set of systems that
must be loaded @emph{before} the system definition is processed.
Typically this is used to load an ASDF extension that is used in the
system definition.
@subsection Build-operation
@cindex :build-operation
@anchor{Build-operation}
The @code{:build-operation} option to @code{defsystem} allows the
programmer to specify an operation that will be applied, in place of
@code{load-op} when @code{make} (@pxref{Convenience Functions, make})
is run on the system. The option
value should be the name of an operation. E.g., @code{:build-operation doc-op}
This feature is
experimental and largely untested. Use at your own risk.
@subsection Weakly depends on
@cindex :weakly-depends-on
We do @emph{NOT} recommend you use this feature.
If you are tempted to write a system @var{foo}
that weakly-depends-on a system @var{bar},
we recommend that you should instead
write system @var{foo} in a parametric way,
and offer some special variable and/or some hook to specialize its behaviour;
then you should write a system @var{foo+bar}
that does the hooking of things together.
The (deprecated) @code{:weakly-depends-on} option to @code{defsystem}
allows the programmer to specify another ASDF-defined system or set of systems
that ASDF should @emph{try} to load,
but need not load in order to be successful.
Typically this is used if there are a number of systems
that, if present, could provide additional functionality,
but which are not necessary for basic function.
Currently, although it is specified to be an option only to @code{defsystem},
this option is accepted at any component, but it probably
only makes sense at the @code{defsystem} level.
Programmers are cautioned not
to use this component option except at the @code{defsystem} level, as
this anomalous behaviour may be removed without warning.
@c Finally, you might look into the @code{asdf-system-connections} extension,
@c that will let you define additional code to be loaded
@c when two systems are simultaneously loaded.
@c It may or may not be considered good style, but at least it can be used
@c in a way that has deterministic behaviour independent of load order,
@c unlike @code{weakly-depends-on}.
@subsection Pathname specifiers
@cindex pathname specifiers
@anchor{Pathname specifiers}
A pathname specifier (@code{pathname-specifier})
may be a pathname, a string or a symbol.
When no pathname specifier is given for a component,
which is the usual case, the component name itself is used.
If a string is given, which is the usual case,
the string will be interpreted as a Unix-style pathname
where @code{/} characters will be interpreted as directory separators.
Usually, Unix-style relative pathnames are used
(i.e. not starting with @code{/}, as opposed to absolute pathnames);
they are relative to the path of the parent component.
Finally, depending on the @code{component-type},
the pathname may be interpreted as either a file or a directory,
and if it's a file,
a file type may be added corresponding to the @code{component-type},
or else it will be extracted from the string itself (if applicable).
For instance, the @code{component-type} @code{:module}
wants a directory pathname, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar/"}.
On the other hand, the @code{component-type} @code{:file}
wants a file of type @code{lisp}, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar.lisp"},
and a string @code{"foo/bar.quux"}
will be interpreted as the pathname @file{#p"foo/bar.quux.lisp"}.
Finally, the @code{component-type} @code{:static-file}
wants a file without specifying a type, and so a string @code{"foo/bar"}
will be interpreted as the pathname @file{#p"foo/bar"},
and a string @code{"foo/bar.quux"}
will be interpreted as the pathname @file{#p"foo/bar.quux"}.
ASDF interprets the string @code{".."}
as the pathname directory component word @code{:back},
which when merged, goes back one level in the directory hierarchy.
If a symbol is given, it will be translated into a string,
and downcased in the process.
The downcasing of symbols is unconventional,
but was selected after some consideration.
The file systems we support
either have lowercase as customary case (Unix, Mac, Windows)
or silently convert lowercase to uppercase (lpns),
so this makes more sense than attempting to use @code{:case :common}
as argument to @code{make-pathname},
which is reported not to work on some implementations.
Please avoid using underscores in system names, or component (module or
file) names, since underscores are not
compatible with logical pathnames (@pxref{Using logical pathnames}).
Pathname objects may be given to override the path for a component.
Such objects are typically specified using reader macros such as @code{#p}
or @code{#.(make-pathname ...)}.
Note however, that @code{#p...} is
a shorthand for @code{#.(parse-namestring ...)}
and that the behaviour of @code{parse-namestring} is completely non-portable,
unless you are using Common Lisp @code{logical-pathname}s,
which themselves involve other non-portable behaviour
(@pxref{Using logical pathnames}).
Pathnames made with @code{#.(make-pathname ...)}
can usually be done more easily with the string syntax above.
The only case that you really need a pathname object is to override
the component-type default file type for a given component.
Therefore, pathname objects should only rarely be used.
Unhappily, ASDF 1 used not to properly support
parsing component names as strings specifying paths with directories,
and the cumbersome @code{#.(make-pathname ...)} syntax had to be used.
An alternative to @code{#.} read-time evaluation is to use
@code{(eval `(defsystem ... ,pathname ...))}.
Note that when specifying pathname objects,
ASDF does not do any special interpretation of the pathname
influenced by the component type, unlike the procedure for
pathname-specifying strings.
On the one hand, you have to be careful to provide a pathname that correctly
fulfills whatever constraints are required from that component type
(e.g. naming a directory or a file with appropriate type);
on the other hand, you can circumvent the file type that would otherwise
be forced upon you if you were specifying a string.
@subsection Version specifiers
@cindex version specifiers
@cindex :version
@anchor{Version specifiers}
Version specifiers are strings to be parsed as period-separated lists of integers.
I.e., in the example, @code{"0.2.1"} is to be interpreted,
roughly speaking, as @code{(0 2 1)}.
In particular, version @code{"0.2.1"} is interpreted the same as @code{"0.0002.1"},
though the latter is not canonical and may lead to a warning being issued.
Also, @code{"1.3"} and @code{"1.4"} are both strictly @code{uiop:version<} to @code{"1.30"},
quite unlike what would have happened
had the version strings been interpreted as decimal fractions.
Instead of a string representing the version,
the @code{:version} argument can be an expression that is resolved to
such a string using the following trivial domain-specific language:
in addition to being a literal string, it can be an expression of the form
@code{(:read-file-form [:at ])},
or @code{(:read-file-line [:at ])}.
As the name suggests, the former will be resolved by reading a form in the specified pathname
(read as a subpathname of the current system if relative or a
unix-namestring), and the latter by reading a line.
You may use a @code{uiop:access-at} specifier
with the @code{:at} keyword,
by default the specifier is @code{0}, meaning the first form/line is
returned.
For @code{:read-file-form},
subforms can also be specified, with e.g. @code{(1 2 2)} specifying
``the third subform (index 2) of the third subform (index 2) of the second form (index 1)''
in the file (mind the off-by-one error in the English language).
System definers are encouraged to use version identifiers of the form
@var{x}.@var{y}.@var{z} for
major version, minor version and patch level,
where significant API incompatibilities are signaled by an increased major number.
@xref{Common attributes of components}.
@subsection Require
@cindex :require dependencies
Use the implementation's own @code{require} to load the @var{module-name}.
It is good taste to use @code{(:feature @emph{:implementation-name} (:require @var{module-name}))}
rather than @code{#+@emph{implementation-name} (:require @var{module-name})}
to only depend on the specified module on the specific implementation that provides it.
@xref{Feature dependencies}.
@subsection Feature dependencies
@cindex :feature dependencies
@anchor{Feature dependencies}
A feature dependency is of the form
@code{(:feature @var{feature-expression} @var{dependency})}
If the @var{feature-expression} is satisfied by the running lisp at the
time the system definition is parsed, then the @var{dependency} will be
added to the system's dependencies. If the @var{feature-expression} is
@emph{not} satisfied, then the feature dependency form is ignored.
Note that this means that @code{:feature} @strong{cannot} be used to
enforce a feature dependency for the system in question. I.e., it
cannot be used to require that a feature hold in order for the system
definition to be loaded. E.g., one cannot use @code{(:feature :sbcl)}
to require that a system only be used on SBCL.
Feature dependencies are not to be confused with the obsolete
feature requirement (@pxref{feature requirement}), or
with @code{if-feature}.
@subsection Using logical pathnames
@cindex logical pathnames
@anchor{Using logical pathnames}
We do not generally recommend the use of logical pathnames,
especially not so to newcomers to Common Lisp.
However, we do support the use of logical pathnames by old timers,
when such is their preference.
To use logical pathnames,
you will have to provide a pathname object as a @code{:pathname} specifier
to components that use it, using such syntax as
@code{#p"LOGICAL-HOST:absolute;path;to;component.lisp"}.
You only have to specify such logical pathname
for your system or some top-level component.
Sub-components' relative pathnames,
specified using the string syntax for names,
will be properly merged with the pathnames of their parents.
The specification of a logical pathname host however is @emph{not}
otherwise directly supported in the ASDF syntax
for pathname specifiers as strings.
The @code{asdf-output-translation} layer will
avoid trying to resolve and translate logical pathnames.
The advantage of this is that
you can define yourself what translations you want to use
with the logical pathname facility.
The disadvantage is that if you do not define such translations,
any system that uses logical pathnames will behave differently under
asdf-output-translations than other systems you use.
If you wish to use logical pathnames you will have to configure the
translations yourself before they may be used.
ASDF currently provides no specific support
for defining logical pathname translations.
Note that the reasons we do not recommend logical pathnames are that
(1) there is no portable way to set up logical pathnames @emph{before} they are used,
(2) logical pathnames are limited to only portably use
a single character case, digits and hyphens.
While you can solve the first issue on your own,
describing how to do it on each of fifteen implementations supported by ASDF
is more than we can document.
As for the second issue, mind that the limitation is notably enforced on SBCL,
and that you therefore can't portably violate the limitations
but must instead define some encoding of your own and add individual mappings
to name physical pathnames that do not fit the restrictions.
This can notably be a problem when your Lisp files are part of a larger project
in which it is common to name files or directories in a way that
includes the version numbers of supported protocols,
or in which files are shared with software written
in different programming languages where conventions include the use of
underscores, dots or CamelCase in pathnames.
@subsection Serial dependencies
@cindex serial dependencies
If the @code{:serial t} option is specified for a module,
ASDF will add dependencies for each child component,
on all the children textually preceding it.
This is done as if by @code{:depends-on}.
@lisp
:serial t
:components ((:file "a") (:file "b") (:file "c"))
@end lisp
is equivalent to
@lisp
:components ((:file "a")
(:file "b" :depends-on ("a"))
(:file "c" :depends-on ("a" "b")))
@end lisp
@subsection Source location (@code{:pathname})
The @code{:pathname} option is optional in all cases for systems
defined via @code{defsystem}, and generally is unnecessary. In the
simple case, source files will be found in the same directory as the
system or, in the case of modules, in a subdirectory with the same name
as the module.
@c FIXME: This should be moved elsewhere -- it's too much detail for the
@c grammar section.
More specifically, ASDF follows a hairy set of rules that are designed so that
@enumerate
@item
@code{find-system}
will load a system from disk
and have its pathname default to the right place.
@item
This pathname information will not be overwritten with
@code{*default-pathname-defaults*}
(which could be somewhere else altogether)
if the user loads up the @file{.asd} file into his editor
and interactively re-evaluates that form.
@end enumerate
If a system is being loaded for the first time,
its top-level pathname will be set to:
@itemize
@item
The host/device/directory parts of @code{*load-truename*},
if it is bound.
@item
@code{*default-pathname-defaults*}, otherwise.
@end itemize
If a system is being redefined, the top-level pathname will be
@itemize
@item
changed, if explicitly supplied or obtained from @code{*load-truename*}
(so that an updated source location is reflected in the system definition)
@item
changed if it had previously been set from @code{*default-pathname-defaults*}
@item
left as before, if it had previously been set from @code{*load-truename*}
and @code{*load-truename*} is currently unbound
(so that a developer can evaluate a @code{defsystem} form
from within an editor without clobbering its source location)
@end itemize
@subsection if-feature option
@cindex :if-feature component option
@anchor{if-feature option} @c redo if this ever becomes a node in
@c its own right...
This option allows you to specify a feature expression to be evaluated
as if by @code{#+} to conditionally include a component in your build.
If the expression is false, the component is dropped
as well as any dependency pointing to it.
As compared to using @code{#+} which is expanded at read-time,
this allows you to have an object in your component hierarchy
that can be used for manipulations beside building your project, and
that is accessible to outside code that wishes to reason about system
structure.
Programmers should be careful to consider @strong{when} the
@code{:if-feature} is evaluated. Recall that ASDF first computes a
build plan, and then executes that plan. ASDF will check to see whether
or not a feature is present @strong{at planning time}, not during the
build. It follows that one cannot use @code{:if-feature} to check
features that are set during the course of the build. It can only be
used to check the state of features before any build operations have
been performed.
This option was added in ASDF 3. For more information,
@xref{required-features, Required features}.
@subsection Entry point
@cindex :entry-point
@anchor{Entry point}
The @code{:entry-point} option allows a developer to specify the entry point of an executable program created by @code{program-op}.
When @code{program-op} is invoked, the form passed to this option is converted to a function by @code{uiop:ensure-function} and bound to @code{uiop:*image-entry-point*}. Typically one will specify a string, e.g. @code{"foo:main"}, so that the executable starts with the @code{foo:main} function. Note that using the symbol @code{foo:main} instead might not work because the @code{foo} package doesn't necessarily exist when ASDF reads the @code{defsystem} form. For more information on @code{program-op}, @pxref{Predefined operations of ASDF}.
@subsection feature requirement
@anchor{feature requirement}
This requirement was removed in ASDF 3.1. Please do not use it. In
most cases, @code{:if-feature} (@pxref{if-feature option}) will provide
an adequate substitute.
The @code{feature} requirement used to ensure that a chain of component
dependencies would fail when a key feature was absent.
Used in conjunction with @code{:if-component-dep-fails}
this provided
a roundabout way to express conditional compilation.
@node Other code in .asd files, The package-inferred-system extension, The defsystem grammar, Defining systems with defsystem
@section Other code in .asd files
Files containing @code{defsystem} forms
are regular Lisp files that are executed by @code{load}.
Consequently, you can put whatever Lisp code you like into these files.
However, it is recommended to keep such forms to a minimal,
and to instead define @code{defsystem} extensions
that you use with @code{:defsystem-depends-on}.
If however, you might insist on including code in the @file{.asd} file itself,
e.g., to examine and adjust the compile-time environment,
possibly adding appropriate features to @code{*features*}.
If so, here are some conventions we recommend you follow,
so that users can control certain details of execution
of the Lisp in @file{.asd} files:
@itemize
@item
Any informative output
(other than warnings and errors,
which are the condition system's to dispose of)
should be sent to the standard CL stream @code{*standard-output*},
so that users can easily control the disposition
of output from ASDF operations.
@end itemize
@node The package-inferred-system extension, , Other code in .asd files, Defining systems with defsystem
@section The package-inferred-system extension
@codequoteundirected on
@cindex Package inferred systems
@cindex Packages, inferring dependencies from
@findex package-inferred-system
@cindex One package per file systems
Starting with release 3.1.2,
ASDF supports a one-package-per-file style of programming,
in which each file is its own system,
and dependencies are deduced from the @code{defpackage} form
or its variant, @code{uiop:define-package}.
In this style of system definition, package names map to systems with
the same name (in lower case letters),
and if a system is defined with @code{:class package-inferred-system},
then system names that start with that name
(using the slash @code{/} separator)
refer to files under the filesystem hierarchy where the system is defined.
For instance, if system @code{my-lib} is defined in
@file{/foo/bar/my-lib/my-lib.asd}, then system @code{my-lib/src/utility}
will be found in file @file{/foo/bar/my-lib/src/utility.lisp}.
One package per file style was made popular by @code{faslpath} and @code{quick-build},
and at the cost of stricter package discipline,
may yield more maintainable code.
This style is used in ASDF itself (starting with ASDF 3), by @code{lisp-interface-library},
and a few other libraries.
To use this style, choose a toplevel system name, e.g. @code{my-lib},
and create a file @file{my-lib.asd}.
Define @code{my-lib}
using the @code{:class :package-inferred-system} option in its @code{defsystem}.
For instance:
@example
;; This example is based on lil.asd of LISP-INTERFACE-LIBRARY.
#-asdf3.1 (error "MY-LIB requires ASDF 3.1 or later.")
(defsystem "my-lib"
:class :package-inferred-system
:depends-on ("my-lib/interface/all"
"my-lib/src/all"
"my-lib/extras/all")
:in-order-to ((test-op (load-op "my-lib/test/all")))
:perform (test-op (o c) (symbol-call :my-lib/test/all :test-suite)))
(defsystem "my-lib/test" :depends-on ("my-lib/test/all"))
(register-system-packages "my-lib/interface/all" '(:my-lib-interface))
(register-system-packages "my-lib/src/all" '(:my-lib-implementation))
(register-system-packages "my-lib/test/all" '(:my-lib-test))
(register-system-packages
"closer-mop"
'(:c2mop
:closer-common-lisp
:c2cl
:closer-common-lisp-user
:c2cl-user))
@end example
@noindent
In the code above, the first form checks that we are using ASDF 3.1 or
later, which provides @code{package-inferred-system}. This is probably
no longer necessary, since none of the major lisp implementations
provides an older version of ASDF.
@findex register-system-packages
The function @code{register-system-packages} must be called to register
packages used or provided by your system
when the name of the system/file that provides the package
is not the same as the package name (converted to lower case).
Each file under the @code{my-lib} hierarchy will start with a
package definition.
@findex define-package
@findex uiop:define-package
The form @code{uiop:define-package} is supported as well as
@code{defpackage}.
ASDF will compute dependencies from the
@code{:use}, @code{:mix}, and other importation clauses of this package definition. Take the file
@file{interface/order.lisp} as an example:
@example
(uiop:define-package :my-lib/interface/order
(:use :closer-common-lisp
:my-lib/interface/definition
:my-lib/interface/base)
(:mix :fare-utils :uiop :alexandria)
(:export ...))
@end example
ASDF can tell that this file/system depends on system @code{closer-mop} (registered above),
@code{my-lib/interface/definition}, and @code{my-lib/interface/base}.
How can ASDF find the file @file{interface/order.lisp} from the
toplevel system @code{my-lib}, however? In the example above,
@file{interface/all.lisp} (and other @file{all.lisp}) reexport
all the symbols exported from the packages at the same or lower levels
of the hierarchy. This can be easily done with
@code{uiop:define-package}, which has many options that prove useful in this
context. For example:
@example
(uiop:define-package :my-lib/interface/all
(:nicknames :my-lib-interface)
(:use :closer-common-lisp)
(:mix :fare-utils :uiop :alexandria)
(:use-reexport
:my-lib/interface/definition
:my-lib/interface/base
:my-lib/interface/order
:my-lib/interface/monad/continuation))
@end example
Thus the top level system need only depend on the @code{my-lib/.../all} systems
because ASDF detects
@file{interface/order.lisp} and all other dependencies from @code{all}
systems' @code{:use-reexport} clauses, which effectively
allow for ``inheritance'' of symbols being exported.
ASDF also detects dependencies from @code{:import-from} clauses.
You may thus import a well-defined set of symbols from an existing
package, and ASDF will know to load the system that provides that
package. In the following example, ASDF will infer that the current
system depends on @code{foo/baz} from the first @code{:import-from}.
If you prefer to use any such symbol fully qualified by a package prefix,
you may declare a dependency on such a package and its corresponding system
via an @code{:import-from} clause with an empty list of symbols. For
example, if we preferred to use the name `foo/quux:bletch`, the second,
empty, @code{:import-from} form would cause ASDF to load
@code{foo/quux}.
@example
(defpackage :foo/bar
(:use :cl)
(:import-from :foo/baz #:sym1 #:sym2)
(:import-from :foo/quux)
(:export ...))
@end example
Note that starting with ASDF 3.1.5.6 only, ASDF will look for source files under
the @code{component-pathname} (specified via the @code{:pathname} option),
whereas earlier versions ignore this option and use the @code{system-source-directory}
where the @file{.asd} file resides.
@c See this blog post about it:
@c @url{http://davazp.net/2014/11/26/modern-library-with-asdf-and-package-inferred-system.html}
@codequoteundirected off
@node The object model of ASDF, Controlling where ASDF searches for systems, Defining systems with defsystem, Top
@comment node-name, next, previous, up
@chapter The Object model of ASDF
@tindex component
@tindex operation
ASDF is designed in an object-oriented way from the ground up.
Both a system's structure and the operations that can be performed on systems
follow an extensible protocol, allowing programmers to add new behaviours to ASDF.
For example, @code{cffi} adds support for special FFI description files
that interface with C libraries and for wrapper files that embed C code in Lisp.
@code{asdf-jar} supports creating Java JAR archives in ABCL.
@code{poiu} supports compiling code in parallel using background processes.
The key classes in ASDF are @code{component} and @code{operation}.
A @code{component} represents an individual source file or a group of source files,
and the products (e.g., fasl files) produced from it.
An @code{operation} represents a transformation that can be performed on a component,
turning them from source files to intermediate results to final outputs.
Components are related by @emph{dependencies}, specified in system
definitions.
When ordered to @code{operate} with some operation on a component (usually a system),
ASDF will first compute a @emph{plan}
by traversing the dependency graph using function @code{make-plan}.@footnote{
Historically, the function that built a plan was
called @code{traverse}, and returned a list of actions;
it was deprecated in favor of @code{make-plan} (that returns a plan object)
when the @code{plan} objects were introduced with ASDF 3;
the old function is kept for backward compatibility and debugging purposes only,
and may be removed in the near future.
}
The resulting plan object contains an ordered list of @emph{actions}.
An action is a pair of an @code{operation} and a @code{component},
representing a particular build step to be @code{perform}ed.
The ordering of the plan ensures that no action is performed before
all its dependencies have been fulfilled.@footnote{
The term @emph{action}
was used by Kent Pitman in his article, ``The Description of Large Systems,''
(@pxref{Bibliography}),
and we suspect might be traced to @code{make}.
Although the term was only used by ASDF hackers starting with ASDF 2,
the concept was there since the very beginning of ASDF 1,
just not clearly articulated.
}
In this chapter, we describe ASDF's object-oriented protocol,
the classes that make it up, and the generic functions on those classes.
These generic functions often take
both an operation and a component as arguments:
much of the power and configurability of ASDF is provided by
this use of CLOS's multiple dispatch.
We will describe the built-in component and operation classes, and
explain how to extend the ASDF protocol by defining new classes and
methods for ASDF's generic functions.
We will also describe the many @emph{hooks} that can be configured to
customize the behaviour of existing @emph{functions}.
@c FIXME: Swap operations and components.
@c FIXME: Possibly add a description of the PLAN object.
@c Not critical, since the user isn't expected to interact with it.
@menu
* Operations::
* Components::
* Dependencies::
* Functions::
@end menu
@node Operations, Components, The object model of ASDF, The object model of ASDF
@comment node-name, next, previous, up
@section Operations
@cindex operation
An @dfn{operation} object of the appropriate type is instantiated
whenever the user wants to do something with a system like
@itemize
@item compile all its files
@item load the files into a running lisp environment
@item copy its source files somewhere else
@end itemize
Operations can be invoked directly, or examined
to see what their effects would be without performing them.
There are a bunch of methods specialised on operation and component type
that actually do the grunt work.
Operations are invoked on systems via @code{operate} (@pxref{operate}).
ASDF contains a number of pre-defined @t{operation} classes for common,
and even fairly uncommon tasks that you might want to do with it.
In addition, ASDF contains ``abstract'' @t{operation} classes that
programmers can use as building blocks to define ASDF extensions. We
discuss these in turn below.
@c The operation object contains whatever state is relevant for this purpose
@c (perhaps a list of visited nodes, for example)
@c but primarily is a nice thing to specialise operation methods on
@c and easier than having them all be @code{EQL} methods.
@menu
* Predefined operations of ASDF::
* Creating new operations::
@end menu
Operations are invoked on systems via @code{operate}.
@anchor{operate}
@deffn {Generic function} operate @var{operation} @var{component} @Arest{} @var{initargs} @Akey{} @code{force} @code{force-not} @code{verbose} @AallowOtherKeys
@deffnx {Generic function} oos @var{operation} @var{component} @Arest{} @var{initargs} @Akey{} @AallowOtherKeys{}
@code{operate} invokes @var{operation} on @var{system}.
@code{oos} is a synonym for @code{operate} (it stands for operate-on-system).
@var{operation} is an operation designator:
it can be an operation object itself, or, typically,
a symbol that is passed to @code{make-operation} (which will call @code{make-instance}),
to create the operation object.
@var{component} is a component designator:
it can be a component object itself, or, typically,
a string or symbol (to be @code{string-downcase}d) that names a system,
more rarely a list of strings or symbols that designate a subcomponent of a system.
The ability to pass @var{initargs} to @code{make-operation} is now deprecated, and will be removed.
For more details, @pxref{make-operation}.
Note that dependencies may cause the operation
to invoke other operations on the system or its components:
the new operations may or may not be created
with the same @var{initargs} as the original one (for the moment).
If @var{force} is @code{:all}, then all systems
are forced to be recompiled even if not modified since last compilation.
If @var{force} is @code{t}, then only the system being loaded
is forced to be recompiled even if not modified since last compilation,
but other systems are not affected.
If @var{force} is a list, then it specifies a list of systems that
are forced to be recompiled even if not modified since last compilation.
If @var{force-not} is @code{:all}, then all systems
are forced not to be recompiled even if modified since last compilation.
If @var{force-not} is @code{t}, then all systems but the system being loaded
are forced not to be recompiled even if modified since last compilation
(note: this was changed in ASDF 3.1.2).
If @var{force-not} is a list, then it specifies a list of systems that
are forced not to be recompiled even if modified since last compilation.
@findex register-immutable-system
@cindex immutable systems
Both @var{force} and @var{force-not} apply to systems that are dependencies and were already compiled.
@var{force-not} takes precedences over @var{force},
as it should, really, but unhappily only since ASDF 3.1.2.
Moreover, systems which have been registered as immutable by @code{register-immutable-system} (since ASDF 3.1.5)
are always considered @var{forced-not}, and even their @file{.asd} are not refreshed from the filesystem.
@xref{Miscellaneous Functions}.
@findex traverse
To see what @code{operate} would do, you can use:
@example
(asdf:traverse operation-class system-name)
@end example
@end deffn
@defun make-operation @var{operation-class} @Arest{} @var{initargs}
@anchor{make-operation}
The @var{initargs} are passed to @code{make-instance} call
when creating the operation object.
@strong{Note:}@var{initargs} for @code{operation}s are now deprecated,
and will be removed from ASDF in the near future.
@strong{Note:} @code{operation} instances must @strong{never} be created
using @code{make-instance} directly: only through
@code{make-operation}. Attempts to directly make @code{operation}
instances will cause a run-time error.
@end defun
@node Predefined operations of ASDF, Creating new operations, Operations, Operations
@comment node-name, next, previous, up
@subsection Predefined operations of ASDF
All the operations described in this section are in the @code{asdf} package.
They are invoked via the @code{operate} generic function.
@lisp
(asdf:operate 'asdf:@var{operation-name} :@var{system-name} @{@var{operation-options ...}@})
@end lisp
@deftp Operation compile-op
This operation compiles the specified component.
A @code{cl-source-file} will be @code{compile-file}'d.
All the children and dependencies of a system or module
will be recursively compiled by @code{compile-op}.
@code{compile-op} depends on @code{prepare-op} which
itself depends on a @code{load-op} of all of a component's dependencies,
as well as of its parent's dependencies.
When @code{operate} is called on @code{compile-op},
all these dependencies will be loaded as well as compiled;
yet, some parts of the system main remain unloaded,
because nothing depends on them.
Use @code{load-op} to load a system.
@end deftp
@deftp Operation load-op
This operation loads the compiled code for a specified component.
A @code{cl-source-file} will have its compiled fasl @code{load}ed,
which fasl is the output of @code{compile-op} that @code{load-op} depends on.
@code{load-op} will recursively load all the children of a system or module.
@code{load-op} also depends on @code{prepare-op} which
itself depends on a @code{load-op} of all of a component's dependencies,
as well as of its parent's dependencies.
@end deftp
@deftp Operation prepare-op
This operation ensures that the dependencies of a component
and its recursive parents are loaded (as per @code{load-op}),
as a prerequisite before @code{compile-op} and @code{load-op} operations
may be performed on a given component.
@end deftp
@deftp Operation load-source-op
@deftpx Operation prepare-source-op
@code{load-source-op} will load the source for the files in a module
rather than the compiled fasl output.
It has a @code{prepare-source-op} analog to @code{prepare-op},
that ensures the dependencies are themselves loaded via @code{load-source-op}.
@end deftp
@anchor{test-op}
@deftp Operation test-op
This operation will perform some tests on the module.
The default method will do nothing.
The default dependency is to require
@code{load-op} to be performed on the module first.
Its default @code{operation-done-p} method returns @code{nil},
which means that the operation is @emph{never} done
--
we assume that if you invoke the @code{test-op},
you want to test the system, even if you have already done so.
The results of this operation are not defined by ASDF.
It has proven difficult to define how the test operation
should signal its results to the user
in a way that is compatible with all of the various test libraries
and test techniques in use in the community, and
given the fact that ASDF operations do not return a value indicating
success or failure.
For those willing to go to the effort, we suggest defining conditions to
signal when a @code{test-op} fails, and storing in those conditions
information that describes which tests fail.
People typically define a separate test @emph{system} to hold the tests.
Doing this avoids unnecessarily adding a test framework as a dependency
on a library. For example, one might have
@lisp
(defsystem "foo"
:in-order-to ((test-op (test-op "foo/test")))
...)
(defsystem "foo/test"
:depends-on ("foo" "fiveam") ; fiveam is a test framework library
...)
@end lisp
Then one defines @code{perform} methods on
@code{test-op} such as the following:
@lisp
(defsystem "foo/test"
:depends-on ("foo" "fiveam") ; fiveam is a test framework library
:perform (test-op (o s)
(uiop:symbol-call :fiveam '#:run!
(uiop:find-symbol* '#:foo-test-suite
:foo-tests)))
...)
@end lisp
@end deftp
@deftp Operation compile-bundle-op
@deftpx Operation monolithic-compile-bundle-op
@deftpx Operation load-bundle-op
@deftpx Operation monolithic-load-bundle-op
@deftpx Operation deliver-asd-op
@deftpx Operation monolithic-deliver-asd-op
@deftpx Operation lib-op
@deftpx Operation monolithic-lib-op
@deftpx Operation dll-op
@deftpx Operation monolithic-dll-op
@deftpx Operation image-op
@deftpx Operation program-op
These are ``bundle'' operations, that can create a single-file ``bundle''
for all the contents of each system in an application,
or for the entire application.
@code{compile-bundle-op} will create a single fasl file for each of the systems needed,
grouping all its many fasls in one,
so you can deliver each system as a single fasl.
@code{monolithic-compile-bundle-op} will create a single fasl file for the target system
and all its dependencies,
so you can deliver your entire application as a single fasl.
@code{load-bundle-op} will load the output of @code{compile-bundle-op}.
Note that if the output is not up-to-date,
@code{compile-bundle-op} may load the intermediate fasls as a side-effect.
Bundling fasls together matters a lot on ECL,
where the dynamic linking involved in loading tens of individual fasls
can be noticeably more expensive than loading a single one.
NB: @code{compile-bundle-op}, @code{monolithic-compile-bundle-op}, @code{load-bundle-op}, @code{monolithic-load-bundle-op}, @code{deliver-asd-op}, @code{monolithic-deliver-asd-op} were respectively called
@code{fasl-op}, @code{monolithic-fasl-op}, @code{load-fasl-op}, @code{monolithic-load-fasl-op}, @code{binary-op}, @code{monolithic-binary-op} before ASDF 3.1.
The old names still exist for backward compatibility,
though they poorly label what is going on.
Once you have created a fasl with @code{compile-bundle-op},
you can use @code{precompiled-system} to deliver it in a way
that is compatible with clients having dependencies on your system,
whether it is distributed as source or as a single binary;
the @file{.asd} file to be delivered with the fasl will look like this:
@example
(defsystem :mysystem :class :precompiled-system
:fasl (some expression that will evaluate to a pathname))
@end example
Or you can use @code{deliver-asd-op} to let ASDF create such a system for you
as well as the @code{compile-bundle-op} output,
or @code{monolithic-deliver-asd-op}.
This allows you to deliver code for your systems or applications
as a single file.
Of course, if you want to test the result in the current image,
@emph{before} you try to use any newly created @file{.asd} files,
you should not forget to @code{(asdf:clear-configuration)}
or at least @code{(asdf:clear-source-registry)},
so it re-populates the source-registry from the filesystem.
The @code{program-op} operation will create an executable program
from the specified system and its dependencies.
You can use UIOP for its pre-image-dump hooks, its post-image-restore hooks,
and its access to command-line arguments.
And you can specify an entry point @code{my-app:main}
by specifying in your @code{defsystem}
the option @code{:entry-point "my-app:main"}.
Depending on your implementation,
running @code{(asdf:operate 'asdf:program-op :my-app)}
may quit the current Lisp image upon completion.
See the example in
@file{test/hello-world-example.asd} and @file{test/hello.lisp},
as built and tested by
@file{test/test-program.script} and @file{test/make-hello-world.lisp}.
@code{image-op} will dump an image that may not be standalone
and does not start its own function,
but follows the usual execution convention of the underlying Lisp,
just with more code pre-loaded,
for use as an intermediate build result or with a wrapper invocation script.
There is also @code{lib-op}
for building a linkable @file{.a} file (Windows: @file{.lib})
from all linkable object dependencies (FFI files, and on ECL, Lisp files too),
and its monolithic equivalent @code{monolithic-lib-op}.
And there is also @code{dll-op}
(respectively its monolithic equivalent @code{monolithic-dll-op})
for building a linkable @file{.so} file
(Windows: @file{.dll}, MacOS X: @file{.dynlib})
to create a single dynamic library
for all the extra FFI code to be linked into each of your systems
(respectively your entire application).
All these ``bundle'' operations are available since ASDF 3
on all actively supported Lisp implementations,
but may be unavailable on unmaintained legacy implementations.
This functionality was previously available for select implementations,
as part of a separate system @code{asdf-bundle},
itself descended from the ECL-only @code{asdf-ecl}.
The pathname of the output of bundle operations
is subject to output-translation as usual,
unless the operation is equal to
the @code{:build-operation} argument to @code{defsystem}.
This behaviour is not very satisfactory and may change in the future.
Maybe you have suggestions on how to better configure it?
@end deftp
@deftp Operation concatenate-source-op
@deftpx Operation monolithic-concatenate-source-op
@deftpx Operation load-concatenated-source-op
@deftpx Operation compile-concatenated-source-op
@deftpx Operation load-compiled-concatenated-source-op
@deftpx Operation monolithic-load-concatenated-source-op
@deftpx Operation monolithic-compile-concatenated-source-op
@deftpx Operation monolithic-load-compiled-concatenated-source-op
These operations, as their respective names indicate,
will concatenate all the @code{cl-source-file} source files in a system
(or in a system and all its dependencies, if monolithic),
in the order defined by dependencies,
then load the result, or compile and then load the result.
These operations are useful to deliver a system or application
as a single source file,
and for testing that said file loads properly, or compiles and then loads properly.
ASDF itself is delivered as a single source file this way,
using @code{monolithic-concatenate-source-op},
prepending a prelude and the @code{uiop} library
before the @code{asdf/defsystem} system itself.
@end deftp
@node Creating new operations, , Predefined operations of ASDF, Operations
@comment node-name, next, previous, up
@subsection Creating new operations
ASDF was designed to be extensible in an object-oriented fashion.
To teach ASDF new tricks, a programmer can implement the behaviour he wants
by creating a subclass of @code{operation}.
ASDF's pre-defined operations are in no way ``privileged'',
but it is requested that developers never use the @code{asdf} package
for operations they develop themselves.
The rationale for this rule is that we don't want to establish a
``global asdf operation name registry'',
but also want to avoid name clashes.
Your operation @emph{must} usually provide methods
for one or more of the following generic functions:
@itemize
@findex perform
@item @code{perform}
Unless your operation, like @code{prepare-op},
is for dependency propagation only,
the most important function for which to define a method
is usually @code{perform},
which will be called to perform the operation on a specified component,
after all dependencies have been performed.
The @code{perform} method must call @code{input-files} and @code{output-files} (see below)
to locate its inputs and outputs,
because the user is allowed to override the method
or tweak the output-translation mechanism.
Perform should only use the primary value returned by @code{output-files}.
If one and only one output file is expected,
it can call @code{output-file} that checks that this is the case
and returns the first and only list element.
@findex output-files
@item @code{output-files}
If your perform method has any output,
you must define a method for this function.
for ASDF to determine where the outputs of performing operation lie.
Your method may return two values, a list of pathnames, and a boolean.
If the boolean is @code{nil} (or you fail to return multiple values),
then enclosing @code{:around} methods may translate these pathnames,
e.g. to ensure object files are somehow stored
in some implementation-dependent cache.
If the boolean is @code{t} then the pathnames are marked
not be translated by the enclosing @code{:around} method.
@findex component-depends-on
@item @code{component-depends-on}
If the action of performing the operation on a component has dependencies,
you must define a method on @code{component-depends-on}.
Your method will take as specialized arguments
an operation and a component which together identify an action,
and return a list of entries describing actions that this action depends on.
The format of entries is described below.
It is @emph{strongly} advised that
you should always append the results of @code{(call-next-method)}
to the results of your method,
or ``interesting'' failures will likely occur,
unless you're a true specialist of ASDF internals.
It is unhappily too late to compatibly use the @code{append} method combination,
but conceptually that's the protocol that is being manually implemented.
Each entry returned by @code{component-depends-on} is itself a list.
The first element of an entry is an operation designator:
either an operation object designating itself, or
a symbol that names an operation class
(that ASDF will instantiate using @code{make-operation}).
For instance, @code{load-op}, @code{compile-op} and @code{prepare-op}
are common such names, denoting the respective operations.
@c FIXME COERCE-NAME is referenced, but not defined.
@findex coerce-name
@findex find-component
The rest of each entry is a list of component designators:
either a component object designating itself,
or an identifier to be used with @code{find-component}.
@code{find-component} will be called with the current component's parent as parent,
and the identifier as second argument.
The identifier is typically a string,
a symbol (to be downcased as per @code{coerce-name}),
or a list of strings or symbols.
In particular, the empty list @code{nil} denotes the parent itself.
@end itemize
An operation @emph{may} provide methods for the following generic functions:
@itemize
@item @code{input-files}
@findex input-files
A method for this function is often not needed,
since ASDF has a pretty clever default @code{input-files} mechanism.
You only need create a method if there are multiple ultimate input
files.
Most operations inherit from @code{selfward-operation}, which
appropriately sets the input-files to include the source file itself.
@c FIXME: Add documentation of built-in operation types.
@defun input-files operation component
Return a list of pathnames that represent the input to @var{operation}
performed on @var{component}.
@end defun
@item @code{operation-done-p}
@findex operation-done-p
You only need to define a method on that function
if you can detect conditions that invalidate previous runs of the operation,
even though no filesystem timestamp has changed,
in which case you return @code{nil} (the default is @code{t}).
For instance, the method for @code{test-op} always returns @code{nil},
so that tests are always run afresh.
Of course, the @code{test-op} for your system could depend
on a deterministically repeatable @code{test-report-op},
and just read the results from the report files,
in which case you could have this method return @code{t}.
@end itemize
Operations that print output should send that output to the standard
CL stream @code{*standard-output*}, as the Lisp compiler and loader do.
@node Components, Dependencies, Operations, The object model of ASDF
@comment node-name, next, previous, up
@section Components
@cindex component
@cindex system
@cindex system designator
@cindex component designator
@vindex *system-definition-search-functions*
A @code{component} represents an individual source file or a group of source files,
and the things that get transformed into.
A @code{system} is a component at the top level of the component hierarchy,
that can be found via @code{find-system}.
A @code{source-file} is a component representing a single source-file
and the successive output files into which it is transformed.
A @code{module} is an intermediate component itself grouping several other components,
themselves source-files or further modules.
A @dfn{system designator} is a system itself,
or a string or symbol that behaves just like any other component name
(including with regard to the case conversion rules for component names).
A @dfn{component designator}, relative to a base component,
is either a component itself,
or a string or symbol,
or a list of designators.
@defun find-system system-designator @Aoptional{} (error-p t)
Given a system designator, @code{find-system} finds and returns a system.
If no system is found, an error of type
@code{missing-component} is thrown,
or @code{nil} is returned if @code{error-p} is false.
To find and update systems, @code{find-system} funcalls each element
in the @code{*system-definition-search-functions*} list,
expecting a pathname to be returned, or a system object,
from which a pathname may be extracted, and that will be registered.
The resulting pathname (if any) is loaded
if one of the following conditions is true:
@itemize
@item
there is no system of that name in memory
@item
the pathname is different from that which was previously loaded
@item
the file's @code{last-modified} time exceeds the @code{last-modified} time
of the system in memory
@end itemize
@cindex ASDF-USER package
When system definitions are loaded from @file{.asd} files,
they are implicitly loaded into the @code{ASDF-USER} package,
which uses @code{ASDF}, @code{UIOP} and @code{UIOP/COMMON-LISP}@footnote{
Note that between releases 2.27 and 3.0.3, only @code{UIOP/PACKAGE},
not all of @code{UIOP}, was used; if you want your code to work
with releases earlier than 3.1.2, you may have to explicitly define a package
that uses @code{UIOP}, or use proper package prefix to your symbols, as in
@code{uiop:version<}.}
Programmers who do anything non-trivial in a @file{.asd} file,
such as defining new variables, functions or classes,
should include @code{defpackage} and @code{in-package} forms in this file,
so they will not overwrite each others' extensions.
Such forms might also help the files behave identically
if loaded manually with @code{cl:load} for development or debugging,
though we recommend you use the function @code{asdf::load-asd} instead,
which the @code{slime-asdf} contrib knows about.
The default value of @code{*system-definition-search-functions*}
is a list of three functions.
The first function looks in each of the directories given
by evaluating members of @code{*central-registry*}
for a file whose name is the name of the system and whose type is @file{asd};
the first such file is returned,
whether or not it turns out to actually define the appropriate system.
The second function does something similar,
for the directories specified in the @code{source-registry},
but searches the filesystem only once and caches its results.
The third function makes the @code{package-inferred-system} extension work,
@pxref{The package-inferred-system extension}.
Because of the way these search functions are defined,
you should put the definition for a system
@var{foo} in a file named @file{foo.asd},
in a directory that is
in the central registry or
which can be found using the
source registry configuration.
@c FIXME: Move this discussion to the system definition grammar, or somewhere else.
@anchor{System names}
@cindex System names
@cindex Primary system name
@findex primary-system-name
It is often useful to define multiple systems in a same file,
but ASDF can only locate a system's definition file based on the system
name.
For this reason,
ASDF 3's system search algorithm has been extended to
allow a file @file{foo.asd} to contain
secondary systems named @var{foo/bar}, @var{foo/baz}, @var{foo/quux}, etc.,
in addition to the primary system named @var{foo}.
The first component of a system name,
separated by the slash character, @code{/},
is called the primary name of a system.
The primary name may be
extracted by function @code{asdf::primary-system-name};
when ASDF 3 is told to find a system whose name has a slash,
it will first attempt to load the corresponding primary system,
and will thus see any such definitions, and/or any
definition of a @code{package-inferred-system}.@footnote{
ASDF 2.26 and earlier versions
do not support this primary system name convention.
With these versions of ASDF
you must explicitly load @file{foo.asd}
before you can use system @var{foo/bar} defined therein,
e.g. using @code{(asdf:find-system "foo")}.
We do not support ASDF 2, and recommend that you should upgrade to ASDF 3.
}
If your file @file{foo.asd} also defines systems
that do not follow this convention, e.g., a system named @var{foo-test},
ASDF will not be able to automatically locate a definition for these systems,
and will only see their definition
if you explicitly find or load the primary system
using e.g. @code{(asdf:find-system "foo")} before you try to use them.
We strongly recommend against this practice,
though it is currently supported for backward compatibility.
@end defun
@defun primary-system-name name
Internal (not exported) function, @code{asdf::primary-system-name}.
Returns the primary system name (the portion before
the slash, @code{/}, in a secondary system name) from @var{name}.
@end defun
@defun locate-system name
This function should typically @emph{not} be invoked directly. It is
exported as part of the API only for programmers who wish to provide
their own @code{*system-definition-search-functions*}.
Given a system @var{name} designator,
try to locate where to load the system definition from.
@c (This does not include the loading of the system definition,
@c which is done by @code{find-system},
@c or the loading of the system itself, which is done by @code{load-system};
@c however, for systems the definition of which has already been loaded,
@c @code{locate-system} may return an object of class @code{system}.)
Returns five values: @var{foundp}, @var{found-system}, @var{pathname},
@var{previous}, and @var{previous-time}.
@var{foundp} is true when a system was found,
either a new as yet unregistered one, or a previously registered one.
The @var{found-system} return value
will be a @code{system} object, if a system definition is found in your
source registry.
@c This system may be registered (by @code{register-system}) or may not, if
@c it's preloaded code. Fare writes:
@c In the case of preloaded code, as for "asdf", "uiop", etc.,
@c themselves, the system objects are not registered until after they are
@c initially located by sysdef-preloaded-system-search as a fallback when
@c no source code was found.
The system definition will @emph{not} be
loaded if it hasn't been loaded already.
@var{pathname} when not null is a path from which to load the system,
either associated with @var{found-system}, or with the @var{previous} system.
If @var{previous} is not null, it will be a @emph{previously loaded}
@code{system} object of the same name (note that the system
@emph{definition} is previously-loaded: the system itself may or may not be).
@var{previous-time} when not null is
the timestamp of the previous system definition file, at the
time when the @var{previous} system definition was loaded.
For example, if your current registry has @file{foo.asd} in
@file{/current/path/to/foo.asd},
but system @code{foo} was previously loaded from @file{/previous/path/to/foo.asd}
then @var{locate-system} will return the following values:
@enumerate
@item
@var{foundp} will be @code{t},
@item
@var{found-system} will be @code{nil},
@item
@var{pathname} will be @code{#p"/current/path/to/foo.asd"},
@item
@var{previous} will be an object of type @code{SYSTEM} with
@code{system-source-file} slot value of
@code{#p"/previous/path/to/foo.asd"}
@item
@var{previous-time} will be the timestamp of
@code{#p"/previous/path/to/foo.asd"} at the time it was loaded.
@end enumerate
@end defun
@defun find-component base path
Given a @var{base} component (or designator for such),
and a @var{path}, find the component designated by the @var{path}
starting from the @var{base}.
If @var{path} is a component object, it designates itself,
independently from the base.
@findex coerce-name
If @var{path} is a string, or symbol denoting a string via @code{coerce-name},
then @var{base} is resolved to a component object,
which must be a system or module,
and the designated component is the child named by the @var{path}.
If @var{path} is a @code{cons} cell,
@code{find-component} with the base and the @code{car} of the @var{path},
and the resulting object is used as the base for a tail call
to @code{find-component} with the @code{car} of the @var{path}.
If @var{base} is a component object, it designates itself.
If @var{base} is null, then @var{path} is used as the base, with @code{nil} as the path.
If @var{base} is a string, or symbol denoting a string via @code{coerce-name},
it designates a system as per @code{find-system}.
If @var{base} is a @code{cons} cell, it designates the component found by
@code{find-component} with its @code{car} as base and @code{cdr} as path.
@end defun
@menu
* Common attributes of components::
* Pre-defined subclasses of component::
* Creating new component types::
@end menu
@node Common attributes of components, Pre-defined subclasses of component, Components, Components
@comment node-name, next, previous, up
@subsection Common attributes of components
All components, regardless of type, have the following attributes.
All attributes except @code{name} are optional.
@subsubsection Name
@findex coerce-name
A component name is a string or a symbol.
If a symbol, its name is taken and lowercased. This translation is
performed by the exported function @code{coerce-name}.
Unless overridden by a @code{:pathname} attribute,
the name will be interpreted as a pathname specifier according
to a Unix-style syntax.
@xref{Pathname specifiers}.
@subsubsection Version identifier
@findex version-satisfies
@cindex :version
This optional attribute specifies a version for the current component.
The version should typically be a string of integers separated by dots,
for example @samp{1.0.11}. @xref{Version specifiers}.
A version may then be queried by the generic function @code{version-satisfies},
to see if @code{:version} dependencies are satisfied,
and when specifying dependencies, a constraint of minimal version to satisfy
can be specified using e.g. @code{(:version "mydepname" "1.0.11")}.
Note that in the wild, we typically see version numbering
only on components of type @code{system}.
Presumably it is much less useful within a given system,
wherein the library author is responsible to keep the various files in synch.
@subsubsection Required features
@anchor{required-features}
Traditionally defsystem users have used @code{#+} reader conditionals
to include or exclude specific per-implementation files.
For example, CFFI, the portable C foreign function interface contained
lines like:
@lisp
#+sbcl (:file "cffi-sbcl")
@end lisp
An unfortunate side effect of this approach is that no single
implementation can read the entire system.
This causes problems if, for example, one wished to design an @code{archive-op}
that would create an archive file containing all the sources, since
for example the file @code{cffi-sbcl.lisp} above would be invisible when
running the @code{archive-op} on any implementation other than SBCL.
Starting with ASDF 3,
components may therefore have an @code{:if-feature} option.
The value of this option should be
a feature expression using the same syntax as @code{#+} does.
If that feature expression evaluates to false, any reference to the component will be ignored
during compilation, loading and/or linking.
Since the expression is read by the normal reader,
you must explicitly prefix your symbols with @code{:} so they be read as keywords;
this is as contrasted with the @code{#+} syntax
that implicitly reads symbols in the keyword package by default.
For instance, @code{:if-feature (:and :x86 (:or :sbcl :cmu :scl))} specifies that
the given component is only to be compiled and loaded
when the implementation is SBCL, CMUCL or Scieneer CL on an x86 machine.
You cannot write it as @code{:if-feature (and x86 (or sbcl cmu scl))}
since the symbols would not be read as keywords.
@xref{if-feature option}.
@subsubsection Dependencies
This attribute specifies dependencies of the component on its siblings.
It is optional but often necessary.
There is an excitingly complicated relationship between the initarg
and the method that you use to ask about dependencies
Dependencies are between (operation component) pairs.
In your initargs for the component, you can say
@lisp
:in-order-to ((compile-op (load-op "a" "b") (compile-op "c"))
(load-op (load-op "foo")))
@end lisp
This means the following things:
@itemize
@item
before performing compile-op on this component, we must perform
load-op on @var{a} and @var{b}, and compile-op on @var{c},
@item
before performing @code{load-op}, we have to load @var{foo}
@end itemize
The syntax is approximately
@verbatim
(this-op @{(other-op required-components)@}+)
simple-component-name := string
| symbol
required-components := simple-component-name
| (required-components required-components)
component-name := simple-component-name
| (:version simple-component-name minimum-version-object)
@end verbatim
Side note:
This is on a par with what ACL defsystem does.
mk-defsystem is less general: it has an implied dependency
@verbatim
for all source file x, (load x) depends on (compile x)
@end verbatim
and using a @code{:depends-on} argument to say that @var{b} depends on
@var{a} @emph{actually} means that
@verbatim
(compile b) depends on (load a)
@end verbatim
This is insufficient for e.g. the McCLIM system, which requires that
all the files are loaded before any of them can be compiled ]
End side note
In ASDF, the dependency information for a given component and operation
can be queried using @code{(component-depends-on operation component)},
which returns a list
@lisp
((load-op "a") (load-op "b") (compile-op "c") ...)
@end lisp
@code{component-depends-on} can be subclassed for more specific
component/operation types: these need to @code{(call-next-method)}
and append the answer to their dependency, unless
they have a good reason for completely overriding the default dependencies.
If it weren't for CLISP, we'd be using @code{LIST} method
combination to do this transparently.
But, we need to support CLISP.
If you have the time for some CLISP hacking,
I'm sure they'd welcome your fixes.
@c Doesn't CLISP now support LIST method combination?
A minimal version can be specified for a component you depend on
(typically another system), by specifying @code{(:version "other-system" "1.2.3")}
instead of simply @code{"other-system"} as the dependency.
See the discussion of the semantics of @code{:version}
in the defsystem grammar.
@c FIXME: Should have cross-reference to "Version specifiers" in the
@c defsystem grammar, but the cross-referencing is so broken by
@c insufficient node breakdown that I have not put one in.
@subsubsection pathname
This attribute is optional and if absent (which is the usual case),
the component name will be used.
@xref{Pathname specifiers},
for an explanation of how this attribute is interpreted.
Note that the @code{defsystem} macro (used to create a ``top-level'' system)
does additional processing to set the filesystem location of
the top component in that system.
This is detailed elsewhere. @xref{Defining systems with defsystem}.
To find the CL pathname corresponding to a component, use
@defun component-pathname component
Returns the pathname corresponding to @var{component}. For components
such as source files, this will be a filename pathname. For example:
@lisp
CL-USER> (asdf:component-pathname (asdf:find-system "xmls"))
#P"/Users/rpg/lisp/xmls/"
@end lisp
and
@lisp
CL-USER> (asdf:component-pathname
(asdf:find-component
(asdf:find-system "xmls") "xmls"))
#P"/Users/rpg/lisp/xmls/xmls.lisp"
@end lisp
@end defun
@subsubsection properties
This attribute is optional.
Packaging systems often require information about files or systems
in addition to that specified by ASDF's pre-defined component attributes.
Programs that create vendor packages out of ASDF systems therefore
have to create ``placeholder'' information to satisfy these systems.
Sometimes the creator of an ASDF system may know the additional
information and wish to provide it directly.
@code{(component-property component property-name)} and
associated @code{setf} method will allow
the programmatic update of this information.
Property names are compared as if by @code{EQL},
so use symbols or keywords or something.
@menu
* Pre-defined subclasses of component::
* Creating new component types::
@end menu
@node Pre-defined subclasses of component, Creating new component types, Common attributes of components, Components
@comment node-name, next, previous, up
@subsection Pre-defined subclasses of component
@deftp Component source-file
A source file is any file that the system does not know how to
generate from other components of the system.
Note that this is not necessarily the same thing as
``a file containing data that is typically fed to a compiler''.
If a file is generated by some pre-processor stage
(e.g. a @file{.h} file from @file{.h.in} by autoconf)
then it is not, by this definition, a source file.
Conversely, we might have a graphic file
that cannot be automatically regenerated,
or a proprietary shared library that we received as a binary:
these do count as source files for our purposes.
Subclasses of source-file exist for various languages.
@emph{FIXME: describe these.}
@end deftp
@deftp Component module
A module is a collection of sub-components.
A module component has the following extra initargs:
@itemize
@item
@code{:components} the components contained in this module
@item
@code{:default-component-class}
All children components which don't specify their class explicitly
are inferred to be of this type.
@item
@code{:if-component-dep-fails}
This attribute was removed in ASDF 3. Do not use it.
Use @code{:if-feature} instead (@pxref{required-features}, and @pxref{if-feature option}).
@item
@code{:serial} When this attribute is set,
each subcomponent of this component is assumed to depend on all subcomponents
before it in the list given to @code{:components}, i.e.
all of them are loaded before a compile or load operation is performed on it.
@end itemize
The default operation knows how to traverse a module, so
most operations will not need to provide methods specialised on modules.
@code{module} may be subclassed to represent components such as
foreign-language linked libraries or archive files.
@end deftp
@deftp Component system
@code{system} is a subclass of @code{module}.
A system is a module with a few extra attributes for documentation
purposes; these are given elsewhere.
@xref{The defsystem grammar}.
Users can create new classes for their systems:
the default @code{defsystem} macro takes a @code{:class} keyword argument.
@end deftp
@node Creating new component types, , Pre-defined subclasses of component, Components
@comment node-name, next, previous, up
@subsection Creating new component types
New component types are defined by subclassing one of the existing
component classes and specializing methods on the new component class.
@c FIXME: this should perhaps be explained more thoroughly,
@c not only by example ...
As an example, suppose we have some implementation-dependent
functionality that we want to isolate
in one subdirectory per Lisp implementation our system supports.
We create a subclass of
@code{cl-source-file}:
@lisp
(defclass unportable-cl-source-file (cl-source-file)
())
@end lisp
Function @code{asdf:implementation-type} (exported since 2.014.14)
gives us the name of the subdirectory.
All that's left is to define how to calculate the pathname
of an @code{unportable-cl-source-file}.
@lisp
(defmethod component-pathname ((component unportable-cl-source-file))
(merge-pathnames*
(parse-unix-namestring (format nil "~(~A~)/" (asdf:implementation-type)))
(call-next-method)))
@end lisp
The new component type is used in a @code{defsystem} form in this way:
@lisp
(defsystem :foo
:components
((:file "packages")
...
(:unportable-cl-source-file "threads"
:depends-on ("packages" ...))
...
)
@end lisp
@node Dependencies, Functions, Components, The object model of ASDF
@section Dependencies
@c FIXME: Moved this material here, but it isn't very comfortable
@c here.... Also needs to be revised to be coherent.
To be successfully build-able, this graph of actions must be acyclic.
If, as a user, extender or implementer of ASDF, you introduce
a cycle into the dependency graph,
ASDF will fail loudly.
To clearly distinguish the direction of dependencies,
ASDF 3 uses the words @emph{requiring} and @emph{required}
as applied to an action depending on the other:
the requiring action @code{depends-on} the completion of all required actions
before it may itself be @code{perform}ed.
Using the @code{defsystem} syntax, users may easily express
direct dependencies along the graph of the object hierarchy:
between a component and its parent, its children, and its siblings.
By defining custom CLOS methods, you can express more elaborate dependencies as you wish.
Most common operations, such as @code{load-op}, @code{compile-op} or @code{load-source-op}
are automatically propagate ``downward'' the component hierarchy and are ``covariant'' with it:
to act the operation on the parent module, you must first act it on all the children components,
with the action on the parent being parent of the action on each child.
Other operations, such as @code{prepare-op} and @code{prepare-source-op}
(introduced in ASDF 3) are automatically propagated ``upward'' the component hierarchy
and are ``contravariant'' with it:
to perform the operation of preparing for compilation of a child component,
you must perform the operation of preparing for compilation of its parent component, and so on,
ensuring that all the parent's dependencies are (compiled and) loaded
before the child component may be compiled and loaded.
Yet other operations, such as @code{test-op} or @code{load-bundle-op}
remain at the system level, and are not propagated along the hierarchy,
but instead do something global on the system.
@node Functions, , Dependencies, The object model of ASDF
@comment node-name, next, previous, up
@section Functions
@c FIXME: this does not belong here....
@defun version-satisfies @var{version} @var{version-spec}
Does @var{version} satisfy the @var{version-spec}. A generic function.
ASDF provides built-in methods for @var{version} being a @code{component} or @code{string}.
@var{version-spec} should be a string.
If it's a component, its version is extracted as a string before further processing.
A version string satisfies the version-spec if after parsing,
the former is no older than the latter.
Therefore @code{"1.9.1"}, @code{"1.9.2"} and @code{"1.10"} all satisfy @code{"1.9.1"},
but @code{"1.8.4"} or @code{"1.9"} do not.
For more information about how @code{version-satisfies} parses and interprets
version strings and specifications,
@pxref{Version specifiers} and
@ref{Common attributes of components}.
Note that in versions of ASDF prior to 3.0.1,
including the entire ASDF 1 and ASDF 2 series,
@code{version-satisfies} would also require that the version and the version-spec
have the same major version number (the first integer in the list);
if the major version differed, the version would be considered as not matching the spec.
But that feature was not documented, therefore presumably not relied upon,
whereas it was a nuisance to several users.
Starting with ASDF 3.0.1,
@code{version-satisfies} does not treat the major version number specially,
and returns T simply if the first argument designates a version that isn't older
than the one specified as a second argument.
If needs be, the @code{(:version ...)} syntax for specifying dependencies
could be in the future extended to specify an exclusive upper bound for compatible versions
as well as an inclusive lower bound.
@end defun
@node Controlling where ASDF searches for systems, Controlling where ASDF saves compiled files, The object model of ASDF, Top
@comment node-name, next, previous, up
@chapter Controlling where ASDF searches for systems
@menu
* Configurations::
* Truenames and other dangers::
* XDG base directory::
* Backward Compatibility::
* Configuration DSL::
* Configuration Directories::
* Shell-friendly syntax for configuration::
* Search Algorithm::
* Caching Results::
* Configuration API::
* Introspection::
* Status::
* Rejected ideas::
* TODO::
* Credits for the source-registry::
@end menu
@node Configurations, Truenames and other dangers, Controlling where ASDF searches for systems, Controlling where ASDF searches for systems
@section Configurations
Configurations specify paths where to find system files.
@enumerate
@item
The search registry may use some hardcoded wrapping registry specification.
This allows some implementations (notably SBCL) to specify where to find
some special implementation-provided systems that
need to precisely match the version of the implementation itself.
@item
An application may explicitly initialize the source-registry configuration
using the configuration API
(@pxref{Controlling where ASDF searches for systems,Configuration API,Configuration API}, below)
in which case this takes precedence.
It may itself compute this configuration from the command-line,
from a script, from its own configuration file, etc.
@item
The source registry will be configured from
the environment variable @code{CL_SOURCE_REGISTRY} if it exists.
@item
The source registry will be configured from
user configuration file
@file{$XDG_CONFIG_DIRS/common-lisp/source-registry.conf}
(which defaults to
@file{~/.config/common-lisp/source-registry.conf})
if it exists.
@item
The source registry will be configured from
user configuration directory
@file{$XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/}
(which defaults to
@file{~/.config/common-lisp/source-registry.conf.d/})
if it exists.
@item
The source registry will be configured from
default user configuration trees
@file{~/common-lisp/} (since ASDF 3.1.2 only),
@file{~/.sbcl/systems/} (on SBCL only),
@file{$XDG_DATA_HOME/common-lisp/systems/} (no recursion, link farm)
@file{$XDG_DATA_HOME/common-lisp/source/}.
The @code{XDG_DATA_HOME} directory defaults to @file{~/.local/share/}.
On Windows, the @code{local-appdata} and @code{appdata} directories are used instead.
@item
The source registry will be configured from
system configuration file
@file{/etc/common-lisp/source-registry.conf}
if it exists.
@item
The source registry will be configured from
system configuration directory
@file{/etc/common-lisp/source-registry.conf.d/}
if it exists.
@item
The source registry will be configured from a default configuration.
This configuration may allow for implementation-specific systems
to be found, for systems to be found the current directory
(at the time that the configuration is initialized) as well as
@code{:directory} entries for @file{$XDG_DATA_DIRS/common-lisp/systems/} and
@code{:tree} entries for @file{$XDG_DATA_DIRS/common-lisp/source/},
where @code{XDG_DATA_DIRS} defaults to @file{/usr/local/share} and @file{/usr/share} on Unix,
and the @code{common-appdata} directory on Windows.
@item
The source registry may include implementation-dependent directories
that correspond to implementation-provided extensions.
@end enumerate
Each of these configurations is specified as an s-expression
in a trivial domain-specific language (defined below).
Additionally, a more shell-friendly syntax is available
for the environment variable (defined yet below).
Each of these configurations is only used if the previous
configuration explicitly or implicitly specifies that it
includes its inherited configuration.
Additionally, some implementation-specific directories
may be automatically prepended to whatever directories are specified
in configuration files, no matter if the last one inherits or not.
@node Truenames and other dangers, XDG base directory, Configurations, Controlling where ASDF searches for systems
@section Truenames and other dangers
One great innovation of the original ASDF was its ability to leverage
@code{CL:TRUENAME} to locate where your source code was and where to build it,
allowing for symlink farms as a simple but effective configuration mechanism
that is easy to control programmatically.
ASDF 3 still supports this configuration style, and it is enabled by default;
however we recommend you instead use
our source-registry configuration mechanism described below,
because it is easier to setup in a portable way across users and implementations.
Additionally, some people dislike truename,
either because it is very slow on their system, or
because they are using content-addressed storage where the truename of a file
is related to a digest of its individual contents,
and not to other files in the same intended project.
For these people, ASDF 3 allows to eschew the @code{TRUENAME} mechanism,
by setting the variable @var{asdf:*resolve-symlinks*} to @code{nil}.
PS: Yes, if you haven't read Vernor Vinge's short but great classic
``True Names... and Other Dangers'' then you're in for a treat.
@node XDG base directory, Backward Compatibility, Truenames and other dangers, Controlling where ASDF searches for systems
@section XDG base directory
Note that we purport to respect the XDG base directory specification
as to where configuration files are located,
where data files are located,
where output file caches are located.
Mentions of XDG variables refer to that document.
@url{http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html}
This specification allows the user to specify some environment variables
to customize how applications behave to his preferences.
On Windows platforms, even when not using Cygwin, and starting with ASDF 3.1.5,
we still do a best effort at following the XDG base directory specification,
even though it doesn't exactly fit common practice for Windows applications.
However, we replace the fixed Unix paths @file{~/.local}, @file{/usr/local} and @file{/usr}
with their rough Windows equivalent @file{Local AppData}, @file{AppData}, @file{Common AppData}, etc.
Since support for querying the Windows registry
is not possible to do in reasonable amounts of portable Common Lisp code,
ASDF 3 relies on the environment variables that Windows usually exports,
and are hopefully in synch with the Windows registry.
If you care about the details, see @file{uiop/configuration.lisp} and don't hesitate to suggest improvements.
@node Backward Compatibility, Configuration DSL, XDG base directory, Controlling where ASDF searches for systems
@section Backward Compatibility
For backward compatibility as well as to provide a practical backdoor for hackers,
ASDF will first search for @file{.asd} files in the directories specified in
@code{asdf:*central-registry*}
before it searches in the source registry above.
@xref{Configuring ASDF,,Configuring ASDF to find your systems --- old style}.
By default, @code{asdf:*central-registry*} will be empty.
This old mechanism will therefore not affect you if you don't use it,
but will take precedence over the new mechanism if you do use it.
@node Configuration DSL, Configuration Directories, Backward Compatibility, Controlling where ASDF searches for systems
@section Configuration DSL
@cindex :inherit-configuration source config directive
@cindex inherit-configuration source config directive
@cindex :ignore-invalid-entries source config directive
@cindex ignore-invalid-entries source config directive
@cindex :directory source config directive
@cindex directory source config directive
@cindex :tree source config directive
@cindex tree source config directive
@cindex :exclude source config directive
@cindex exclude source config directive
@cindex :also-exclude source config directive
@cindex also-exclude source config directive
@cindex :include source config directive
@cindex include source config directive
@cindex :default-registry source config directive
@cindex default-registry source config directive
Here is the grammar of the s-expression (SEXP) DSL for source-registry
configuration:
@c FIXME: This is too wide for happy compilation into pdf.
@example
;; A configuration is a single SEXP starting with the keyword
;; :source-registry followed by a list of directives.
CONFIGURATION := (:source-registry DIRECTIVE ...)
;; A directive is one of the following:
DIRECTIVE :=
;; INHERITANCE DIRECTIVE:
;; Your configuration expression MUST contain
;; exactly one of the following:
:inherit-configuration |
;; splices inherited configuration (often specified last) or
:ignore-inherited-configuration |
;; drop inherited configuration (specified anywhere)
;; forward compatibility directive (since ASDF 2.011.4), useful when
;; you want to use new configuration features but have to bootstrap
;; the newer required ASDF from an older release that doesn't
;; support said features:
:ignore-invalid-entries |
;; add a single directory to be scanned (no recursion)
(:directory DIRECTORY-PATHNAME-DESIGNATOR) |
;; add a directory hierarchy, recursing but
;; excluding specified patterns
(:tree DIRECTORY-PATHNAME-DESIGNATOR) |
;; override the defaults for exclusion patterns
(:exclude EXCLUSION-PATTERN ...) |
;; augment the defaults for exclusion patterns
(:also-exclude EXCLUSION-PATTERN ...) |
;; Note that the scope of a an exclude pattern specification is
;; the rest of the current configuration expression or file.
;; splice the parsed contents of another config file
(:include REGULAR-FILE-PATHNAME-DESIGNATOR) |
;; This directive specifies that some default must be spliced.
:default-registry
REGULAR-FILE-PATHNAME-DESIGNATOR
:= PATHNAME-DESIGNATOR ; interpreted as a file
DIRECTORY-PATHNAME-DESIGNATOR
:= PATHNAME-DESIGNATOR ; interpreted as a directory
PATHNAME-DESIGNATOR :=
NIL | ;; Special: skip this entry.
ABSOLUTE-COMPONENT-DESIGNATOR ;; see pathname DSL
EXCLUSION-PATTERN := a string without wildcards, that will be matched
exactly against the name of a any subdirectory in the directory
component of a path. e.g. @code{"_darcs"} will match
@file{#p"/foo/bar/_darcs/src/bar.asd"}
@end example
Pathnames are designated using another DSL,
shared with the output-translations configuration DSL below.
The DSL is resolved by the function @code{asdf::resolve-location},
to be documented and exported at some point in the future.
@example
ABSOLUTE-COMPONENT-DESIGNATOR :=
(ABSOLUTE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
STRING |
;; namestring (better be absolute or bust, directory assumed where
;; applicable). In output-translations, directory is assumed and
;; **/*.*.* added if it's last. On MCL, a MacOSX-style POSIX
;; namestring (for MacOS9 style, use #p"..."); Note that none of the
;; above applies to strings used in *central-registry*, which
;; doesn't use this DSL: they are processed as normal namestrings.
;; however, you can compute what you put in the *central-registry*
;; based on the results of say
;; (asdf::resolve-location "/Users/fare/cl/cl-foo/")
PATHNAME |
;; pathname (better be an absolute path, or bust)
;; In output-translations, unless followed by relative components,
;; it better have appropriate wildcards, as in **/*.*.*
:HOME | ; designates the user-homedir-pathname ~/
:USER-CACHE | ; designates the default location for the user cache
:HERE |
;; designates the location of the configuration file
;; (or *default-pathname-defaults*, if invoked interactively)
:ROOT
;; magic, for output-translations source only: paths that are relative
;; to the root of the source host and device
They keyword :SYSTEM-CACHE is not accepted in ASDF 3.1 and beyond: it
was a security hazard.
RELATIVE-COMPONENT-DESIGNATOR :=
(RELATIVE-COMPONENT-DESIGNATOR RELATIVE-COMPONENT-DESIGNATOR ...) |
STRING |
;; relative directory pathname as interpreted by
;; parse-unix-namestring.
;; In output translations, if last component, **/*.*.* is added
PATHNAME | ; pathname; unless last component, directory is assumed.
:IMPLEMENTATION |
;; directory based on implementation, e.g. sbcl-1.0.45-linux-x64
:IMPLEMENTATION-TYPE |
;; a directory based on lisp-implementation-type only, e.g. sbcl
:DEFAULT-DIRECTORY |
;; a relativized version of the default directory
:*/ | ;; any direct subdirectory (since ASDF 2.011.4)
:**/ | ;; any recursively inferior subdirectory (since ASDF 2.011.4)
:*.*.* | ;; any file (since ASDF 2.011.4)
The keywords :UID and :USERNAME are no longer supported.
@end example
For instance, as a simple case, my @file{~/.config/common-lisp/source-registry.conf},
which is the default place ASDF looks for this configuration, once contained:
@example
(:source-registry
(:tree (:home "cl")) ;; will expand to e.g. "/home/joeluser/cl/"
:inherit-configuration)
@end example
@node Configuration Directories, Shell-friendly syntax for configuration, Configuration DSL, Controlling where ASDF searches for systems
@section Configuration Directories
Configuration directories consist in files each containing
a list of directives without any enclosing @code{(:source-registry ...)} form.
The files will be sorted by namestring as if by @code{string<} and
the lists of directives of these files with be concatenated in order.
An implicit @code{:inherit-configuration} will be included
at the @emph{end} of the list.
System-wide or per-user Common Lisp software distributions
such as Debian packages or some future version of @code{clbuild}
may then include files such as
@file{/etc/common-lisp/source-registry.conf.d/10-foo.conf} or
@file{~/.config/common-lisp/source-registry.conf.d/10-foo.conf}
to easily and modularly register configuration information
about software being distributed.
The convention is that, for sorting purposes,
the names of files in such a directory begin with two digits
that determine the order in which these entries will be read.
Also, the type of these files must be @file{.conf},
which not only simplifies the implementation by allowing
for more portable techniques in finding those files,
but also makes it trivial to disable a file, by renaming it to a different file type.
Directories may be included by specifying a directory pathname
or namestring in an @code{:include} directive, e.g.:
@example
(:include "/foo/bar/")
@end example
Hence, to achieve the same effect as
my example @file{~/.config/common-lisp/source-registry.conf} above,
I could simply create a file
@file{~/.config/common-lisp/source-registry.conf.d/33-home-fare-cl.conf}
alone in its directory with the following contents:
@example
(:tree "/home/fare/cl/")
@end example
@menu
* The here directive::
@end menu
@node The here directive, , Configuration Directories, Configuration Directories
@subsection The :here directive
The @code{:here} directive is an absolute pathname designator that
refers to the directory containing the configuration file currently
being processed.
The @code{:here} directive is intended to simplify the delivery of
complex CL systems, and for easy configuration of projects shared through
revision control systems, in accordance with our design principle that
each participant should be able to provide all and only the information
available to him or her.
Consider a person X who has set up the source code repository for a
complex project with a master directory @file{dir/}. Ordinarily, one
might simply have the user add a directive that would look something
like this:
@example
(:tree "path/to/dir")
@end example
But what if X knows that there are very large subtrees
under dir that are filled with, e.g., Java source code, image files for
icons, etc.? All of the asdf system definitions are contained in the
subdirectories @file{dir/src/lisp/} and @file{dir/extlib/lisp/}, and
these are the only directories that should be searched.
In this case, X can put into @file{dir/} a file @file{asdf.conf} that
contains the following:
@example
(:source-registry
(:tree (:here "src/lisp/"))
(:tree (:here "extlib/lisp"))
(:directory (:here "outlier/")))
@end example
Then when someone else (call her Y) checks out a copy of this
repository, she need only add
@example
(:include "/path/to/my/checkout/directory/asdf.conf")
@end example
to one of her previously-existing asdf source location configuration
files, or invoke @code{initialize-source-registry} with a configuration
form containing that s-expression. ASDF will find the .conf file that X
has provided, and then set up source locations within the working
directory according to X's (relative) instructions.
@node Shell-friendly syntax for configuration, Search Algorithm, Configuration Directories, Controlling where ASDF searches for systems
@section Shell-friendly syntax for configuration
When considering environment variable @code{CL_SOURCE_REGISTRY}
ASDF will skip to next configuration if it's an empty string.
It will @code{READ} the string as a SEXP in the DSL
if it begins with a paren @code{(},
otherwise it will be interpreted much like @code{TEXINPUTS},
as a list of paths, where
@itemize
@item paths are separated by a @code{:} (colon) on Unix platforms
(including cygwin), by a @code{;} (semicolon) on other platforms
(mainly, Windows).
@item each entry is a directory to add to the search path.
@item if the entry ends with a double slash @code{//} then it instead
indicates a tree in the subdirectories of which to recurse.
@item if the entry is the empty string (which may only appear once),
then it indicates that the inherited configuration should be spliced
there.
@end itemize
@node Search Algorithm, Caching Results, Shell-friendly syntax for configuration, Controlling where ASDF searches for systems
@section Search Algorithm
@vindex *default-source-registry-exclusions*
In case that isn't clear, the semantics of the configuration is that
when searching for a system of a given name,
directives are processed in order.
When looking in a directory, if the system is found, the search succeeds,
otherwise it continues.
When looking in a tree, if one system is found, the search succeeds.
If multiple systems are found, the consequences are unspecified:
the search may succeed with any of the found systems,
or an error may be raised.
ASDF 3.2.1 or later returns the pathname whose normalized directory component
has the shortest length (as a list), and breaks ties by choosing the system
with the smallest @code{unix-namestring} when compared with @code{string<}.
Earlier versions of ASDF return ASDF return the first system found,
which is implementation-dependent, and may or may not be the pathname
with the smallest @code{unix-namestring} when compared with @code{string<}.
XCVB raises an error.
If none is found, the search continues.
Exclude statements specify patterns of subdirectories
the systems from which to ignore.
Typically you don't want to use copies of files kept by such
version control systems as Darcs.
Exclude statements are not propagated to further included or inherited
configuration files or expressions;
instead the defaults are reset around every configuration statement
to the default defaults from @code{asdf::*default-source-registry-exclusions*}.
Include statements cause the search to recurse with the path specifications
from the file specified.
An inherit-configuration statement cause the search to recurse with the path
specifications from the next configuration
(@pxref{Configurations} above).
@node Caching Results, Configuration API, Search Algorithm, Controlling where ASDF searches for systems
@section Caching Results
The implementation is allowed to either eagerly compute the information
from the configurations and file system, or to lazily re-compute it
every time, or to cache any part of it as it goes.
In practice, the recommended @code{source-registry} eagerly collects and caches results
and you need to explicitly flush the cache for change to be taken into account,
whereas the old-style @code{*central-registry*} mechanism queries the filesystem every time.
To explicitly flush any information cached by the system
after a change was made in the filesystem, @xref{Configuration API},
and e.g. call @code{asdf:clear-source-registry}.
Starting with ASDF 3.1.4, you can also explicitly build a persistent cache
of the @file{.asd} files found under a tree:
when recursing into a directory declared by @code{:tree} and its transitive subdirectories,
if a file @file{.cl-source-registry.cache} exists containing a form
that is a list starting with @code{:source-registry-cache} followed by a list of strings,
as in @code{(:source-registry-cache @emph{"foo/bar.asd" "path/to/more.asd" ...})},
then the strings are assumed to be @code{unix-namestring}s designating
the available asd files under that tree, and the recursion otherwise stops.
The list can also be empty, allowing to stop a costly recursion in a huge directory tree.
To update such a cache after you install, update or remove source repositories,
you can run a script distributed with ASDF:
@code{tools/cl-source-registry-cache.lisp @emph{/path/to/directory}}.
To wholly invalidate the cache, you can
delete the file @file{.cl-source-registry.cache} in that directory.
In either case, for an existing Lisp process to see this change,
it needs to clear its own cache with e.g. @code{(asdf:clear-source-registry)}.
Developers may safely create a cache in their development tree,
and we recommend they do it at the top of their source tree if
it contains more than a small number of files and directories;
they only need update it when they create, remove or move @file{.asd} files.
Software distribution managers may also safely create such a cache,
but they must be careful to update it every time they install, update or remove
a software source repository or installation package.
Finally, advanced developers who juggle with a lot of code
in their @code{source-registry} may manually manage such a cache,
to allow for faster startup of Lisp programs.
This persistence cache can help you reduce startup latency.
For instance, on one machine with hundreds of source repositories,
such a cache shaves half a second at the startup
of every @code{#!/usr/bin/cl} script using SBCL, more on other implementations;
this makes a notable difference as to
their subjective interactivity and usability.
The speedup will only happen if the implementation-provided ASDF is recent enough
(3.1.3.7 or later); it is not enough for a recent ASDF upgrade to be present,
since the upgrade will itself be found but
after the old version has scanned the directories without heeding such a cache.
To upgrade the implementation-provided ASDF,
@pxref{Replacing your implementation's ASDF}.
@node Configuration API, Introspection, Caching Results, Controlling where ASDF searches for systems
@section Configuration API
The specified functions are exported from your build system's package.
Thus for ASDF the corresponding functions are in package ASDF,
and for XCVB the corresponding functions are in package XCVB.
@defun initialize-source-registry @Aoptional{} PARAMETER
will read the configuration and initialize all internal variables.
You may extend or override configuration
from the environment and configuration files
with the given @var{PARAMETER}, which can be
@code{nil} (no configuration override),
or a SEXP (in the SEXP DSL),
a string (as in the string DSL),
a pathname (of a file or directory with configuration),
or a symbol (fbound to function that when called returns one of the above).
@end defun
@defun clear-source-registry
undoes any source registry configuration
and clears any cache for the search algorithm.
You might want to call this function
(or better, @code{clear-configuration})
before you dump an image that would be resumed
with a different configuration,
and return an empty configuration.
Note that this does not include clearing information about
systems defined in the current image, only about
where to look for systems not yet defined.
@end defun
@defun ensure-source-registry @Aoptional{} PARAMETER
checks whether a source registry has been initialized.
If not, initialize it with the given @var{PARAMETER}.
@end defun
Every time you use ASDF's @code{find-system}, or
anything that uses it (such as @code{operate}, @code{load-system}, etc.),
@code{ensure-source-registry} is called with parameter @code{nil},
which the first time around causes your configuration to be read.
If you change a configuration file,
you need to explicitly @code{initialize-source-registry} again,
or maybe simply to @code{clear-source-registry} (or @code{clear-configuration})
which will cause the initialization to happen next time around.
@node Introspection, Status, Configuration API, Controlling where ASDF searches for systems
@section Introspection
@menu
* *source-registry-parameter* variable::
* Information about system dependencies::
@end menu
@node *source-registry-parameter* variable, Information about system dependencies, Introspection, Introspection
@subsection *source-registry-parameter* variable
@vindex *source-registry-parameter*
We have made available the variable @code{*source-registry-parameter*}
that can be used by code that wishes to introspect about the (past)
configuration of ASDF's source registry. @strong{This variable should
never be set!} It will be set as a side-effect of calling
@code{initialize-source-registry}; user code should treat it as
read-only.
@node Information about system dependencies, , *source-registry-parameter* variable, Introspection
@subsection Information about system dependencies
ASDF makes available three functions to read system interdependencies.
These are intended to aid programmers who wish to perform dependency
analyses.
@defun system-defsystem-depends-on system
@end defun
@defun system-depends-on system
@end defun
@defun system-weakly-depends-on system
Returns a list of names of systems that are weakly depended on by
@var{system}. Weakly depended on systems are optionally loaded only if
ASDF can find them; failure to find such systems does @emph{not} cause an
error in loading.
Note that the return value for @code{system-weakly-depends-on} is simpler
than the return values of the other two system dependency introspection
functions.
@end defun
@node Status, Rejected ideas, Introspection, Controlling where ASDF searches for systems
@section Status
This mechanism is vastly successful, and we have declared
that @code{asdf:*central-registry*} is not recommended anymore,
though we will continue to support it.
All hooks into implementation-specific search mechanisms
have been integrated in the @code{wrapping-source-registry}
that everyone uses implicitly.
@node Rejected ideas, TODO, Status, Controlling where ASDF searches for systems
@section Rejected ideas
Alternatives I (FRR) considered and rejected while developing ASDF 2 included:
@enumerate
@item Keep @code{asdf:*central-registry*} as the master with its current semantics,
and somehow the configuration parser expands the new configuration
language into a expanded series of directories of subdirectories to
lookup, pre-recursing through specified hierarchies. This is kludgy,
and leaves little space of future cleanups and extensions.
@item Keep @code{asdf:*central-registry*} as the master but extend its semantics
in completely new ways, so that new kinds of entries may be implemented
as a recursive search, etc. This seems somewhat backwards.
@item Completely remove @code{asdf:*central-registry*}
and break backwards compatibility.
Hopefully this will happen in a few years after everyone migrate to
a better ASDF and/or to XCVB, but it would be very bad to do it now.
@item Replace @code{asdf:*central-registry*} by a symbol-macro with appropriate magic
when you dereference it or setf it. Only the new variable with new
semantics is handled by the new search procedure.
Complex and still introduces subtle semantic issues.
@end enumerate
I've been suggested the below features, but have rejected them,
for the sake of keeping ASDF no more complex than strictly necessary.
@itemize
@item
More syntactic sugar: synonyms for the configuration directives, such as
@code{(:add-directory X)} for @code{(:directory X)}, or @code{(:add-directory-hierarchy X)}
or @code{(:add-directory X :recurse t)} for @code{(:tree X)}.
@item
The possibility to register individual files instead of directories.
@item
Integrate Xach Beane's tilde expander into the parser,
or something similar that is shell-friendly or shell-compatible.
I'd rather keep ASDF minimal. But maybe this precisely keeps it
minimal by removing the need for evaluated entries that ASDF has?
i.e. uses of @code{USER-HOMEDIR-PATHNAME} and @code{$SBCL_HOME}
Hopefully, these are already superseded by the @code{:default-registry}
@item
Using the shell-unfriendly syntax @code{/**} instead of TEXINPUTS-like @code{//} to specify recursion
down a filesystem tree in the environment variable.
It isn't that Lisp friendly either.
@end itemize
@node TODO, Credits for the source-registry, Rejected ideas, Controlling where ASDF searches for systems
@section TODO
@itemize
@item Add examples
@end itemize
@node Credits for the source-registry, , TODO, Controlling where ASDF searches for systems
@section Credits for the source-registry
Thanks a lot to Stelian Ionescu for the initial idea.
Thanks to Rommel Martinez for the initial implementation attempt.
All bad design ideas and implementation bugs are mine, not theirs.
But so are good design ideas and elegant implementation tricks.
--- Francois-Rene Rideau @email{fare@@tunes.org}, Mon, 22 Feb 2010 00:07:33 -0500
@node Controlling where ASDF saves compiled files, Error handling, Controlling where ASDF searches for systems, Top
@comment node-name, next, previous, up
@chapter Controlling where ASDF saves compiled files
@cindex asdf-output-translations
@vindex ASDF_OUTPUT_TRANSLATIONS
Each Common Lisp implementation has its own format
for compiled files or fasls.@footnote{``FASL'' is short for ``FASt Loading.''}
If you use multiple implementations
(or multiple versions of the same implementation),
you'll soon find your source directories
littered with various @file{fasl}s, @file{dfsl}s, @file{cfsl}s and so
on.
Worse yet, multiple implementations use the same file extension and
some implementations maintain the same file extension
while changing formats from version to version (or platform to
platform).
This can lead to many errors and much confusion
as you switch from one implementation to the next.
Finally, this requires write access to the source directory,
and therefore precludes sharing of a same source code directory between multiple users.
Since ASDF 2, ASDF includes the @code{asdf-output-translations} facility
to mitigate the problem.
@menu
* Output Configurations::
* Output Backward Compatibility::
* Output Configuration DSL::
* Output Configuration Directories::
* Output Shell-friendly syntax for configuration::
* Semantics of Output Translations::
* Output Caching Results::
* Output location API::
* Credits for output translations::
@end menu
@node Output Configurations, Output Backward Compatibility, Controlling where ASDF saves compiled files, Controlling where ASDF saves compiled files
@section Configurations
@c FIXME: Explain how configurations work: can't expect reader will have
@c looked at previous chapter. Probably cut and paste will do.
Configurations specify mappings from input locations to output locations.
Once again we rely on the XDG base directory specification for configuration.
@xref{Controlling where ASDF searches for systems,,XDG base directory}.
@enumerate
@item
Some hardcoded wrapping output translations configuration may be used.
This allows special output translations (or usually, invariant directories)
to be specified corresponding to the similar special entries in the source registry.
@item
An application may explicitly initialize the output-translations
configuration using the Configuration API
in which case this takes precedence.
(@pxref{Controlling where ASDF saves compiled files,,Configuration API}.)
It may itself compute this configuration from the command-line,
from a script, from its own configuration file, etc.
@item
The source registry will be configured from
the environment variable @code{ASDF_OUTPUT_TRANSLATIONS} if it exists.
@item
The source registry will be configured from
user configuration file
@file{$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf}
(which defaults to
@file{~/.config/common-lisp/asdf-output-translations.conf})
if it exists.
@item
The source registry will be configured from
user configuration directory
@file{$XDG_CONFIG_DIRS/common-lisp/asdf-output-translations.conf.d/}
(which defaults to
@file{~/.config/common-lisp/asdf-output-translations.conf.d/})
if it exists.
@item
The source registry will be configured from
system configuration file
@file{/etc/common-lisp/asdf-output-translations.conf}
if it exists.
@item
The source registry will be configured from
system configuration directory
@file{/etc/common-lisp/asdf-output-translations.conf.d/}
if it exists.
@end enumerate
Each of these configurations is specified as a SEXP
in a trivial domain-specific language (@pxref{Configuration DSL}).
Additionally, a more shell-friendly syntax is available
for the environment variable (@pxref{Shell-friendly syntax for configuration}).
When processing an entry in the above list of configuration methods,
ASDF will stop unless that entry
explicitly or implicitly specifies that it
includes its inherited configuration.
Note that by default, a per-user cache is used for output files.
This allows the seamless use of shared installations of software
between several users, and takes files out of the way of the developers
when they browse source code,
at the expense of taking a small toll when developers have to clean up
output files and find they need to get familiar with output-translations
first.@footnote{A @code{CLEAN-OP} would be a partial solution to this problem.}
@node Output Backward Compatibility, Output Configuration DSL, Output Configurations, Controlling where ASDF saves compiled files
@section Backward Compatibility
@cindex ASDF-BINARY-LOCATIONS compatibility
@c FIXME: Demote this section -- the typical reader doesn't care about
@c backwards compatibility.
We purposely do @emph{not} provide backward compatibility with earlier versions of
@code{ASDF-Binary-Locations} (8 Sept 2009),
@code{common-lisp-controller} (7.0) or
@code{cl-launch} (2.35),
each of which had similar general capabilities.
The APIs of these programs were not designed
for easy user configuration
through configuration files.
Recent versions of @code{common-lisp-controller} (7.2) and @code{cl-launch} (3.000)
use the new @code{asdf-output-translations} API as defined below.
@code{ASDF-Binary-Locations} is fully superseded and not to be used anymore.
This incompatibility shouldn't inconvenience many people.
Indeed, few people use and customize these packages;
these few people are experts who can trivially adapt to the new configuration.
Most people are not experts, could not properly configure these features
(except inasmuch as the default configuration of
@code{common-lisp-controller} and/or @code{cl-launch}
might have been doing the right thing for some users),
and yet will experience software that ``just works'',
as configured by the system distributor, or by default.
Nevertheless, if you are a fan of @code{ASDF-Binary-Locations},
we provide a limited emulation mode:
@defun enable-asdf-binary-locations-compatibility @Akey{} centralize-lisp-binaries default-toplevel-directory include-per-user-information map-all-source-files source-to-target-mappings
This function will initialize the new @code{asdf-output-translations} facility in a way
that emulates the behaviour of the old @code{ASDF-Binary-Locations} facility.
Where you would previously set global variables
@var{*centralize-lisp-binaries*},
@var{*default-toplevel-directory*},
@var{*include-per-user-information*},
@var{*map-all-source-files*} or @var{*source-to-target-mappings*}
you will now have to pass the same values as keyword arguments to this function.
Note however that as an extension the @code{:source-to-target-mappings} keyword argument
will accept any valid pathname designator for @code{asdf-output-translations}
instead of just strings and pathnames.
@end defun
If you insist, you can also keep using the old @code{ASDF-Binary-Locations}
(the one available as an extension to load of top of ASDF,
not the one built into a few old versions of ASDF),
but first you must disable @code{asdf-output-translations}
with @code{(asdf:disable-output-translations)},
or you might experience ``interesting'' issues.
Also, note that output translation is enabled by default.
To disable it, use @code{(asdf:disable-output-translations)}.
@node Output Configuration DSL, Output Configuration Directories, Output Backward Compatibility, Controlling where ASDF saves compiled files
@section Configuration DSL
Here is the grammar of the SEXP DSL
for @code{asdf-output-translations} configuration:
@verbatim
;; A configuration is single SEXP starting with keyword :source-registry
;; followed by a list of directives.
CONFIGURATION := (:output-translations DIRECTIVE ...)
;; A directive is one of the following:
DIRECTIVE :=
;; INHERITANCE DIRECTIVE:
;; Your configuration expression MUST contain
;; exactly one of either of these:
:inherit-configuration |
;; splices inherited configuration (often specified last)
:ignore-inherited-configuration |
;; drop inherited configuration (specified anywhere)
;; forward compatibility directive (since ASDF 2.011.4), useful when
;; you want to use new configuration features but have to bootstrap a
;; the newer required ASDF from an older release that doesn't have
;; said features:
:ignore-invalid-entries |
;; include a configuration file or directory
(:include PATHNAME-DESIGNATOR) |
;; enable global cache in ~/.common-lisp/cache/sbcl-1.0.45-linux-amd64/
;; or something.
:enable-user-cache |
;; Disable global cache. Map / to /
:disable-cache |
;; add a single directory to be scanned (no recursion)
(DIRECTORY-DESIGNATOR DIRECTORY-DESIGNATOR)
;; use a function to return the translation of a directory designator
(DIRECTORY-DESIGNATOR (:function TRANSLATION-FUNCTION))
DIRECTORY-DESIGNATOR :=
NIL | ; As source: skip this entry. As destination: same as source
T | ; as source matches anything, as destination
; maps pathname to itself.
ABSOLUTE-COMPONENT-DESIGNATOR ; same as in the source-registry language
TRANSLATION-FUNCTION :=
SYMBOL | ;; symbol naming a function that takes two arguments:
;; the pathname to be translated and the matching
;; DIRECTORY-DESIGNATOR
LAMBDA ;; A form which evaluates to a function taking two arguments:
;; the pathname to be translated and the matching
;; DIRECTORY-DESIGNATOR
@end verbatim
Relative components better be either relative
or subdirectories of the path before them, or bust.
@c FIXME: the following assumes that the reader is familiar with the use
@c of this pattern in logical pathnames, which may not be a reasonable
@c assumption. Expand.
The last component, if not a pathname, is notionally completed by @file{/**/*.*}.
You can specify more fine-grained patterns
by using a pathname object as the last component
e.g. @file{#p"some/path/**/foo*/bar-*.fasl"}
You may use @code{#+features} to customize the configuration file.
The second designator of a mapping may be @code{nil}, indicating that files are not mapped
to anything but themselves (same as if the second designator was the same as the first).
When the first designator is @code{t},
the mapping always matches.
When the first designator starts with @code{:root},
the mapping matches any host and device.
In either of these cases, if the second designator
isn't @code{t} and doesn't start with @code{:root},
then strings indicating the host and pathname are somehow copied
in the beginning of the directory component of the source pathname
before it is translated.
When the second designator is @code{t}, the mapping is the identity.
When the second designator starts with @code{:root},
the mapping preserves the host and device of the original pathname.
Notably, this allows you to map files
to a subdirectory of the whichever directory the file is in.
Though the syntax is not quite as easy to use as we'd like,
you can have an (source destination) mapping entry such as follows
in your configuration file,
or you may use @code{enable-asdf-binary-locations-compatibility}
with @code{:centralize-lisp-binaries nil}
which will do the same thing internally for you:
@lisp
#.(let ((wild-subdir
(make-pathname :directory '(:relative :wild-inferiors)))
(wild-file
(make-pathname :name :wild :version :wild :type :wild)))
`((:root ,wild-subdir ,wild-file)
(:root ,wild-subdir :implementation ,wild-file)))
@end lisp
Starting with ASDF 2.011.4, you can use the simpler:
@code{`(:root (:root :**/ :implementation :*.*.*))}
@code{:include} statements cause the search to recurse with the path specifications
from the file specified.
If the @code{translate-pathname} mechanism cannot achieve a desired
translation, the user may provide a function which provides the
required algorithm. Such a translation function is specified by
supplying a list as the second @code{directory-designator}
the first element of which is the keyword @code{:function},
and the second element of which is
either a symbol which designates a function or a lambda expression.
The function designated by the second argument must take two arguments,
the first being the pathname of the source file,
the second being the wildcard that was matched.
When invoked, the function should return the translated pathname.
An @code{:inherit-configuration} statement causes the search to recurse with the path
specifications from the next configuration in the bulleted list.
@xref{Controlling where ASDF saves compiled files,,Configurations}, above.
@vindex asdf::*user-cache*
@itemize
@item
@code{:enable-user-cache} is the same as @code{(t :user-cache)}.
@item
@code{:disable-cache} is the same as @code{(t t)}.
@item
@code{:user-cache} uses the contents of variable @code{asdf::*user-cache*}
which by default is the same as using
@code{(:home ".cache" "common-lisp" :implementation)}.
@end itemize
@node Output Configuration Directories, Output Shell-friendly syntax for configuration, Output Configuration DSL, Controlling where ASDF saves compiled files
@section Configuration Directories
Configuration directories consist of files, each of which contains
a list of directives without any enclosing
@code{(:output-translations ...)} form.
The files will be sorted by namestring as if by @code{string<} and
the lists of directives of these files with be concatenated in order.
An implicit @code{:inherit-configuration} will be included
at the @emph{end} of the list.
System-wide or per-user Common Lisp software distributions
such as Debian packages or some future version of @code{clbuild}
may then include files such as
@file{/etc/common-lisp/asdf-output-translations.conf.d/10-foo.conf} or
@file{~/.config/common-lisp/asdf-output-translations.conf.d/10-foo.conf}
to easily and modularly register configuration information
about software being distributed.
The convention is that, for sorting purposes,
the names of files in such a directory begin with two digits
that determine the order in which these entries will be read.
Also, the type of these files must be @file{.conf},
which not only simplifies the implementation by allowing
for more portable techniques in finding those files,
but also makes it trivial to disable a file, by renaming it to a different file type.
Directories may be included by specifying a directory pathname
or namestring in an @code{:include} directive, e.g.:
@verbatim
(:include "/foo/bar/")
@end verbatim
@node Output Shell-friendly syntax for configuration, Semantics of Output Translations, Output Configuration Directories, Controlling where ASDF saves compiled files
@section Shell-friendly syntax for configuration
When processing the environment variable
@code{ASDF_OUTPUT_TRANSLATIONS}:
@itemize
@item ASDF will skip to the next configuration if it's an empty string.
@item ASDF will @code{READ} the string as an SEXP in the DSL, if it
begins with a parenthesis @code{(}.
@item Otherwise ASDF will interpret the value as a list of directories
(see below).
@end itemize
In the directory list format,
directories should come in pairs, each pair indicating a mapping directive.
Entries are separated
by a @code{:} (colon) on Unix platforms (including Mac and cygwin), and
by a @code{;} (semicolon) on other platforms (mainly, Windows).
The magic empty entry,
if it comes in what would otherwise be the first entry in a pair,
indicates the splicing of inherited configuration;
the next entry (if any) then starts a new pair.
If the second entry in a pair is empty,
it indicates that the directory in the first entry is to be left untranslated
(which has the same effect as if the directory had been repeated).
For example, @code{"/foo:/bar::/baz:"} means:
specify that outputs for things under directory @file{/foo/}
are translated to be under @file{/bar/};
then include the inherited configuration;
then specify that outputs for things under directory @file{/baz/} are not translated.
@node Semantics of Output Translations, Output Caching Results, Output Shell-friendly syntax for configuration, Controlling where ASDF saves compiled files
@section Semantics of Output Translations
From the specified configuration,
a list of mappings is extracted in a straightforward way:
mappings are collected in order, recursing through
included or inherited configuration as specified.
To this list is prepended some implementation-specific mappings,
and is appended a global default.
The list is then compiled to a mapping table as follows:
for each entry, in order, resolve the first designated directory
into an actual directory pathname for source locations.
If no mapping was specified yet for that location,
resolve the second designated directory to an output location directory
add a mapping to the table mapping the source location to the output location,
and add another mapping from the output location to itself
(unless a mapping already exists for the output location).
Based on the table, a mapping function is defined,
mapping source pathnames to output pathnames:
given a source pathname, locate the longest matching prefix
in the source column of the mapping table.
Replace that prefix by the corresponding output column
in the same row of the table, and return the result.
If no match is found, return the source pathname.
(A global default mapping the filesystem root to itself
may ensure that there will always be a match,
with same fall-through semantics).
@node Output Caching Results, Output location API, Semantics of Output Translations, Controlling where ASDF saves compiled files
@section Caching Results
The implementation is allowed to either eagerly compute the information
from the configurations and file system, or to lazily re-compute it
every time, or to cache any part of it as it goes.
To explicitly flush any information cached by the system, use the API below.
@node Output location API, Credits for output translations, Output Caching Results, Controlling where ASDF saves compiled files
@section Output location API
The specified functions are exported from package ASDF.
@defun initialize-output-translations @Aoptional{} PARAMETER
will read the configuration and initialize all internal variables.
You may extend or override configuration
from the environment and configuration files
with the given @var{PARAMETER}, which can be
@code{nil} (no configuration override),
or a SEXP (in the SEXP DSL),
a string (as in the string DSL),
a pathname (of a file or directory with configuration),
or a symbol (fbound to function that when called returns one of the above).
@end defun
@defun disable-output-translations
will initialize output translations in a way
that maps every pathname to itself,
effectively disabling the output translation facility.
@end defun
@defun clear-output-translations
undoes any output translation configuration
and clears any cache for the mapping algorithm.
You might want to call this function
(or better, @code{clear-configuration})
before you dump an image that would be resumed
with a different configuration,
and return an empty configuration.
Note that this does not include clearing information about
systems defined in the current image, only about
where to look for systems not yet defined.
@end defun
@defun ensure-output-translations @Aoptional{} PARAMETER
checks whether output translations have been initialized.
If not, initialize them with the given @var{PARAMETER}.
This function will be called before any attempt to operate on a system.
@end defun
@defun apply-output-translations PATHNAME
Applies the configured output location translations to @var{PATHNAME}
(calls @code{ensure-output-translations} for the translations).
@end defun
Every time you use ASDF's @code{output-files}, or
anything that uses it (that may compile, such as @code{operate}, @code{perform}, etc.),
@code{ensure-output-translations} is called with parameter @code{nil},
which the first time around causes your configuration to be read.
If you change a configuration file,
you need to explicitly @code{initialize-output-translations} again,
or maybe @code{clear-output-translations} (or @code{clear-configuration}),
which will cause the initialization to happen next time around.
@node Credits for output translations, , Output location API, Controlling where ASDF saves compiled files
@section Credits for output translations
Thanks a lot to Peter van Eynde for @code{Common Lisp Controller}
and to Bjorn Lindberg and Gary King for @code{ASDF-Binary-Locations}.
All bad design ideas and implementation bugs are to mine, not theirs.
But so are good design ideas and elegant implementation tricks.
--- Francois-Rene Rideau @email{fare@@tunes.org}
@c @section Default locations
@c @findex output-files-for-system-and-operation
@c The default binary location for each Lisp implementation
@c is a subdirectory of each source directory.
@c To account for different Lisps, Operating Systems, Implementation versions,
@c and so on, ASDF borrows code from SLIME
@c to create reasonable custom directory names.
@c Here are some examples:
@c @itemize
@c @item
@c SBCL, version 1.0.45 on Mac OS X for Intel: @code{sbcl-1.0.45-darwin-x86}
@c @item
@c Franz Allegro, version 8.0, ANSI Common Lisp: @code{allegro-8.0a-macosx-x86}
@c @item
@c Franz Allegro, version 8.1, Modern (case sensitive) Common Lisp: @code{allegro-8.1m-macosx-x86}
@c @end itemize
@c By default, all output file pathnames will be relocated
@c to some thus-named subdirectory of @file{~/.cache/common-lisp/}.
@c See the document @file{README.asdf-output-translations}
@c for a full specification on how to configure @code{asdf-output-translations}.
@node Error handling, Miscellaneous additional functionality, Controlling where ASDF saves compiled files, Top
@comment node-name, next, previous, up
@chapter Error handling
@tindex system-definition-error
@tindex operation-error
@section ASDF errors
If ASDF detects an incorrect system definition, it will signal a generalised instance of
@code{system-definition-error}.
Operations may go wrong (for example when source files contain errors).
These are signalled using generalised instances of
@code{operation-error}.
@section Compilation error and warning handling
@vindex *compile-file-warnings-behaviour*
@vindex *compile-file-failure-behaviour*
ASDF checks for warnings and errors when a file is compiled.
The variables @var{*compile-file-warnings-behaviour*} and
@var{*compile-file-failure-behaviour*}
control the handling of any such events.
The valid values for these variables are
@code{:error}, @code{:warn}, and @code{:ignore}.
@node Miscellaneous additional functionality, Getting the latest version, Error handling, Top
@comment node-name, next, previous, up
@chapter Miscellaneous additional functionality
ASDF includes several additional features that are generally
useful for system definition and development.
@menu
* Controlling file compilation::
* Controlling source file character encoding::
* Miscellaneous Functions::
* Some Utility Functions::
@end menu
@node Controlling file compilation, Controlling source file character encoding, Miscellaneous additional functionality, Miscellaneous additional functionality
@section Controlling file compilation
@cindex :around-compile
@cindex around-compile keyword
@cindex compile-check keyword
@cindex :compile-check
@findex compile-file*
@c FIXME: Needs rewrite. Start with motivation -- why are we doing
@c this? (there is some, but it's buried). Also, all of a sudden in
@c the middle of the discussion we start talking about a "hook," which
@c is confusing.
When declaring a component (system, module, file),
you can specify a keyword argument @code{:around-compile function}.
If left unspecified (and therefore unbound),
the value will be inherited from the parent component if any,
or with a default of @code{nil}
if no value is specified in any transitive parent.
The argument must be either @code{nil}, an fbound symbol,
a lambda-expression (e.g. @code{(lambda (thunk) ...(funcall thunk ...) ...)})
a function object (e.g. using @code{#.#'} but that's discouraged
because it prevents the introspection done by e.g. asdf-dependency-grovel),
or a string that when @code{read} yields a symbol or a lambda-expression.
@code{nil} means the normal compile-file function will be called.
A non-nil value designates a function of one argument
that will be called with a function that will
invoke @code{compile-file*} with various arguments;
the around-compile hook may supply additional keyword arguments
to pass to that call to @code{compile-file*}.
One notable argument that is heeded by @code{compile-file*} is
@code{:compile-check},
a function called when the compilation was otherwise a success,
with the same arguments as @code{compile-file};
the function shall return true if the compilation
and its resulting compiled file respected all system-specific invariants,
and false (@code{nil}) if it broke any of those invariants;
it may issue warnings or errors before it returns @code{nil}.
(NB: The ability to pass such extra flags
is only available starting with ASDF 2.22.3.)
This feature is notably exercised by asdf-finalizers.
By using a string, you may reference
a function, symbol and/or package
that will only be created later during the build, but
isn't yet present at the time the defsystem form is evaluated.
However, if your entire system is using such a hook, you may have to
explicitly override the hook with @code{nil} for all the modules and files
that are compiled before the hook is defined.
Using this hook, you may achieve such effects as:
locally renaming packages,
binding @var{*readtables*} and other syntax-controlling variables,
handling warnings and other conditions,
proclaiming consistent optimization settings,
saving code coverage information,
maintaining meta-data about compilation timings,
setting gensym counters and PRNG seeds and other sources of non-determinism,
overriding the source-location and/or timestamping systems,
checking that some compile-time side-effects were properly balanced,
etc.
Note that there is no around-load hook. This is on purpose.
Some implementations such as ECL, GCL or MKCL link object files,
which allows for no such hook.
Other implementations allow for concatenating FASL files,
which doesn't allow for such a hook either.
We aim to discourage something that's not portable,
and has some dubious impact on performance and semantics
even when it is possible.
Things you might want to do with an around-load hook
are better done around-compile,
though it may at times require some creativity
(see e.g. the @code{package-renaming} system).
@node Controlling source file character encoding, Miscellaneous Functions, Controlling file compilation, Miscellaneous additional functionality
@section Controlling source file character encoding
Starting with ASDF 2.21, components accept a @code{:encoding} option
so authors may specify which character encoding should be used
to read and evaluate their source code.
When left unspecified, the encoding is inherited
from the parent module or system;
if no encoding is specified at any point,
or if @code{nil} is explicitly specified,
an extensible protocol described below is followed,
that ultimately defaults to @code{:utf-8} since ASDF 3.
The protocol to determine the encoding is
to call the function @code{detect-encoding},
which itself, if provided a valid file,
calls the function specified by @var{*encoding-detection-hook*},
or else defaults to the @var{*default-encoding*}.
The @var{*encoding-detection-hook*} is by default bound
to function @code{always-default-encoding},
that always returns the contents of @var{*default-encoding*}.
@var{*default-encoding*} is bound to @code{:utf-8} by default
(before ASDF 3, the default was @code{:default}).
Whichever encoding is returned must be a portable keyword,
that will be translated to an implementation-specific external-format designator
by function @code{encoding-external-format},
which itself simply calls the function specified @var{*encoding-external-format-hook*};
that function by default is @code{default-encoding-external-format},
that only recognizes @code{:utf-8} and @code{:default},
and translates the former to the implementation-dependent @var{*utf-8-external-format*},
and the latter to itself (that itself is portable but has an implementation-dependent meaning).
In other words, there now are plenty of extension hooks, but
by default ASDF enforces the previous @emph{de facto} standard behaviour
of using @code{:utf-8}, independently from
whatever configuration the user may be using.
Thus, system authors can now rely on @code{:utf-8}
being used while compiling their files,
even if the user is currently using @code{:koi8-r} or @code{:euc-jp}
as their interactive encoding.
(Before ASDF 3, there was no such guarantee, @code{:default} was used,
and only plain ASCII was safe to include in source code.)
Some legacy implementations only support 8-bit characters,
and some implementations provide 8-bit only variants.
On these implementations, the @var{*utf-8-external-format*}
gracefully falls back to @code{:default},
and Unicode characters will be read as multi-character mojibake.
To detect such situations, UIOP will push the @code{:asdf-unicode} feature
on implementations that support Unicode, and you can use reader-conditionalization
to protect any @code{:encoding @emph{encoding}} statement, as in
@code{#+asdf-unicode :encoding #+asdf-unicode :utf-8}.
We recommend that you avoid using unprotected @code{:encoding} specifications
until after ASDF 2.21 or later becomes widespread.
As of May 2016, all maintained implementations provide ASDF 3.1,
so you may prudently start using this and other features without such protection.
While it offers plenty of hooks for extension,
and one such extension is available (see @code{asdf-encodings} below),
ASDF itself only recognizes one encoding beside @code{:default},
and that is @code{:utf-8}, which is the @emph{de facto} standard,
already used by the vast majority of libraries that use more than ASCII.
On implementations that do not support unicode,
the feature @code{:asdf-unicode} is absent, and
the @code{:default} external-format is used
to read even source files declared as @code{:utf-8}.
On these implementations, non-ASCII characters
intended to be read as one CL character
may thus end up being read as multiple CL characters.
In most cases, this shouldn't affect the software's semantics:
comments will be skipped just the same, strings with be read and printed
with slightly different lengths, symbol names will be accordingly longer,
but none of it should matter.
But a few systems that actually depend on unicode characters
may fail to work properly, or may work in a subtly different way.
See for instance @code{lambda-reader}.
We invite you to embrace UTF-8
as the encoding for non-ASCII characters starting today,
even without any explicit specification in your @file{.asd} files.
Indeed, on some implementations and configurations,
UTF-8 is already the @code{:default},
and loading your code may cause errors if it is encoded in anything but UTF-8.
Therefore, even with the legacy behaviour,
non-UTF-8 is guaranteed to break for some users,
whereas UTF-8 is pretty much guaranteed not to break anywhere
(provided you do @emph{not} use a BOM),
although it might be read incorrectly on some implementations.
@code{:utf-8} has been the default value of @code{*default-encoding*} since ASDF 3.
If you need non-standard character encodings for your source code,
use the extension system @code{asdf-encodings}, by specifying
@code{:defsystem-depends-on ("asdf-encodings")} in your @code{defsystem}.
This extension system will register support for more encodings using the
@code{*encoding-external-format-hook*} facility,
so you can explicitly specify @code{:encoding :latin1}
in your @file{.asd} file.
Using the @code{*encoding-detection-hook*} it will also
eventually implement some autodetection of a file's encoding
from an emacs-style @code{-*- mode: lisp ; coding: latin1 -*-} declaration,
or otherwise based on an analysis of octet patterns in the file.
At this point, @code{asdf-encoding} only supports the encodings
that are supported as part of your implementation.
Since the list varies depending on implementations,
we still recommend you use @code{:utf-8} everywhere,
which is the most portable (next to it is @code{:latin1}).
Recent versions of Quicklisp include @code{asdf-encodings};
if you're not using it, you may get this extension using git:
@kbd{git clone https://gitlab.common-lisp.net/asdf/asdf-encodings.git}
or
@kbd{git clone git@@gitlab.common-lisp.net:asdf/asdf-encodings.git}.
You can also browse the repository on
@url{https://gitlab.common-lisp.net/asdf/asdf-encodings}.
When you use @code{asdf-encodings},
any @file{.asd} file loaded
will use the autodetection algorithm to determine its encoding.
If you depend on this detection happening,
you should explicitly load @code{asdf-encodings} early in your build.
Note that @code{:defsystem-depends-on} cannot be used here: by the time
the @code{:defsystem-depends-on} is loaded, the enclosing
@code{defsystem} form has already been read.
In practice, this means that the @code{*default-encoding*}
is usually used for @file{.asd} files.
Currently, this defaults to @code{:utf-8}, and
you should be safe using Unicode characters in those files.
This might matter, for instance, in meta-data about author's names.
Otherwise, the main data in these files is component (path)names,
and we don't recommend using non-ASCII characters for these,
for the result probably isn't very portable.
@node Miscellaneous Functions, Some Utility Functions, Controlling source file character encoding, Miscellaneous additional functionality
@section Miscellaneous Functions
These functions are exported by ASDF for your convenience.
@anchor{system-relative-pathname}
@defun system-relative-pathname system name @Akey{} type
It's often handy to locate a file relative to some system.
The @code{system-relative-pathname} function meets this need.
It takes two mandatory arguments @var{system} and @var{name}
and a keyword argument @var{type}:
@var{system} is name of a system, whereas @var{name} and optionally @var{type}
specify a relative pathname, interpreted like a component pathname specifier
by @code{coerce-pathname}. @xref{Pathname specifiers}.
It returns a pathname built from the location of the system's
source directory and the relative pathname. For example:
@lisp
> (asdf:system-relative-pathname 'cl-ppcre "regex.data")
#P"/repository/other/cl-ppcre/regex.data"
@end lisp
@end defun
@defun system-source-directory system-designator
ASDF does not provide a turnkey solution for locating
data (or other miscellaneous) files
that are distributed together with the source code of a system.
Programmers can use @code{system-source-directory} to find such files.
Returns a pathname object.
The @var{system-designator} may be a string, symbol, or ASDF system object.
@end defun
@defun clear-system system-designator
It is sometimes useful to force recompilation of a previously loaded system.
For these cases, @code{(asdf:clear-system :foo)}
will remove the system from the table of currently loaded systems:
the next time the system @code{foo} or one that depends on it is re-loaded,
@code{foo} will be loaded again.@footnote{Alternatively, you could touch @code{foo.asd} or
remove the corresponding fasls from the output file cache.}
Note that this does not and cannot undo
the previous loading of the system.
Common Lisp has no provision for such an operation,
and its reliance on irreversible side-effects to global data structures
makes such a thing impossible in the general case.
If the software being re-loaded is not conceived with hot upgrade in mind,
re-loading may cause many errors, warnings or subtle silent problems,
as packages, generic function signatures, structures, types, macros, constants, etc.
are being redefined incompatibly.
It is up to the user to make sure that reloading is possible and has the desired effect.
In some cases, extreme measures such as recursively deleting packages,
unregistering symbols, defining methods on @code{update-instance-for-redefined-class}
and much more are necessary for reloading to happen smoothly.
ASDF itself goes to extensive effort to make a hot upgrade possible
with respect to its own code.
If you want, you can reuse some of its utilities such as
@code{uiop:define-package} and @code{uiop:with-upgradability},
and get inspiration (or disinspiration)
from what it does in @file{header.lisp} and @file{upgrade.lisp}.
@end defun
@defun register-preloaded-system name @Arest{} keys @Akey{} version @AallowOtherKeys{}
A system with name @var{name},
created by @code{make-instance} with extra keys @var{keys}
(e.g. @code{:version}),
is registered as @emph{preloaded}.
If @var{version} is @code{t} (default), then the version is copied from the defined system
of the same name (if registered) or else is @code{nil}
(this automatic copy of version is only available starting since ASDF 3.1.8).
A preloaded system is considered as having already been loaded into the current image,
and if at some point some other system @code{:depends-on} it yet no source code is found,
it is considered as already provided,
and ASDF will not raise a @code{missing-component} error.
This function is particularly useful if you distribute your code
as fasls with either @code{compile-bundle-op} or @code{monolithic-compile-bundle-op},
and want to register systems so that dependencies will work uniformly
whether you're using your software from source or from fasl.
Note that if the system was already defined or loaded from source code,
its build information will remain active until you call @code{clear-system} on it,
at which point a system without build information will be registered in its place.
@end defun
@defun register-immutable-system name @Arest{} keys
A system with name @var{name} is registered as preloaded,
and additionally is marked as @emph{immutable}:
that is, attempts to compile or load it will be succeed
without actually reading, creating or loading any file,
as if the system was passed as a @code{force-not} argument
to all calls to @code{plan} or @code{operate}.
There will be no search for an updated @file{.asd} file
to override the loaded version,
whether from the source-register or any other method.
If a @var{version} keyword argument is specified as @code{t} or left unspecified,
then the version is copied from the defined system
of the same name (if registered) or else is @code{nil}.
This automatic copy of version is available starting
since immutable systems have been available in ASDF 3.1.5.
This function, available since ASDF 3.1.5, is particularly useful
if you distribute a large body of code as a precompiled image,
and want to allow users to extend the image with further extension systems,
but without making thousands of filesystem requests looking for inexistent
(or worse, out of date) source code
for all the systems that came bundled with the image but aren't
distributed as source code to regular users.
@cindex immutable systems
@end defun
@defun run-shell-command control-string @Arest{} args
This function is obsolete and present only for the sake of backwards-compatibility:
``If it's not backwards, it's not compatible''. We @emph{strongly} discourage its use.
Its current behaviour is only well-defined on Unix platforms
(which include MacOS X and cygwin). On Windows, anything goes.
The following documentation is only for the purpose of your migrating away from it
in a way that preserves semantics.
Instead we recommend the use @code{run-program}, described in the next section, and
available as part of ASDF since ASDF 3.
@code{run-shell-command} takes as arguments a format @code{control-string}
and arguments to be passed to @code{format} after this control-string
to produce a string.
This string is a command that will be evaluated with a POSIX shell if possible;
yet, on Windows, some implementations will use CMD.EXE,
while others (like SBCL) will make an attempt at invoking a POSIX shell
(and fail if it is not present).
@end defun
@node Some Utility Functions, , Miscellaneous Functions, Miscellaneous additional functionality
@section Some Utility Functions
The below functions are not exported by ASDF itself, but by UIOP, available since ASDF 3.
Some of them have precursors in ASDF 2, but we recommend that for active developments,
you should rely on the package UIOP as included in ASDF 3.
UIOP provides many, many more utility functions, and we recommend
you read its @file{README.md} and sources for more information.
@defun parse-unix-namestring name @Akey{} type defaults dot-dot ensure-directory @AallowOtherKeys
Coerce @var{name} into a @var{pathname} using standard Unix syntax.
Unix syntax is used whether or not the underlying system is Unix;
on non-Unix systems it is only usable for relative pathnames.
In order to manipulate relative pathnames portably, it is crucial
to possess a portable pathname syntax independent of the underlying OS.
This is what @code{parse-unix-namestring} provides, and why we use it in ASDF.
When given a @code{pathname} object, just return it untouched.
When given @code{nil}, just return @code{nil}.
When given a non-null @code{symbol}, first downcase its name and treat it as a string.
When given a @code{string}, portably decompose it into a pathname as below.
@code{#\/} separates directory components.
The last @code{#\/}-separated substring is interpreted as follows:
1- If @var{type} is @code{:directory} or @var{ensure-directory} is true,
the string is made the last directory component, and its @code{name} and @code{type} are @code{nil}.
if the string is empty, it's the empty pathname with all slots @code{nil}.
2- If @var{type} is @code{nil}, the substring is a file-namestring,
and its @code{name} and @code{type} are separated by @code{split-name-type}.
3- If @var{type} is a string, it is the given @code{type}, and the whole string is the @code{name}.
Directory components with an empty name the name @code{.} are removed.
Any directory named @code{..} is read as @var{dot-dot},
which must be one of @code{:back} or @code{:up} and defaults to @code{:back}.
@vindex *nil-pathname*
@code{host}, @code{device} and @code{version} components are taken from @var{defaults},
which itself defaults to @code{*nil-pathname*}.
@code{*nil-pathname*} is also used if @var{defaults} is @code{nil}.
No host or device can be specified in the string itself,
which makes it unsuitable for absolute pathnames outside Unix.
For relative pathnames, these components (and hence the defaults) won't matter
if you use @code{merge-pathnames*} but will matter if you use @code{merge-pathnames},
which is an important reason to always use @code{merge-pathnames*}.
Arbitrary keys are accepted, and the parse result is passed to @code{ensure-pathname}
with those keys, removing @var{type}, @var{defaults} and @var{dot-dot}.
When you're manipulating pathnames that are supposed to make sense portably
even though the OS may not be Unixish, we recommend you use @code{:want-relative t}
so that @code{parse-unix-namestring} will throw an error if the pathname is absolute.
@end defun
@defun merge-pathnames* specified @Aoptional{} defaults
This function is a replacement for @code{merge-pathnames} that uses the host and device
from the @var{defaults} rather than the @var{specified} pathname when the latter
is a relative pathname. This allows ASDF and its users to create and use relative pathnames
without having to know beforehand what are the host and device
of the absolute pathnames they are relative to.
@end defun
@defun subpathname pathname subpath @Akey{} type
This function takes a @var{pathname} and a @var{subpath} and a @var{type}.
If @var{subpath} is already a @code{pathname} object (not namestring),
and is an absolute pathname at that, it is returned unchanged;
otherwise, @var{subpath} is turned into a relative pathname with given @var{type}
as per @code{parse-unix-namestring} with @code{:want-relative t :type }@var{type},
then it is merged with the @code{pathname-directory-pathname} of @var{pathname},
as per @code{merge-pathnames*}.
We strongly encourage the use of this function
for portably resolving relative pathnames in your code base.
@end defun
@defun subpathname* pathname subpath @Akey{} type
This function returns @code{nil} if the base @var{pathname} is @code{nil},
otherwise acts like @code{subpathname}.
@end defun
@defun run-program command @Akey{} ignore-error-status force-shell input output @
error-output if-input-does-not-exist if-output-exists if-error-output-exists @
element-type external-format @AallowOtherKeys
@code{run-program} takes a @var{command} argument that is either
a list of a program name or path and its arguments,
or a string to be executed by a shell.
It spawns the command, waits for it to return,
verifies that it exited cleanly (unless told not too below),
and optionally captures and processes its output.
It accepts many keyword arguments to configure its behaviour.
@code{run-program} returns three values: the first for the output,
the second for the error-output, and the third for the return value.
(Beware that before ASDF 3.0.2.11, it didn't handle input or error-output,
and returned only one value,
the one for the output if any handler was specified, or else the exit code;
please upgrade ASDF, or at least UIOP, to rely on the new enhanced behaviour.)
@var{output} is its most important argument;
it specifies how the output is captured and processed.
If it is @code{nil}, then the output is redirected to the null device,
that will discard it.
If it is @code{:interactive}, then it is inherited from the current process
(beware: this may be different from your @var{*standard-output*},
and under SLIME will be on your @code{*inferior-lisp*} buffer).
If it is @code{t}, output goes to your current @var{*standard-output*} stream.
Otherwise, @var{output} should be a value that is a suitable first argument to
@code{slurp-input-stream} (see below), or
a list of such a value and keyword arguments.
In this case, @code{run-program} will
create a temporary stream for the program output;
the program output, in that stream,
will be processed by a call to @code{slurp-input-stream},
using @var{output} as the first argument
(or if it's a list the first element of @var{output} and the rest as keywords).
The primary value resulting from that call
(or @code{nil} if no call was needed)
will be the first value returned by @code{run-program}.
E.g., using @code{:output :string}
will have it return the entire output stream as a string.
And using @code{:output '(:string :stripped t)}
will have it return the same string stripped of any ending newline.
@var{error-output} is similar to @var{output}, except that
the resulting value is returned as the second value of @code{run-program}.
@code{t} designates the @var{*error-output*}.
Also @code{:output} means redirecting the error output to the output stream,
in which case @code{nil} is returned.
@var{input} is similar to @var{output}, except that
@code{vomit-output-stream} is used, no value is returned,
and @code{t} designates the @var{*standard-input*}.
@code{element-type} and @code{external-format} are passed on
to your Lisp implementation, when applicable, for creation of the output stream.
One and only one of the stream slurping or vomiting may or may not happen
in parallel in parallel with the subprocess,
depending on options and implementation,
and with priority being given to output processing.
Other streams are completely produced or consumed
before or after the subprocess is spawned, using temporary files.
@code{force-shell} forces evaluation of the command through a shell,
even if it was passed as a list rather than a string.
If a shell is used, it is @file{/bin/sh} on Unix or @file{CMD.EXE} on Windows,
except on implementations that (erroneously, IMNSHO)
insist on consulting @code{$SHELL} like clisp.
@code{ignore-error-status} causes @code{run-program}
to not raise an error if the spawned program exits in error.
Following POSIX convention, an error is anything but
a normal exit with status code zero.
By default, an error of type @code{subprocess-error} is raised in this case.
@code{run-program} works on all platforms supported by ASDF, except Genera.
See the source code for more documentation.
@end defun
@defun slurp-input-stream processor input-stream @Akey{}
@code{slurp-input-stream} is a generic function of two arguments, a target object and an input stream,
and accepting keyword arguments.
Predefined methods based on the target object are as follows:
@itemize
@item
If the object is a function, the function is called with the stream as argument.
@item If the object is a cons, its first element is applied to its rest appended by
a list of the input stream.
@item If the object is an output stream, the contents of the input stream are copied to it.
If the @var{linewise} keyword argument is provided, copying happens line by line,
and an optional @var{prefix} is printed before each line.
Otherwise, copying happen based on a buffer of size @var{buffer-size},
using the specified @var{element-type}.
@item If the object is @code{'string} or @code{:string}, the content is captured into a string.
Accepted keywords include the @var{element-type} and a flag @var{stripped},
which when true causes any single line ending to be removed as per @code{uiop:stripln}.
@item If the object is @code{:lines}, the content is captured as a list of strings,
one per line, without line ending. If the @var{count} keyword argument is provided,
it is a maximum count of lines to be read.
@item If the object is @code{:line}, the content is captured as with @code{:lines} above,
and then its sub-object is extracted with the @var{at} argument,
which defaults to @code{0}, extracting the first line.
A number will extract the corresponding line.
See the documentation for @code{uiop:access-at}.
@item If the object is @code{:forms}, the content is captured as a list of s-expressions,
as read by the Lisp reader.
If the @var{count} argument is provided,
it is a maximum count of lines to be read.
We recommend you control the syntax with such macro as
@code{uiop:with-safe-io-syntax}.
@item If the object is @code{:form}, the content is captured as with @code{:forms} above,
and then its sub-object is extracted with the @var{at} argument,
which defaults to @code{0}, extracting the first form.
A number will extract the corresponding form.
See the documentation for @code{uiop:access-at}.
We recommend you control the syntax with such macro as
@code{uiop:with-safe-io-syntax}.
@end itemize
@end defun
@node Getting the latest version, FAQ, Miscellaneous additional functionality, Top
@comment node-name, next, previous, up
@chapter Getting the latest version
Decide which version you want.
The @code{master} branch is where development happens;
its @code{HEAD} is usually OK, including the latest fixes and portability tweaks,
but an occasional regression may happen despite our (limited) test suite.
The @code{release} branch is what cautious people should be using;
it has usually been tested more, and releases are cut at a point
where there isn't any known unresolved issue.
You may get the ASDF source repository using git:
@kbd{git clone https://gitlab.common-lisp.net/asdf/asdf.git}
You will find the above referenced tags in this repository.
You can also browse the repository on
@url{https://gitlab.common-lisp.net/asdf/asdf}.
Discussion of ASDF development is conducted on the
mailing list (@pxref{Mailing list}).
@node FAQ, Ongoing Work, Getting the latest version, Top
@comment node-name, next, previous, up
@chapter FAQ
@menu
* Where do I report a bug?::
* Mailing list::
* What has changed between ASDF 1 ASDF 2 and ASDF 3?::
* Issues with installing the proper version of ASDF::
* Issues with configuring ASDF::
* Issues with using and extending ASDF to define systems::
* ASDF development FAQs::
@end menu
@node Where do I report a bug?, Mailing list, FAQ, FAQ
@section ``Where do I report a bug?''
@cindex bug tracker
@cindex gitlab
@cindex launchpad
ASDF bugs are tracked on common-lisp.net's gitlab:: @url{https://gitlab.common-lisp.net/asdf/asdf/issues}.
Previously, we had done bug-tracking on @code{launchpad.net}, but we are
now consolidating project management on @code{common-lisp.net}.
If you're unsure about whether something is a bug, or for general discussion,
use the asdf-devel mailing list (@pxref{Mailing list}).
@node Mailing list, What has changed between ASDF 1 ASDF 2 and ASDF 3?, Where do I report a bug?, FAQ
@section Mailing list
@cindex mailing list
Discussion of ASDF development is conducted on the
mailing list
@kbd{asdf-devel@@common-lisp.net}.
@url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel}
@node What has changed between ASDF 1 ASDF 2 and ASDF 3?, Issues with installing the proper version of ASDF, Mailing list, FAQ
@section ``What has changed between ASDF 1, ASDF 2, and ASDF 3?''
We released ASDF 2.000 on May 31st 2010,
ASDF 3.0.0 on May 15th 2013,
ASDF 3.1.2 on May 6th 2014.
Releases of ASDF 2 and now ASDF 3 have since then been included
in all actively maintained CL implementations that used to bundle ASDF 1,
plus many implementations that previously did not.
ASDF has been made to work with all actively maintained CL
implementations and even a few implementations that are @emph{not}
actively maintained.
Furthermore, it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly
(though we recommend instead upgrading your implementation or replacing its ASDF module).
For this reason, we have stopped supporting ASDF 1 and ASDF 2.
If you are using ASDF 1 or ASDF 2 and are experiencing any kind of issues or limitations,
we recommend you upgrade to ASDF 3
--- and we explain how to do that. @xref{Loading ASDF}.
Note that in the context of compatibility requirements,
ASDF 2.27, released on Feb 1st 2013, and further releases up to 2.33,
count as pre-releases of ASDF 3, and define the @code{:asdf3} feature,
though the first stable release of ASDF 3 was release 3.0.1.
Significant new or improved functionality were added in ASDF 3.1;
the @code{:asdf3.1} feature is present in recent enough versions to detect this functionality;
the first stable release since then was ASDF 3.1.2.
New @code{*features*} are only added at major milestones,
and the next one will probably be @code{:asdf3.2}.
@menu
* What are ASDF 1 2 3?::
* How do I detect the ASDF version?::
* ASDF can portably name files in subdirectories::
* Output translations::
* Source Registry Configuration::
* Usual operations are made easier to the user::
* Many bugs have been fixed::
* ASDF itself is versioned::
* ASDF can be upgraded::
* Decoupled release cycle::
* Pitfalls of the transition to ASDF 2::
* Pitfalls of the upgrade to ASDF 3::
* What happened to the bundle operations::
@end menu
@node What are ASDF 1 2 3?, How do I detect the ASDF version?, What has changed between ASDF 1 ASDF 2 and ASDF 3?, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection What are ASDF 1, ASDF 2, and ASDF 3?
ASDF 1 refers to any release earlier than 1.369 or so (from August 2001 to October 2009),
and to any development revision earlier than 2.000 (May 2010).
If your copy of ASDF doesn't even contain version information, it's an old ASDF 1.
Revisions between 1.656 and 1.728 may count as development releases for ASDF 2.
ASDF 2 refers to releases from 2.000 (May 31st 2010) to 2.26 (Oct 30th 2012),
and any development revision newer than ASDF 1 and older than 2.27 (Feb 1st 2013).
ASDF 3 refers to releases from 2.27 (Feb 1st 2013) to 2.33 and 3.0.0 onward (May 15th 2013).
2.27 to 2.33 count as pre-releases to ASDF 3.
ASDF 3.1 refers to releases from 3.1.2 (May 6th 2014) onward.
These releases are also considered part of ASDF 3.
@node How do I detect the ASDF version?, ASDF can portably name files in subdirectories, What are ASDF 1 2 3?, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection How do I detect the ASDF version?
@findex asdf-version
@cindex *features*
All releases of ASDF
push @code{:asdf} onto @code{*features*}.
Releases starting with ASDF 2
push @code{:asdf2} onto @code{*features*}.
Releases starting with ASDF 3 (including 2.27 and later pre-releases)
push @code{:asdf3} onto @code{*features*}.
Furthermore, releases starting with ASDF 3.1.2 (May 2014),
though they count as ASDF 3, include enough progress that they
also push @code{:asdf3.1} onto @code{*features*}.
You may depend on the presence or absence of these features
to write code that takes advantage of recent ASDF functionality
but still works on older versions, or at least detects the old version and signals an error.
Additionally, all releases starting with ASDF 2
define a function @code{(asdf:asdf-version)} you may use to query the version.
All releases starting with 2.013 display the version number prominently
on the second line of the @file{asdf.lisp} source file.
If you are experiencing problems or limitations of any sort with ASDF 1 or ASDF 2,
we recommend that you should upgrade to the latest release, be it ASDF 3 or other.
Finally, here is a code snippet to programmatically determine what version of ASDF is loaded, if any,
that works on all versions including very old ones:
@lisp
(when (find-package :asdf)
(let ((ver (symbol-value
(or (find-symbol (string :*asdf-version*) :asdf)
(find-symbol (string :*asdf-revision*) :asdf)))))
(etypecase ver
(string ver)
(cons (with-output-to-string (s)
(loop for (n . m) on ver
do (princ n s)
(when m (princ "." s)))))
(null "1.0"))))
@end lisp
If it returns @code{nil} then ASDF is not installed.
Otherwise it should return a string.
If it returns @code{"1.0"}, then it can actually be
any version before 1.77 or so, or some buggy variant of 1.x.
If it returns anything older than @code{"3.0.1"},
you really need to upgrade your implementation or at least upgrade its ASDF.
@xref{Replacing your implementation's ASDF}.
@node ASDF can portably name files in subdirectories, Output translations, How do I detect the ASDF version?, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection ASDF can portably name files in subdirectories
Common Lisp namestrings are not portable,
except maybe for logical pathname namestrings,
that themselves have various limitations and require a lot of setup
that is itself ultimately non-portable.
In ASDF 1, the only portable ways to refer to pathnames inside systems and components
were very awkward, using @code{#.(make-pathname ...)} and
@code{#.(merge-pathnames ...)}.
Even the above were themselves were inadequate in the general case
due to host and device issues, unless horribly complex patterns were used.
Plenty of simple cases that looked portable actually weren't,
leading to much confusion and greavance.
ASDF 2 implements its own portable syntax for strings as pathname specifiers.
Naming files within a system definition becomes easy and portable again.
@xref{Miscellaneous additional functionality,system-relative-pathname},
@code{merge-pathnames*},
@code{coerce-pathname}.
On the other hand, there are places where systems used to accept namestrings
where you must now use an explicit pathname object:
@code{(defsystem ... :pathname "LOGICAL-HOST:PATH;TO;SYSTEM;" ...)}
must now be written with the @code{#p} syntax:
@code{(defsystem ... :pathname #p"LOGICAL-HOST:PATH;TO;SYSTEM;" ...)}
@xref{Pathname specifiers}.
@node Output translations, Source Registry Configuration, ASDF can portably name files in subdirectories, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection Output translations
A popular feature added to ASDF was output pathname translation:
@code{asdf-binary-locations}, @code{common-lisp-controller},
@code{cl-launch} and other hacks were all implementing it in ways
both mutually incompatible and difficult to configure.
Output pathname translation is essential to share
source directories of portable systems across multiple implementations
or variants thereof,
or source directories of shared installations of systems across multiple users,
or combinations of the above.
In ASDF 2, a standard mechanism is provided for that,
@code{asdf-output-translations},
with sensible defaults, adequate configuration languages,
a coherent set of configuration files and hooks,
and support for non-Unix platforms.
@xref{Controlling where ASDF saves compiled files}.
@node Source Registry Configuration, Usual operations are made easier to the user, Output translations, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection Source Registry Configuration
Configuring ASDF used to require special magic
to be applied just at the right moment,
between the moment ASDF is loaded and the moment it is used,
in a way that is specific to the user,
the implementation he is using and the application he is building.
This made for awkward configuration files and startup scripts
that could not be shared between users, managed by administrators
or packaged by distributions.
ASDF 2 provides a well-documented way to configure ASDF,
with sensible defaults, adequate configuration languages,
and a coherent set of configuration files and hooks.
We believe it's a vast improvement because it decouples
application distribution from library distribution.
The application writer can avoid thinking where the libraries are,
and the library distributor (dpkg, clbuild, advanced user, etc.)
can configure them once and for every application.
Yet settings can be easily overridden where needed,
so whoever needs control has exactly as much as required.
At the same time, ASDF 2 remains compatible
with the old magic you may have in your build scripts
(using @code{*central-registry*} and
@code{*system-definition-search-functions*})
to tailor the ASDF configuration to your build automation needs,
and also allows for new magic, simpler and more powerful magic.
@xref{Controlling where ASDF searches for systems}.
@node Usual operations are made easier to the user, Many bugs have been fixed, Source Registry Configuration, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection Usual operations are made easier to the user
In ASDF 1, you had to use the awkward syntax
@code{(asdf:oos 'asdf:load-op :foo)}
to load a system,
and similarly for @code{compile-op}, @code{test-op}.
In ASDF 2, you can use shortcuts for the usual operations:
@code{(asdf:load-system :foo)}, and
similarly for @code{compile-system}, @code{test-system}.
@node Many bugs have been fixed, ASDF itself is versioned, Usual operations are made easier to the user, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection Many bugs have been fixed
The following issues and many others have been fixed:
@itemize
@item
The infamous TRAVERSE function has been revamped completely
between ASDF 1 and ASDF 2, with many bugs squashed.
In particular, dependencies were not correctly propagated
across modules but now are.
It has been completely rewritten many times over
between ASDF 2.000 and ASDF 3,
with fundamental issues in the original model being fixed.
Timestamps were not propagated at all, and now are.
The internal model of how actions depend on each other
is now both consistent and complete.
The @code{:version} and
the @code{:force (system1 .. systemN)} feature have been fixed.
@item
Performance has been notably improved for large systems
(say with thousands of components) by using
hash-tables instead of linear search,
and linear-time list accumulation instead of cubic time recursive append,
for an overall @emph{O(n)} complexity vs @emph{O(n^4)}.
@item
Many features used to not be portable,
especially where pathnames were involved.
Windows support was notably quirky because of such non-portability.
@item
The internal test suite used to massively fail on many implementations.
While still incomplete, it now fully passes
on all implementations supported by the test suite,
though some tests are commented out on a few implementations.
@item
Support was lacking for some implementations.
ABCL and GCL were notably wholly broken.
ECL extensions were not integrated with ASDF release.
@item
The documentation was grossly out of date.
@end itemize
@node ASDF itself is versioned, ASDF can be upgraded, Many bugs have been fixed, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection ASDF itself is versioned
Between new features, old bugs fixed, and new bugs introduced,
there were various releases of ASDF in the wild,
and no simple way to check which release had which feature set.
People using or writing systems had to either make worst-case assumptions
as to what features were available and worked,
or take great pains to have the correct version of ASDF installed.
With ASDF 2, we provide a new stable set of working features
that everyone can rely on from now on.
Use @code{#+asdf2} to detect presence of ASDF 2,
@code{(asdf:version-satisfies (asdf:asdf-version) "2.345.67")}
to check the availability of a version no earlier than required.
@node ASDF can be upgraded, Decoupled release cycle, ASDF itself is versioned, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection ASDF can be upgraded
When an old version of ASDF was loaded,
it was very hard to upgrade ASDF in your current image
without breaking everything.
Instead you had to exit the Lisp process and
somehow arrange to start a new one from a simpler image.
Something that can't be done from within Lisp,
making automation of it difficult,
which compounded with difficulty in configuration,
made the task quite hard.
Yet as we saw before, the task would have been required
to not have to live with the worst case or non-portable
subset of ASDF features.
With ASDF 2, it is easy to upgrade
from ASDF 2 to later versions from within Lisp,
and not too hard to upgrade from ASDF 1 to ASDF 2 from within Lisp.
We support hot upgrade of ASDF and any breakage is a bug
that we will do our best to fix.
There are still limitations on upgrade, though,
most notably the fact that after you upgrade ASDF,
you must also reload or upgrade all ASDF extensions.
@node Decoupled release cycle, Pitfalls of the transition to ASDF 2, ASDF can be upgraded, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection Decoupled release cycle
When vendors were releasing their Lisp implementations with ASDF,
they had to basically never change version
because neither upgrade nor downgrade was possible
without breaking something for someone,
and no obvious upgrade path was visible and recommendable.
With ASDF 2, upgrade is possible, easy and can be recommended.
This means that vendors can safely ship a recent version of ASDF,
confident that if a user isn't fully satisfied,
he can easily upgrade ASDF and deal
with a supported recent version of it.
This means that release cycles will be causally decoupled,
the practical consequence of which will mean faster convergence
towards the latest version for everyone.
@node Pitfalls of the transition to ASDF 2, Pitfalls of the upgrade to ASDF 3, Decoupled release cycle, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection Pitfalls of the transition to ASDF 2
The main pitfalls in upgrading to ASDF 2 seem to be related
to the output translation mechanism.
@itemize
@item
Output translations is enabled by default. This may surprise some users,
most of them in pleasant way (we hope), a few of them in an unpleasant way.
It is trivial to disable output translations.
@xref{FAQ,,``How can I wholly disable the compiler output cache?''}.
@item
Some systems in the large have been known
not to play well with output translations.
They were relatively easy to fix.
Once again, it is also easy to disable output translations,
or to override its configuration.
@item
The new ASDF output translations are incompatible with ASDF-Binary-Locations.
They replace A-B-L, and there is compatibility mode to emulate
your previous A-B-L configuration.
See @code{enable-asdf-binary-locations-compatibility} in
@pxref{Controlling where ASDF saves compiled files,,Backward Compatibility}.
But thou shalt not load ABL on top of ASDF 2.
@end itemize
Other issues include the following:
@itemize
@item
ASDF pathname designators are now specified
in places where they were unspecified,
and a few small adjustments have to be made to some non-portable defsystems.
Notably, in the @code{:pathname} argument
to a @code{defsystem} and its components,
a logical pathname (or implementation-dependent hierarchical pathname)
must now be specified with @code{#p} syntax
where the namestring might have previously sufficed;
moreover when evaluation is desired @code{#.} must be used,
where it wasn't necessary in the toplevel @code{:pathname} argument
(but necessary in other @code{:pathname} arguments).
@item
There is a slight performance bug, notably on SBCL,
when initially searching for @file{asd} files,
the implicit @code{(directory "/configured/path/**/*.asd")}
for every configured path @code{(:tree "/configured/path/")}
in your @code{source-registry} configuration can cause a slight pause.
Try to @code{(time (asdf:initialize-source-registry))}
to see how bad it is or isn't on your system.
If you insist on not having this pause,
you can avoid the pause by overriding the default source-registry configuration
and not use any deep @code{:tree} entry but only @code{:directory} entries
or shallow @code{:tree} entries.
Or you can fix your implementation to not be quite that slow
when recursing through directories.
@emph{Update}: This performance bug fixed the hard way in 2.010.
@item
On Windows, only LispWorks supports proper default configuration pathnames
based on the Windows registry.
Other implementations make do with environment variables,
that you may have to define yourself
if you're using an older version of Windows.
Windows support is somewhat less tested than Unix support.
Please help report and fix bugs.
@emph{Update}: As of ASDF 2.21, all implementations
should now use the same proper default configuration pathnames
and they should actually work, though they haven't all been tested.
@item
The mechanism by which one customizes a system so that Lisp files
may use a different extension from the default @file{.lisp} has changed.
Previously, the pathname for a component
was lazily computed when operating on a system,
and you would
@code{(defmethod source-file-type ((component cl-source-file) (system (eql (find-system 'foo))))
(declare (ignorable component system)) "lis")}.
Now, the pathname for a component is eagerly computed when defining the system,
and instead you will @code{(defclass cl-source-file.lis (cl-source-file) ((type :initform "lis")))}
and use @code{:default-component-class cl-source-file.lis}
as argument to @code{defsystem},
as detailed in a @pxref{FAQ,How do I create a system definition where all the source files have a .cl extension?} below.
@code{source-file-type} is deprecated. To access a component's
file-type, use @code{file-type}, instead. @code{source-file-type} will
be removed.
@findex source-file-type
@findex file-type
@end itemize
@node Pitfalls of the upgrade to ASDF 3, What happened to the bundle operations, Pitfalls of the transition to ASDF 2, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection Pitfalls of the upgrade to ASDF 3
While ASDF 3 is largely compatible with ASDF 2,
there are a few pitfalls when upgrading from ASDF 2,
due to limitations in ASDF 2.
@itemize
@item
ASDF 2 was designed so it could be upgraded;
but upgrading it required a special setup at the beginning of your build files.
Failure to upgrade it early could result in catastrophic attempt to self-upgrade in mid-build.
@item
Starting with ASDF 3 (2.27 or later),
ASDF will automatically attempt to upgrade itself
as the first step before any system operation,
to avoid any possibility of such catastrophic mid-build self-upgrade.
But that doesn't help if your old implementation still provides ASDF 2.
@item
It was unsafe in ASDF 2 for a system definition to declare a dependency on ASDF,
since it could trigger such catastrophe for users who were not carefully configured.
If you declare a dependency on a recent enough ASDF,
yet want to be nice with these potentially misconfigured users,
we recommend that you not only specify a recent ASDF in your dependencies with
@code{:depends-on ((:version "asdf" "3.1.2"))},
but that you @emph{also} check that ASDF 3 is installed,
or else the upgrade catastrophe might happen before that specification is checked,
by starting your @file{.asd} file with a version check as follows:
@example
#-asdf3 (error "@var{MY-SYSTEM} requires ASDF 3.1.2")
@end example
@item
When you upgrade from too old a version of ASDF,
previously loaded ASDF extensions become invalid, and will need to be reloaded.
Example extensions include CFFI-Grovel, hacks used by ironclad, etc.
Since it isn't possible to automatically detect what extensions
need to be invalidated and what systems use them,
ASDF will invalidate @emph{all} previously loaded systems
when it is loaded on top of a forward-incompatible ASDF version.
@footnote{
@vindex *oldest-forward-compatible-asdf-version*
Forward incompatibility can be determined using the variable
@code{asdf/upgrade::*oldest-forward-compatible-asdf-version*},
which is 2.33 at the time of this writing.}
@item
To write a portable build script, you need to rely on a recent version of UIOP,
but until you have ensured a recent ASDF is loaded,
you can't rely on UIOP being present,
and thus must manually avoid all the pathname pitfalls when loading ASDF itself.
@item
Bugs in CMUCL and XCL prevent upgrade of ASDF from an old forward-incompatible version.
Happily, CMUCL comes with a recent ASDF,
and XCL is more of a working demo than something you'd use seriously anyway.
@item
For the above reasons, your build and startup scripts
should load ASDF 3, configure it, and upgrade it,
among the very first things they do.
They should ensure that only ASDF 3 or later is used indeed,
and error out if ASDF 2 or earlier was used.
@item
Now that (since May 2016) all maintained implementations
(i.e. having had at least one release since 2014,
or a commit on their public source code repository)
provide ASDF 3.1 or later,
the simple solution is just to use code as below in your setup,
and when it fails, upgrade your implementation or replace its ASDF.
(@pxref{Replacing your implementation's ASDF}):
@example
(require "asdf")
#-asdf3.1 (error "ASDF 3.1 or bust")
@end example
@item
For scripts that try to use ASDF simply via @code{require} at first, and
make heroic attempts to load it the hard way if at first they don't succeed,
see @file{tools/load-asdf.lisp} distributed with the ASDF source repository,
or the code of @url{https://cliki.net/cl-launch,@code{cl-launch}}.
@item @anchor{reinitializeASDFAfterUpgrade}
Note that in addition to the pitfalls and constraints above,
these heroic scripts (should you wish to write or modify one),
must take care to configure ASDF @emph{twice}.
A first time, right after you load the old ASDF 2 (or 1!)
and before you upgrade to the new ASDF 3,
so it may find where you put ASDF 3.
A second time, because most implementations can't handle a smooth upgrade from ASDF 2 to ASDF 3,
so ASDF 3 doesn't try (anymore) and loses any configuration from ASDF 2.
@lisp
(ignore-errors (funcall 'require "asdf")) ;; <--- try real hard
;; <--- insert heroics here, if that failed to provide ASDF 2 or 3
;; <--- insert configuration here, if that succeeded
(asdf:load-system "asdf")
;; <--- re-configure here, too, in case at first you got ASDF 2
@end lisp
@end itemize
@node What happened to the bundle operations, , Pitfalls of the upgrade to ASDF 3, What has changed between ASDF 1 ASDF 2 and ASDF 3?
@subsection What happened to the bundle operations?
@tindex fasl-op (obsolete)
@tindex load-fasl-op (obsolete)
@tindex binary-op (obsolete)
@tindex monolithic-fasl-op (obsolete)
@tindex monolithic-load-fasl-op (obsolete)
@tindex monolithic-binary-op (obsolete)
@tindex compile-bundle-op
@tindex load-bundle-op
@tindex deliver-asd-op
@tindex monolithic-compile-bundle-op
@tindex monolithic-load-bundle-op
@tindex monolithic-deliver-asd-op
@code{asdf-ecl} and its short-lived successor @code{asdf-bundle} are no more,
having been replaced by code now built into ASDF 3.
Moreover, the name of the bundle operations has changed since ASDF 3.1.3.
Starting with ASDF 3.2.0, @code{load-system}
will once again use @code{load-bundle-op} instead of @code{load-op} on ECL,
as originally intended by @code{asdf-ecl} authors, but disabled for a long time
due to bugs in both ECL and ASDF.
Note that some of the bundle operations were renamed after ASDF 3.1.3,
and the old names have been removed.
Old bundle operations, and their modern equivalents are:
@itemize
@item
@code{fasl-op} is now @code{compile-bundle-op}
@item
@code{load-fasl-op} is now @code{load-bundle-op}
@item
@code{binary-op} is now @code{deliver-asd-op}
@item
@code{monolithic-fasl-op} is now @code{monolithic-compile-bundle-op}
@item
@code{monolithic-load-fasl-op} is now @code{monolithic-load-bundle-op}
@item
@code{monolithic-binary-op} is now @code{monolithic-deliver-asd-op}
@end itemize
@node Issues with installing the proper version of ASDF, Issues with configuring ASDF, What has changed between ASDF 1 ASDF 2 and ASDF 3?, FAQ
@section Issues with installing the proper version of ASDF
@menu
* My Common Lisp implementation comes with an outdated version of ASDF. What to do?::
* I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?::
* After upgrading ASDF, ASDF (and Quicklisp) can't find my systems: After upgrading ASDF.
@end menu
@node My Common Lisp implementation comes with an outdated version of ASDF. What to do?, I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?, Issues with installing the proper version of ASDF, Issues with installing the proper version of ASDF
@subsection ``My Common Lisp implementation comes with an outdated version of ASDF. What to do?''
If you have a recent implementation, it should already come with ASDF 3 or later.
If you need a more recent version than is provided,
we recommend you simply upgrade ASDF by installing a recent version
in a path configured in your source-registry.
@xref{Upgrading ASDF}.
If you have an old implementation that does not provide ASDF 3,
we recommend you replace your implementation's ASDF.
@xref{Replacing your implementation's ASDF}.
@node I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?, After upgrading ASDF, My Common Lisp implementation comes with an outdated version of ASDF. What to do?, Issues with installing the proper version of ASDF
@subsection ``I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?''
Since ASDF 2,
it should always be a good time to upgrade to a recent version of ASDF.
You may consult with the maintainer for which specific version they recommend,
but the latest @code{release} should be correct.
Though we do try to test ASDF releases against all implementations that we can,
we may not be testing against all variants of your implementation,
and we may not be running enough tests;
we trust you to thoroughly test it with your own implementation
before you release it.
If there are any issues with the current release,
it's a bug that you should report upstream and that we will fix ASAP.
As to how to include ASDF, we recommend the following:
@itemize
@item
If ASDF isn't loaded yet, then @code{(require "asdf")}
should load the version of ASDF that is bundled with your system.
If possible so should @code{(require "ASDF")}.
You may have it load some other version configured by the user,
if you allow such configuration.
@item
If your system provides a mechanism to hook into @code{cl:require},
then it would be nice to add ASDF to this hook the same way that
ABCL, CCL, CLISP, CMUCL, ECL, SBCL and SCL do it.
Please send us appropriate code to this end.
@item
You may, like SBCL since 1.1.13 or MKCL since 1.1.9,
have ASDF create bundle FASLs
that are provided as modules by your Lisp distribution.
You may also, but we don't recommend that anymore,
as in SBCL up until 1.1.12, have ASDF be implicitly used
to @code{cl:require} these modules that are provided by your Lisp distribution;
if you do, you should add these modules in the beginning of both
@code{wrapping-source-registry} and @code{wrapping-output-translations}.
@item
If you have magic systems as above, like SBCL used to do,
then we explicitly ask you to @emph{NOT} distribute
@file{asdf.asd} as part of those magic systems.
You should still include the file @file{asdf.lisp} in your source distribution
and precompile it in your binary distribution,
but @file{asdf.asd} if included at all,
should be secluded from the magic systems,
in a separate file hierarchy.
Alternatively, you may provide the system
after renaming it and its @file{.asd} file to e.g.
@code{asdf-ecl} and @file{asdf-ecl.asd}, or
@code{sb-asdf} and @file{sb-asdf.asd}.
Indeed, if you made @file{asdf.asd} a magic system,
then users would no longer be able to upgrade ASDF using ASDF itself
to some version of their preference that
they maintain independently from your Lisp distribution.
@item
If you do not have any such magic systems, or have other non-magic systems
that you want to bundle with your implementation,
then you may add them to the @code{wrapping-source-registry},
and you are welcome to include @file{asdf.asd} amongst them.
Non-magic systems should be at the back of the @code{wrapping-source-registry}
while magic systems are at the front.
If they are precompiled,
they should also be in the @code{wrapping-output-translations}.
@item
Since ASDF 3, the library UIOP comes transcluded in ASDF.
But if you want to be nice to users who care for UIOP but not for ASDF,
you may package UIOP separately,
so that one may @code{(require "uiop")} and not load ASDF,
or one may @code{(require "asdf")}
which would implicitly require and load the former.
@item
Please send us upstream any patches you make to ASDF itself,
so we can merge them back in for the benefit of your users
when they upgrade to the upstream version.
@end itemize
@node After upgrading ASDF, , I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?, Issues with installing the proper version of ASDF
@subsection After upgrading ASDF, ASDF (and Quicklisp) can't find my systems
@vindex *central-registry*
@cindex Quicklisp
When you upgrade the ASDF running in your Lisp image
from an ancient ASDF 2 or older to ASDF 3 or newer,
then you may have to re-configure ASDF.
If your configuration only consists in
using the source-registry and output-translations (as it should),
and if you are not explicitly calling @code{asdf:initialize-source-registry}
or @code{asdf:initialize-output-translations} with a non-nil argument,
then ASDF will reconfigure itself.
Otherwise, you will have to configure ASDF 2 (or older) to find ASDF 3,
then configure ASDF 3.
Notably, @var{*central-registry*} is not maintained across upgrades from ASDF 2.
@xref{reinitializeASDFAfterUpgrade,note about ASDF reconfiguration after upgrade}.
Problems like this may be experienced if one loads Quicklisp
(which as of this writing bundles an obsolete ASDF version 2.26),
upgrades ASDF, and then tries to load new systems.
The correct solution is to load the most up-to-date ASDF you can,
@emph{then} configure it, @emph{then} load Quicklisp and any other extension.
Do @emph{not} try to upgrade from ASDF 2 @emph{after} loading Quicklisp,
for it will leave both ASDF and Quicklisp badly misconfigured.
For details see the discussion at the above cross-reference.
Also, if you are experiencing such failures due to Quicklisp shipping an ancient ASDF,
please complain to Zach Beane about it.
@node Issues with configuring ASDF, Issues with using and extending ASDF to define systems, Issues with installing the proper version of ASDF, FAQ
@section Issues with configuring ASDF
@menu
* How can I customize where fasl files are stored?::
* How can I wholly disable the compiler output cache?::
* How can I debug problems finding ASDF systems::
@end menu
@node How can I customize where fasl files are stored?, How can I wholly disable the compiler output cache?, Issues with configuring ASDF, Issues with configuring ASDF
@subsection ``How can I customize where fasl files are stored?''
@xref{Controlling where ASDF saves compiled files}.
Note that in the past there was an add-on to ASDF called
@code{ASDF-binary-locations}, developed by Gary King.
That add-on has been merged into ASDF proper,
then superseded by the @code{asdf-output-translations} facility.
Note that use of @code{asdf-output-translations}
can interfere with one aspect of your systems
--- if your system uses @code{*load-truename*} to find files
(e.g., if you have some data files stored with your program),
then the relocation that this ASDF customization performs
is likely to interfere.
Use @code{asdf:system-relative-pathname} to locate a file
in the source directory of some system, and
use @code{asdf:apply-output-translations} to locate a file
whose pathname has been translated by the facility.
@node How can I wholly disable the compiler output cache?, How can I debug problems finding ASDF systems, How can I customize where fasl files are stored?, Issues with configuring ASDF
@subsection ``How can I wholly disable the compiler output cache?''
To permanently disable the compiler output cache
for all future runs of ASDF, you can:
@example
mkdir -p ~/.config/common-lisp/asdf-output-translations.conf.d/
echo ':disable-cache' > \
~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf
@end example
This assumes that you didn't otherwise configure the ASDF files
(if you did, edit them again),
and don't somehow override the configuration at runtime
with a shell variable (see below) or some other runtime command
(e.g. some call to @code{asdf:initialize-output-translations}).
To disable the compiler output cache in Lisp processes
run by your current shell, try (assuming @code{bash} or @code{zsh})
(on Unix and cygwin only):
@example
export ASDF_OUTPUT_TRANSLATIONS=/:
@end example
To disable the compiler output cache just in the current Lisp process,
use (after loading ASDF but before using it):
@example
(asdf:disable-output-translations)
@end example
Note that this does @emph{NOT} belong in a @file{.asd} file.
Please do not tamper with ASDF configuration from a @file{.asd} file,
and only do this from your personal configuration or build scripts.
@node How can I debug problems finding ASDF systems, , How can I wholly disable the compiler output cache?, Issues with configuring ASDF
@comment node-name, next, previous, up
@subsection How can I debug problems finding ASDF systems?
Sometimes ASDF will be unable to find and load your systems, although
you believe that it should be able to. There are a number of things you
can do to debug such issues.
@vindex *central-registry*
If you are using @code{asdf:*central-registry*} (@pxref{Configuring ASDF to find your systems --- old style}),
you can
simply look at the pathnames and namestrings in this variable, and use
conventional tools such as @code{cl:probe-file} and @code{cl:directory}
to poke around and see why your systems are not being found.
If you are using one of the newer methods for configuring ASDF's system
finding (@pxref{Controlling where ASDF searches for systems}), you can try:
@vindex *source-registry*
@example
(alexandria:hash-table-alist asdf/source-registry::*source-registry*)
@end example
(alphabetizing the results here may be helpful). Or for a higher-level
view:
@findex flatten-source-registry
@example
(asdf/source-registry:flatten-source-registry)
@end example
Finally, if you use the source registry cache (@pxref{Caching Results}), you can:
@example
find ~/common-lisp -name .cl-source-registry.cache
@end example
at the shell.
It is still, unfortunately, an open question how to monitor ASDF's
interpretation of its source configuration as it happens.
@node Issues with using and extending ASDF to define systems, ASDF development FAQs, Issues with configuring ASDF, FAQ
@section Issues with using and extending ASDF to define systems
@menu
* How can I cater for unit-testing in my system?::
* How can I cater for documentation generation in my system?::
* How can I maintain non-Lisp (e.g. C) source files?::
* I want to put my module's files at the top level. How do I do this?::
* How do I create a system definition where all the source files have a .cl extension?::
* How do I mark a source file to be loaded only and not compiled?::
* How do I work with readtables?::
* How can I capture ASDF's output?::
* LOAD-PATHNAME has a weird value::
@end menu
@node How can I cater for unit-testing in my system?, How can I cater for documentation generation in my system?, Issues with using and extending ASDF to define systems, Issues with using and extending ASDF to define systems
@subsection ``How can I cater for unit-testing in my system?''
ASDF provides a predefined test operation, @code{test-op}.
@xref{Predefined operations of ASDF, test-op}.
The test operation, however, is largely left to the system definer to specify.
@code{test-op} has been
a topic of considerable discussion on the
@url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}
(@pxref{Mailing list}),
and on the
@url{https://launchpad.net/asdf,launchpad bug-tracker} (@pxref{Where do I report a bug?}).
We provide some guidelines in the discussion of @code{test-op}.
@c cut the following because it's discussed in the discussion of test-op.
@c Here are some guidelines:
@c @itemize
@c @item
@c For a given system, @var{foo}, you will want to define a corresponding
@c test system, such as @var{foo-test}. The reason that you will want this
@c separate system is that ASDF does not out of the box supply components
@c that are conditionally loaded. So if you want to have source files
@c (with the test definitions) that will not be loaded except when testing,
@c they should be put elsewhere.
@c @item
@c The @var{foo-test} system can be defined in an asd file of its own or
@c together with @var{foo}. An aesthetic preference against cluttering up
@c the filesystem with extra asd files should be balanced against the
@c question of whether one might want to directly load @var{foo-test}.
@c Typically one would not want to do this except in early stages of
@c debugging.
@c @item
@c Record that testing is implemented by @var{foo-test}. For example:
@c @example
@c (defsystem @var{foo}
@c :in-order-to ((test-op (test-op @var{foo-test})))
@c ....)
@c (defsystem @var{foo-test}
@c :depends-on (@var{foo} @var{my-test-library} ...)
@c ....)
@c @end example
@c @end itemize
@c This procedure will allow you to support users who do not wish to
@c install your test framework.
@c One oddity of ASDF is that @code{operate} (@pxref{Operations,operate})
@c does not return a value. So in current versions of ASDF there is no
@c reliable programmatic means of determining whether or not a set of tests
@c has passed, or which tests have failed. The user must simply read the
@c console output. This limitation has been the subject of much
@c discussion.
@node How can I cater for documentation generation in my system?, How can I maintain non-Lisp (e.g. C) source files?, How can I cater for unit-testing in my system?, Issues with using and extending ASDF to define systems
@subsection ``How can I cater for documentation generation in my system?''
Various ASDF extensions provide some kind of @code{doc-op} operation.
See also @url{https://bugs.launchpad.net/asdf/+bug/479470}.
@node How can I maintain non-Lisp (e.g. C) source files?, I want to put my module's files at the top level. How do I do this?, How can I cater for documentation generation in my system?, Issues with using and extending ASDF to define systems
@subsection ``How can I maintain non-Lisp (e.g. C) source files?''
See @code{cffi}'s @code{cffi-grovel}.
@anchor{report-bugs}
@node I want to put my module's files at the top level. How do I do this?, How do I create a system definition where all the source files have a .cl extension?, How can I maintain non-Lisp (e.g. C) source files?, Issues with using and extending ASDF to define systems
@subsection ``I want to put my module's files at the top level. How do I do this?''
By default, the files contained in an asdf module go
in a subdirectory with the same name as the module.
However, this can be overridden by adding a @code{:pathname ""} argument
to the module description.
For example, here is how it could be done
in the spatial-trees ASDF system definition for ASDF 2 or later:
@example
(asdf:defsystem "spatial-trees"
:components
((:module "base"
:pathname ""
:components
((:file "package")
(:file "basedefs" :depends-on ("package"))
(:file "rectangles" :depends-on ("package"))))
(:module tree-impls
:depends-on ("base")
:pathname ""
:components
((:file "r-trees")
(:file "greene-trees" :depends-on ("r-trees"))
(:file "rstar-trees" :depends-on ("r-trees"))
(:file "rplus-trees" :depends-on ("r-trees"))
(:file "x-trees" :depends-on ("r-trees" "rstar-trees"))))
(:module viz
:depends-on ("base")
:pathname ""
:components
((:static-file "spatial-tree-viz.lisp")))
(:module tests
:depends-on ("base")
:pathname ""
:components
((:static-file "spatial-tree-test.lisp")))
(:static-file "LICENCE")
(:static-file "TODO")))
@end example
All of the files in the @code{tree-impls} module are at the top level,
instead of in a @file{tree-impls/} subdirectory.
Note that the argument to @code{:pathname} can be either a pathname object or a string.
A pathname object can be constructed with the @file{#p"foo/bar/"} syntax,
but this is discouraged because the results of parsing a namestring are not portable.
A pathname can only be portably constructed with such syntax as
@code{#.(make-pathname :directory '(:relative "foo" "bar"))},
and similarly the current directory can only be portably specified as
@code{#.(make-pathname :directory '(:relative))}.
However, as of ASDF 2, you can portably use a string to denote a pathname.
The string will be parsed as a @code{/}-separated path from the current directory,
such that the empty string @code{""} denotes the current directory, and
@code{"foo/bar"} (no trailing @code{/} required in the case of modules)
portably denotes the same subdirectory as above.
When files are specified, the last @code{/}-separated component is interpreted
either as the name component of a pathname
(if the component class specifies a pathname type),
or as a name component plus optional dot-separated type component
(if the component class doesn't specifies a pathname type).
@node How do I create a system definition where all the source files have a .cl extension?, How do I mark a source file to be loaded only and not compiled?, I want to put my module's files at the top level. How do I do this?, Issues with using and extending ASDF to define systems
@subsection How do I create a system definition where all the source files have a .cl extension?
Starting with ASDF 2.014.14, you may just pass
the builtin class @code{cl-source-file.cl} as
the @code{:default-component-class} argument to @code{defsystem}:
@lisp
(defsystem my-cl-system
:default-component-class cl-source-file.cl
...)
@end lisp
Another builtin class @code{cl-source-file.lsp} is offered
for files ending in @file{.lsp}.
If you want to use a different extension
for which ASDF doesn't provide builtin support,
or want to support versions of ASDF
earlier than 2.014.14 (but later than 2.000),
you can define a class as follows:
@lisp
;; Prologue: make sure we're using a sane package.
(defpackage :my-asdf-extension
(:use :asdf :common-lisp)
(:export #:cl-source-file.lis))
(in-package :my-asdf-extension)
(defclass cl-source-file.lis (cl-source-file)
((type :initform "lis")))
@end lisp
Then you can use it as follows:
@lisp
(defsystem my-cl-system
:default-component-class my-asdf-extension:cl-source-file.lis
...)
@end lisp
Of course, if you're in the same package, e.g. in the same file,
you won't need to use the package qualifier before @code{cl-source-file.lis}.
Actually, if all you're doing is defining this class
and using it in the same file without other fancy definitions,
you might skip package complications:
@lisp
(in-package :asdf)
(defclass cl-source-file.lis (cl-source-file)
((type :initform "lis")))
(defsystem my-cl-system
:default-component-class cl-source-file.lis
...)
@end lisp
@node How do I mark a source file to be loaded only and not compiled?, How do I work with readtables?, How do I create a system definition where all the source files have a .cl extension?, Issues with using and extending ASDF to define systems
@subsection How do I mark a source file to be loaded only and not compiled?
There is no provision in ASDF for ensuring that
some components are always loaded as source, while others are always
compiled.
There is @code{load-source-op} (@pxref{Predefined operations of
ASDF,load-source-op}), but that is an operation to be applied to a
system as a whole, not to one or another specific source files.
While this idea often comes up in discussions,
it doesn't play well with either the linking model of ECL
or with various bundle operations.
In addition, the dependency model of ASDF would have to be modified incompatibly
to allow for such a trick.
@c If your code doesn't compile cleanly, fix it.
@c If compilation makes it slow, use @code{declaim} or @code{eval-when}
@c to adjust your compiler settings,
@c or eschew compilation by @code{eval}uating a quoted source form at load-time.
@node How do I work with readtables?, How can I capture ASDF's output?, How do I mark a source file to be loaded only and not compiled?, Issues with using and extending ASDF to define systems
@subsection How do I work with readtables?
@cindex readtables
It is possible to configure the lisp syntax by modifying the currently-active readtable.
However, this same readtable is shared globally by all software being compiled by ASDF,
especially since @code{load} and @code{compile-file} both bind @var{*readtable*},
so that its value is the same across the build at the start of every file
(unless overridden by some @code{perform :around} method),
even if a file locally binds it to a different readtable during the build.
Therefore, the following hygiene restrictions apply. If you don't abide by these restrictions,
there will be situations where your output files will be corrupted during an incremental build.
We are not trying to prescribe new restrictions for the sake of good style:
these restrictions have always applied implicitly, and
we are simply describing what they have always been.
@itemize
@item It is forbidden to modifying any standard character or standard macro dispatch defined in the CLHS.
@item No two dependencies may assign different meanings to the same non-standard character.
@item Using any non-standard character while expecting the implementation to treat some way
counts as such an assignment of meaning.
@item libraries need to document these assignments of meaning to non-standard characters.
@item free software libraries will register these changes on:
@url{http://www.cliki.net/Macro%20Characters}
@end itemize
If you want to use readtable modifications that cannot abide by those restrictions,
you @emph{must} create a different readtable object and set @var{*readtable*}
to temporarily bind it to your new readtable (which will be undone after processing the file).
For that, we recommend you use system @code{named-readtables}
to define or combine such readtables using @code{named-readtables:defreadtable}
and use them using @code{named-readtables:in-readtable}.
Equivalently, you can use system @code{cl-syntax},
that itself uses @code{named-readtables},
but may someday do more with, e.g. @var{*print-pprint-dispatch*}.
For even more advanced syntax modification beyond what a readtable can express,
you may consider either:
@itemize
@item a @code{perform} method that compiles a constant file that contains a single form
@code{#.*code-read-with-alternate-reader*} in an environment where this special variable
was bound to the code read by your alternate reader, or
@item using the system @code{reader-interception}.
@end itemize
Beware that @c unless and until the @code{syntax-control} branch is merged,
it is unsafe to use ASDF from the REPL to compile or load systems
while the readtable isn't the shared readtable previously used to build software.
You @emph{must} manually undo any binding of @var{*readtable*} at the REPL
and restore its initial value whenever you call @code{operate}
(via e.g. @code{load-system}, @code{test-system} or @code{require})
from a REPL that is using a different readtable.
@subsubsection How should my system use a readtable exported by another system?
Use from the @code{named-readtables} system the macro @code{named-readtables:in-readtable}.
If the other system fails to use @code{named-readtables}, fix it and send a patch upstream.
In the day and age of Quicklisp and clbuild, there is little reason
to eschew using such an important library anymore.
@subsubsection How should my library make a readtable available to other systems?
Use from the @code{named-readtables} system the macro @code{named-readtables:defreadtable}.
@node How can I capture ASDF's output?, LOAD-PATHNAME has a weird value, How do I work with readtables?, Issues with using and extending ASDF to define systems
@subsection How can I capture ASDF's output?
@cindex ASDF output
@cindex Capturing ASDF output
@vindex *standard-output*
Output from ASDF and ASDF extensions are sent to the CL stream
@code{*standard-output*}, so rebinding that stream around calls to
@code{asdf:operate} should redirect all output from ASDF operations.
@node LOAD-PATHNAME has a weird value, , How can I capture ASDF's output?, Issues with using and extending ASDF to define systems
@subsection *LOAD-PATHNAME* and *LOAD-TRUENAME* have weird values, help!
@vindex *LOAD-PATHNAME*
@vindex *LOAD-TRUENAME*
Conventional Common Lisp code may use @code{*LOAD-TRUENAME*} or @code{*LOAD-PATHNAME*} to find
files adjacent to source files. This will generally @emph{not} work in
ASDF-loaded systems. Recall that ASDF relocates the FASL files it
builds, typically to a special cache directory. Thus the value of
@code{*LOAD-PATHNAME*} and @code{*LOAD-TRUENAME*} at load time, when ASDF is loading your system,
will typically be a pathname in that cache directory, and useless to you
for finding other system components.
There are two ways to work around this problem:
@enumerate
@findex system-relative-pathname
@item
Use the @code{system-relative-pathname} function. This can readily be
used from outside the system, but it is probably not good software
engineering to require a source file @emph{of} a system to know what
system it is going to be part of. Contained objects should not have to
know their containers.
@item
Store the pathname at compile time, so that you get the pathname of the
source file, which is presumably what you want. To do this, you can
capture the value of @code{(or *compile-file-pathname* *load-truename*)}
(or @code{*LOAD-PATHNAME*}, if you prefer)
in a macro expansion or other compile-time evaluated context.
@end enumerate
@node ASDF development FAQs, , Issues with using and extending ASDF to define systems, FAQ
@section ASDF development FAQs
@menu
* How do I run the tests interactively in a REPL?::
@end menu
@node How do I run the tests interactively in a REPL?, , ASDF development FAQs, ASDF development FAQs
@subsection How do I run the tests interactively in a REPL?
This not-so-frequently asked question is primarily for ASDF developers,
but those who encounter an unexpected error in some test may be
interested, too.
Here's the procedure for experimenting with tests in a REPL:
@example
;; BEWARE! Some tests expect you to be in the .../asdf/test directory
;; If your REPL is not there yet, change your current directory:
;; under SLIME, you may: ,change-directory ~/common-lisp/asdf/test/
;; otherwise you may evaluate something like:
(require "asdf") (asdf:upgrade-asdf) ;load UIOP & update asdf.lisp
(uiop:chdir (asdf:system-relative-pathname :asdf "test/"))
(setf *default-pathname-defaults* (uiop:getcwd))
;; Load the test script support.
(load "script-support.lisp")
;; Initialize the script support for interaction.
;; This will also change your *package* to asdf-test
;; after frobbing the asdf-test package to make it usable.
;; NB: this function is also available from package cl-user,
;; and also available with the shorter name da in both packages.
(asdf-test:debug-asdf)
;; Now, you may experiment with test code from a .script file.
;; See the instructions given at the end of your failing test
;; to identify which form is needed, e.g.
(run-test-script "test-utilities.script")
@end example
@comment FIXME: Add a FAQ about how to use a new system class...
@comment node-name, next, previous, up
@node Ongoing Work, Bibliography, FAQ, Top
@unnumbered Ongoing Work
For an active list of things to be done,
see the @file{TODO} file in the source repository.
Also, bugs are currently tracked on launchpad:
@url{https://launchpad.net/asdf}.
@node Bibliography, Concept Index, Ongoing Work, Top
@unnumbered Bibliography
@itemize
@item Andrey Mokhov, Neil Mitchell and Simon Peyton Jones:
``Build Systems à la Carte'',
International Conference on Functional Programming, 2018.
@url{https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf}
This influential article provides axes along which to describe build systems in general;
ASDF, in addition to being in-image (an axis not considered by these authors),
has the following characteristics:
ASDF's persistent build information is file modification times
(the way ASDF is written, it should be easy enough to write an extension that modifies it
to use a ``cloud cache'' à la Bazel,
but that would involve using some database, network and cryptographic libraries,
which cannot reasonably be included in the base ASDF,
that must remain a minimal bootstrappable system with no external dependencies).
The object model of ASDF was initially designed for ``static'' dependencies
with a ``topological'' scheduler, but its @code{defsystem-depends-on} mechanism
(and more generally, the ability to call ASDF from within an @code{.asd} file)
allows for multiple @emph{phases} of execution resulting
in ``dynamic'' dependencies with a ``suspending'' scheduler.
The rebuilder essentially uses a ``dirty bit'', except that the in-image model
and the multiple phase support mean that's actually more than a bit:
instead it's three bits plus the timestamp plus a phase depth level.
The build is guaranteed ``minimal'' in number of steps computed.
It is local. It assumes but does not enforce determinism.
It does not assume early cutoff of the build when rebuild dependencies didn't change.
@item Robert Goldman, Elias Pipping, and François-René Rideau:
``Delivering Common Lisp Applications with ASDF 3.3'',
European Lisp Symposium, 2017.
@url{https://github.com/fare/asdf2017}
This short article gives an overview of the changes in ASDF 3.2 and 3.3, including
improved application delivery, asynchronous subprocess management,
correct support for multi-phase builds, and enhanced source location configuration.
@item Francois-Rene Rideau:
``ASDF 3, or Why Lisp is Now an Acceptable Scripting Language'',
European Lisp Symposium, 2014.
@url{https://github.com/fare/asdf3-2013}
This article describes the innovations in ASDF 3 and 3.1,
as well as historical information on previous versions.
@item Alastair Bridgewater:
``Quick-build'' (private communication), 2012.
@code{quick-build} is a simple and robust one file, one package build system,
similar to @code{faslpath}, in 182 lines of code
(117 of which are neither blank nor comments nor docstrings).
Unhappily, it remains unpublished and its IP status is unclear as of April 2014.
@code{asdf/package-system} is mostly compatible with it,
modulo a different setup for toplevel hierarchies.
@item Zach Beane:
``Quicklisp'', 2011.
The Quicklisp blog and Xach's personal blogs contain information on Quicklisp.
@url{http://blog.quicklisp.org/}
@url{http://lispblog.xach.com/} (new)
@url{http://xach.livejournal.com/} (old)
@item Francois-Rene Rideau and Robert Goldman:
``Evolving ASDF: More Cooperation, Less Coordination'',
International Lisp Conference, 2010.
This article describes the main issues solved by ASDF 2,
and exposes its design principles.
@url{https://common-lisp.net/project/asdf/ilc2010draft.pdf}
@url{http://rpgoldman.goldman-tribe.org/papers/ilc2010-asdf.pdf}
@item Francois-Rene Rideau and Spencer Brody:
``XCVB: an eXtensible Component Verifier and Builder for Common Lisp'',
International Lisp Conference, 2009.
This article describes XCVB, a proposed competitor for ASDF;
many of its ideas have been incorporated into ASDF 2 and 3,
though many other ideas still haven't.
@url{https://common-lisp.net/project/xcvb/}
@item Peter von Etter:
``faslpath'', 2009.
@code{faslpath} is similar to the latter @code{quick-build}
and our yet latter @code{asdf/package-system} extension,
except that it uses dot @code{.} rather than slash @code{/} as a separator.
@url{https://code.google.com/p/faslpath/}
@item Drew McDermott:
``A Framework for Maintaining the Coherence of a Running Lisp,''
International Lisp Conference, 2005.
@url{http://www.cs.yale.edu/homes/dvm/papers/lisp05.pdf}
@item Dan Barlow: ``ASDF Manual'', 2004.
Older versions of this document from the days of ASDF 1;
they include ideas laid down by Dan Barlow,
and comparisons with older defsystems (@code{mk-defsystem})
and defsystem (@code{defsystem-4}, kmp's Memo 801).
@item Marco Antoniotti and Peter Van Eynde:
``@code{DEFSYSTEM}: A @code{make} for Common Lisp, A Thoughtful Re-Implementation of an Old Idea'', 2002.
The @file{defsystem-4} proposal available in the CLOCC repository.
@item Mark Kantrovitz:
``Defsystem: A Portable Make Facility for Common Lisp'', 1990.
The classic @file{mk-defsystem}, later variants of which
are available in the CLOCC repository as @code{defsystem-3.x}.
@item Richard Elliot Robbins:
``BUILD: A Tool for Maintaining Consistency in Modular Systems'', MIT AI TR 874, 1985.
@url{http://www.dtic.mil/dtic/tr/fulltext/u2/a162744.pdf}
@item Kent M. Pitman (kmp): ``The Description of Large Systems'', MIT AI Memo 801, 1984.
Available in updated-for-CL form on the web at
@url{http://nhplace.com/kent/Papers/Large-Systems.html}
@item Dan Weinreb and David Moon:
``Lisp Machine Manual'', 3rd Edition MIT, March 1981.
The famous CHINE NUAL describes one of the earliest variants of DEFSYSTEM.
(NB: Not present in the second preliminary version of January 1979)
@url{http://bitsavers.org/pdf/mit/cadr/chinual_3rdEd_Mar81.pdf}
@end itemize
@node Concept Index, Function and Macro Index, Bibliography, Top
@unnumbered Concept Index
@printindex cp
@node Function and Macro Index, Variable Index, Concept Index, Top
@unnumbered Function and Macro Index
@printindex fn
@node Variable Index, Class and Type Index, Function and Macro Index, Top
@unnumbered Variable Index
@printindex vr
@node Class and Type Index, , Variable Index, Top
@unnumbered Class and Type Index
@printindex tp
@bye
@c LocalWords: clbuild tarballs defsystem Quicklisp initarg uiop fasl
@c LocalWords: namestring initargs fasls
asdf-3.3.4/doc/best_practices.md 0000664 0000000 0000000 00000131031 13621551153 0016520 0 ustar 00root root 0000000 0000000 ASDF Best Practices
===================
This document presents the current best practices and conventions
for using ASDF 3, as of 2017.
It is not a tutorial, though it starts like one,
because it assumes for each category of ASDF user
(beginner, simple user, more elaborate user)
that he already knows what seems to be common knowledge among such users,
and tries to complete this knowledge with less obvious points
that are often wrong in systems seen in the wild.
Table of Contents
-----------------------------------
- [Trivial Examples](#trivial_examples)
+ [Trivial Uses of ASDF](#trivial_asdf)
* [Loading a System](#loading_system)
* [Testing a System](#testing_system)
* [Designating a System](#designating_system)
+ [Trivial System Definition](#trivial_system)
* [Using the system you defined](#using_system)
+ [Trivial Testing Definition](#trivial_testing)
* [Notes on ASDF 2 compatibility](#notes_asdf2)
+ [Trivial Packaging](#trivial_packaging)
* [Digression about symbols and packages](#digression)
- [Simple Examples](#simple_examples)
+ [Simple Uses of a System](#simple_uses)
* [Building a System](#building_system)
* [Inspecting a System](#inspecting_system)
* [Other Operations](#other_operations)
+ [System Naming](#system_naming)
* [Primary Systems](#primary_systems)
* [Secondary Systems](#secondary_systems)
+ [Simple System Definition](#simple_system)
+ [Simple Packaging](#simple_packaging)
* [Initial Package for a Lisp File](#initial_package)
* [Using Symbols from ASDF and UIOP](#using_symbols)
+ [Simple Testing](#simple_testing)
+ [Other Secondary Systems](#other_secondary)
* [Delivering an Executable](#delivering_executable)
* [System Connections](#system_connections)
- [More Elaborate Examples](#moreelaborate_examples)
+ [More Elaborate Uses of ASDF](#moreelaborate_asdf)
* [force](#force)
* [force-not](#force_not)
* [Require](#require)
+ [More Elaborate System Definitions](#elaborate_definitions)
* [package-inferred-system](#package_inferred)
* [Using ASDF Extensions](#using_extensions)
* [Code in .asd files](#code_asd)
* [Conditional Code](#conditional_code)
+ [More Elaborate Testing](#moreelaborate_testing)
+ [Defining ASDF Extensions](#defining_extensions)
* [Source File Types](#source_types)
* [Conditional Outputs and Conditional Perform](#conditional_outputs)
- [Other](#other)
+ [Syntax Control](#syntax_control)
+ [Using ASDF Internals](#using_asdf_internals)
Trivial Examples
------------------------------------------------
Let's start with some trivial examples.
We'll see below how these examples evolve as systems grow more complex.
### Trivial Uses of ASDF
#### Loading a System
The most trivial use of ASDF is by calling `(asdf:load-system :foobar)`
to load your library.
Then you can use it.
For instance, if it exports a function `some-fun` in its package `foobar`,
then you will be able to call it with `(foobar:some-fun ...)` or with:
(in-package :foobar)
(some-fun ...)
#### Testing a System
To run the tests for a system, you may use:
(asdf:test-system :foobar)
The convention is that an error SHOULD be signalled if tests are unsuccessful.
#### Designating a System
Using keywords to name systems is good and well at the REPL.
However, when writing a program, a bootstrap script, or a system definition,
you SHOULD follow the good style of writing names in the canonical way;
and the canonical name of a system is a string, which by convention is in lower-case
(indeed any symbol used as system designator is downcased by `asdf:coerce-name`).
Thus, the proper way to designate a system in a program is with lower-case strings, as in:
(asdf:load-system "foobar")
(asdf:test-system "foobar")
(Historical note: MK-DEFSYSTEM and before it Genera's SCT
used string-upcase to normalize system names,
and use that as filenames, which made sense on Genera's filesystem
or using logical pathnames as common with MK-DEFSYSTEM.
Dan Barlow's ASDF, to "Play Nice With Unix", preferred lower-case file names,
and used string-downcase to normalize symbols into strings;
at the same time, he allowed you to specify mixed case or upper-case names by using a string.
The latter was probably a mistake, and I strongly recommend against using anything but lower-case.
If that weren't allowed, there would be a case for making lower-case symbols the default syntax,
and let the various case conversions do their job without quotes.
But that is not where we are.
In any case, system names designate `.asd` files, not Lisp bindings,
and this determines their syntax.)
### Trivial System Definition
A trivial system would have a single Lisp file called `foobar.lisp`.
That file would depend on some existing libraries,
say `alexandria` for general purpose utilities,
and `trivia` for pattern-matching.
To make this system buildable using ASDF,
you create a system definition file called `foobar.asd`,
with the following contents:
(defsystem "foobar"
:depends-on ("alexandria" "trivia")
:components ((:file "foobar")))
Note how the type `lisp` of `foobar.lisp`
is implicit in the name of the file above.
As for contents of that file, they would look like this:
(defpackage :foobar
(:use :common-lisp :alexandria :trivia)
(:export
#:some-function
#:another-function
#:call-with-foobar
#:with-foobar))
(in-package :foobar)
(defun some-function (...)
...)
...
#### Using the system you defined
Assuming your system is installed under the `~/common-lisp/` hierarchy
or some other filesystem hierarchy already configured for ASDF,
you can load it with: `(asdf:load-system "foobar")`,
or shorter `(asdf:make :foobar)`
If your Lisp was already started when you created that file,
you may have to `(asdf:clear-configuration)` to re-process the configuration.
### Trivial Testing Definition
Even the most trivial of systems needs some tests,
if only because it will have to be modified eventually,
and you want to make sure those modifications don't break client code.
Tests are also a good way to document expected behavior.
The simplest way to write tests is to have a file `foobar-tests.lisp`
and modify the above `foobar.asd` as follows:
(defsystem "foobar"
:depends-on ("alexandria" "trivia")
:components ((:file "foobar"))
:in-order-to ((test-op (test-op "foobar/tests"))))
(defsystem "foobar/tests"
:depends-on ("foobar" "fiveam")
:components ((:file "foobar-tests"))
:perform (test-op (o c) (symbol-call :fiveam '#:run! :foobar)))
The `:in-order-to` clause in the first system
allows you to use `(asdf:test-system :foobar)`
which will chain into `foobar/tests`.
The `:perform` clause in the second system does the testing itself.
In the test system, `fiveam` is the name of a popular test library,
and the content of the `perform` method is how to invoke this library
to run the test suite `:foobar`.
Obviously your mileage may vary if you use a different library.
#### Note on ASDF 2 compatibility
The `:in-order-to ((test-op (test-op ...)))` idiom will not work with ASDF 2:
attempts to `test-system` will result in failure due to circular dependencies;
however, `load-system` will still work.
As for the `:perform` method, you need to specify `:after` right after `test-op`
for ASDF 2 to accept the `defsystem` form at all (but still not make the `:in-order-to` work);
so it's probably OK if your test system is in a separate `.asd` file,
but if you want backward compatibility and it's a secondary system, you'll use `:after`.
Making things work completely on ASDF 2 as well as ASDF 3 would take a lot of pain,
and would be colloquial for neither.
But *friends don't let friends use ASDF 2*.
ASDF 3 has been available since 2013, and
all implementations have now been providing it for a long time.
Many systems, and growing, assume ASDF 3, possibly some you depend on,
and it's pointless to maintain compatibility with a moribund system
(especially so if you don't also check that all your dependencies do, too).
Upgrade your implementations and/or at least your ASDF,
and tell your friends to do as much.
The [very founding principle of ASDF 2](http://fare.livejournal.com/149264.html) (and 3)
was to provide users with
the ability to install a newer ASDF on top of an old one to fix its bugs
(an ability that did not exist with ASDF 1);
thus, users do not have to maintain compatibility with antique bugs.
These days, I even recommended that you should freely rely
on features of ASDF 3.1 (2014) not present in ASDF 3.0 (2013), such as:
`~/common-lisp/` being included in the source-registry by default;
`run-program` being full-fledged with input and error-output support;
or the `package-inferred-system` feature.
Conversely, if you want indefinite backward compatibility, why stop at ASDF 2?
Why not also support ASDF 1, and MK-DEFSYSTEM, and
the original Lisp Machine DEFSYSTEM?
A good rule of thumb for me is that it is not worth writing workarounds
for bugs that were fixed or features that were changed two years ago or more.
Two years seems to be the time it takes for a release of ASDF
to become ubiquitously available by default on all implementations;
and, remember, if a user must use an older implementation,
he can always trivially install a newer ASDF on top of it.
Thus, by October 2019, people should not be shy about
dropping support for ASDF versions older than 3.3.
And even before then, if you need a recent ASDF, just document it,
and tell your users to upgrade their implementation and/or
install a recent ASDF on top of their implementation's.
### Trivial Packaging
In the previous testing code, `symbol-call` is a function defined in package `uiop`.
It helps deal with the fact that the package `:fiveam` isn't defined yet
at the time the `defsystem` form is read.
Thus you can't simply write `(fiveam:run! :foobar)`, as
this might cause a failure at read-time when file `foobar.asd` is first read
and the system `fiveam` isn't loaded yet.
This of course also holds for packages defined by system `foobar` itself.
To get a symbol in it that is not a function being called,
you can also use `(find-symbol* :some-symbol :foobar)`,
and you can use `symbol-value` to get the value bound to such a symbol as denoting a variable.
For complex expressions, you can use `eval` and `read-from-string`,
as in `(eval (read-from-string "(foobar:some-fun foobar:*some-var*)"))`,
or equivalently, also from `uiop`: `(eval-input "(foobar:some-fun foobar:*some-var*)")`.
System definition files are loaded with the current `*package*` bound to the package `:asdf-user`,
that uses the packages `:cl`, `:asdf` and `:uiop`.
Therefore, you don't need to and you SHOULD NOT specify `cl:`, `asdf:` or `uiop:` prefixes
when referring to symbols in these respective packages.
It is considered bad form to do so, unless you changed the package,
and even then, your package should probably use these packages, too.
In particular you SHOULD NOT to write `(asdf:defsystem "foobar" ...)`
instead of `(defsystem "foobar" ...)`.
Also, you SHOULD NOT use `(in-package ...)` or `(defpackage ...)`
if all you do can legitimately be done in package `ASDF-USER`.
System definition files are loaded by a special function `asdf::load-asd`;
this function locally binds the current `*package*` to the `:asdf-user` package,
but it also does many other things.
You MUST NOT ever load a `.asd` file using `cl:load`,
as this will not work in general, and may fail in subtle or spectacular ways.
You MUST always use `asdf::load-asd` for that purpose
(the function is exported in ASDF 3.2 and above, but not in earlier versions).
You SHOULD NOT encourage the illusion that a `.asd` file can be loaded with `cl:load`
by using `(in-package :asdf-user)` or anything,
or by using the package prefix `asdf:` for `defsystem` and other such symbols.
You SHOULD be using the `slime-asdf` extension to SLIME
if you are going to edit `.asd` file and then load them from SLIME,
as it will automatically use `load-asd` to load the file contents.
#### Digression about symbols and packages
A crucial notion in Common Lisp is that of *symbols*, to which are associated
functions, variables, macros, properties, and other meanings.
These symbols are organized in a two-level namespace that is global to a given Lisp image.
Symbols are the second level, and the first level are *packages*.
Symbols and packages are traditionally uppercase internally,
but you traditionally write them lower-case in source code;
the Common Lisp reader is *case-converting*.
These internal representation details matter, because they are exposed
when you either write macros at compile-time or introspect the system at runtime.
The conventional way to refer to a package is with its name designated by a lower-case keyword,
starting with the colon character `:`.
For instance, the standard package `COMMON-LISP` is commonly designated as `:common-lisp`
(or `(find-package :common-lisp)` if you need an actual package object).
Keywords are themselves symbols in the magic package `KEYWORD`,
where each interned symbol is also a constant bound to its own name as a value.
Using a keyword as designator rather than a string ensures that we can maintain
the same convention of using lower-case in source code while the runtime will use uppercase.
Simple Examples
----------------------------------------------
As systems grow, the above pattern quickly becomes insufficient,
but systems can still remain simple.
### Simple Uses of a System
#### Building a System
Some systems offer operations
that are neither loading in the current image, nor testing.
Whichever operation a system is meant to be used with, you may use it with:
(asdf:make :foobar)
This will invoke `build-op`, which in turn will depend on
the `build-operation` for the system, if defined, or `load-op` if not.
Therefore, for usual Lisp systems that want you to load them,
the above will be equivalent to `(asdf:load-system :foobar)`,
but for other Lisp systems, e.g. one that creates a shell command-line executable,
`(asdf:make ...)` will do the Right Thing™, whatever that Right Thing™ is.
#### Inspecting a System
To look at what ASDF knows of your system, try:
(describe (asdf:find-system "foobar"))
If you're looking for the `.asd` file, try `(asdf:system-source-file "foobar")`.
For the directory in which the `.asd` file resides, try `(asdf:system-source-directory "foobar")`.
For a specific file under that directory try
`(asdf:system-relative-pathname "foobar" "path/to/the/file.extension")`.
#### Other Operations
ASDF has the concept of an *operation* that can act upon a system (or a smaller component thereof).
Typical operations that matter to end-users include:
* `load-op` for loading a system in the current Lisp image, as used by `asdf:load-system`,
* `test-op` for running tests associated to the system, as used by `asdf:test-system`,
* `build-op` for doing whatever build operation is associated to the system,
(which by default is `load-op` if the system didn't override it),
as used by `asdf:make`.
Further operations of interest to users include:
* `compile-op`
(ensure the system is compiled, without necessarily loading all of it, or any bit of it),
* `load-source-op`
(load the system from source without compiling),
* `compile-bundle-op`
(create a single fasl for the entire system, for delivery),
* `monolithic-compile-bundle-op`
(create a single fasl for the entire system *and all its transitive dependencies*, for delivery),
* `image-op`
(create a development image with this system already loaded, for fast startup),
* `program-op`
(create a standalone application, which we will see below), etc.
Whichever operation you want, `(asdf:operate `*operation* *system*`)`
will ensure this operation is performed on that system
(after all the necessary dependencies of such an action).
A short-hand `asdf:oos` is available for `asdf:operate`
(the name `oos` is an old acronym for `operate-on-system`,
and both functions existed as synonyms in the old MK-DEFSYSTEM;
the latter function doesn't exist in ASDF, which instead has just `operate`).
The operation is typically specified as a symbol that names the operation class.
Since ASDF 3, you can also use a keyword to specify an action in the ASDF package.
Thus, `(asdf:oos :load-op :foobar)` is equivalent to `(asdf:load-system :foobar)`.
### System Naming
#### Primary Systems
ASDF has a notion of *primary system*,
that it can find in configured parts of the filesystem (the *source-registry*),
in a file that has the same name and the type `asd`.
Thus, primary system `foobar` is defined in a file `foobar.asd`.
While arbitrary strings are accepted in system names, it is strongly discouraged
to use anything but lower-case ASCII letters and digits for primary system names,
plus the separators `-` (hyphen) and `.` (dot).
The `.` itself is only recommended in primary system names that are part of an informal hierarchy;
for instance the popular library `iolib` contains many related systems:
`iolib.asdf`, `iolib.base`, `iolib.common-lisp`, `iolib.conf`, `iolib.examples`,
`iolib.grovel`, `iolib.tests`.
The main one is ostensibly `iolib`, but it contains many systems,
and for some reasons (notably proper phase separation)
they cannot all be secondary systems in the same file.
#### Secondary Systems
A *secondary system* is a system defined in the same file as a primary system.
By convention, its name starts the same as the file's primary system,
followed by a slash `/` and by a *suffix* made of some arbitrary characters,
preferably ASCII letters and digits
plus the separators `-` (hyphen), `.` (dot) and `/` (slash).
We already saw an example of it with system `foobar/tests`
in the trivial testing definition above.
The convention above allows ASDF 3 and later to find a secondary system by name,
by first looking for the associated primary system.
ASDF 3.2 or later will issue a `warning` when you violate this naming convention.
(Historically, ASDF 1 (and 2) allowed arbitrary names for secondary systems,
and in practice many people used `foo-test` or such for secondary system names in `foo.asd`;
however, ASDF 1 (and 2) couldn't find those systems by name, and horrific bugs could happen
if a system was simultaneously defined in multiple files.)
### Simple System Definition
A simple system may be made of many files.
Typically, in `package.lisp` (or `packages.lisp`)
you'll define the package (or packages)
used by all the files in your system
in one or more forms such as `(defpackage :foobar ...)`.
Then, in a package `utils.lisp` you'll define utility macros and functions
that you're using throughout your system;
maybe some of them deserve to be moved to `alexandria` and other utility systems;
and maybe they already exist out there and you just haven't looked hard enough.
Then a file `foobar.lisp` defines the meat of your system.
Your system definition will look like:
(defsystem "foobar"
:depends-on ("alexandria" "trivia")
:serial t
:components
((:file "package")
(:file "utils")
(:file "foobar")))
The `:serial t` indicates that each of these files depends on (all) the previous.
As your system grows some more, soon enough instead of a single file `foobar.lisp`,
you will have several files, one for each aspect of your system, such as
`foo.lisp`, `bar.lisp` as well as `foobar.lisp`.
Moreover, `:serial t` soon becomes inappropriate:
it will make your code slower to compile, but also to read.
Indeed, those who read the code won't be readily able to tell
which parts of the code they need to keep active in their brains
to understand the code at hand.
Instead, you may prefer to explicitly represent the dependencies
between the components of your system using `:depends-on` clauses
as follows:
(defsystem "foobar"
:depends-on ("alexandria" "trivia" "trivia.ppcre")
:components
((:file "package")
(:file "utils" :depends-on ("package"))
(:file "foo" :depends-on ("utils"))
(:file "bar" :depends-on ("utils"))
(:file "foobar" :depends-on ("foo" "bar"))))
Out of good style, you SHOULD still list the components in an order that makes sense,
such that the readers can read the files and mentally rebuild the system.
However, note that this order, if coherent, will be respected
only in ASDF 3.3 or later, due to a bug in earlier versions of ASDF.
But that precise order shouldn't matter, or it should be reflected
in the `:depends-on` declarations (or in a `:serial t` declaration).
### Simple Packaging
#### Initial Package for a Lisp File
You MAY assume that the current package uses `CL` at the beginning of a file,
but you MUST NOT assume that it is any particular package at this point:
right now, it *is* guaranteed to be the `CL-USER` package of the underlying implementation,
but it is conceivable that in some indeterminate future,
some extension to CL may provide a well-defined portable alternative that ASDF would use.
Therefore, the sane way to write a Lisp file is that it SHOULD start
with an `in-package` form, optionally preceded by a `defpackage` form
(or a `uiop:define-package` form).
You SHOULD NOT write `cl:in-package` or precede your `defpackage` with an `(in-package :cl-user)`
(which is stupid, because to be pedantic you'd have to `(cl:in-package :cl-user)`,
at which point you may as well `(cl:defpackage ...)` and `(cl:in-package ...)`).
If it's a regular `cl-source-file`, it can assume the language is CL indeed,
and that the readtable something reasonable, etc.
#### Using Symbols from ASDF and UIOP
You MAY use any of the symbols documented and exported by ASDF or UIOP.
Actually, it is warmly recommended to use them everywhere that it matters,
instead of less documented or less portable alternatives.
You MUST NOT use `asdf:run-shell-command`, `asdf:system-definition-pathname`,
or other deprecated functions that were once recommended in the time of ASDF 1.
They will be removed in the near future (one to two year horizon).
ASDF 3.2 or 3.3 will issue a `style-warning` when you do, and
some future version of ASDF will issue a full `warning`,
which will then break the SBCL build.
See `backward-interface.lisp` for a list of deprecated function — or just heed the damn warnings.
### Simple Testing
Test systems can also be divided in multiple files.
If possible (which is not always the case), the file names for test files
should match file names for regular code files,
so that the file that tests `bar.lisp` will be called `bar-test.lisp` or `bar-tests.lisp`
(pick singular or plural, but have a story for it and be consistent about it).
To keep things tidy as the test system grows,
you may even put all test files in a subdirectory `t/`, `test/` or `tests/`.
Your test system definition may then look like:
(defsystem "foobar/tests"
:depends-on ("fiveam" "foobar")
:pathname "t/" ;; specify the subdirectory
:components
((:file "test-suite")
(:file "utils-test" :depends-on ("test-suite"))
(:file "foo-test" :depends-on ("test-suite"))
(:file "bar-test" :depends-on ("test-suite"))
(:file "foobar-test" :depends-on ("test-suite")))
:perform (test-op (o c) (symbol-call :foobar/tests :run-test-suite)))
As the system and its test system both grow, the test system may be moved to its own file
`foobar-tests.asd` or `foobar.tests.asd` where it is its own primary system:
(defsystem "foobar-tests" ...)
### Other secondary systems
Other secondary systems may be created beyond test systems:
for instance systems that provide independent aspects of the system,
or optional add-ons to it.
One case is a command that makes the Lisp functionality accessible from a Unix shell.
#### Delivering an Executable
To build an executable, define a system as follows
(in this case, it's a secondary system, but it could also be a primary system).
You will be able to create an executable file `foobar-command`
by evaluating `(asdf:make :foobar/executable)`:
(defsystem "foobar/executable"
:build-operation program-op
:build-pathname "foobar-command" ;; shell name
:entry-point "foobar::start-foobar" ;; thunk
:depends-on ("foobar")
:components ((:file "main")))
The `build-pathname` gives the name of the executable;
a `.exe` type will be automatically added on Windows.
As a horrible kluge that may go away in the future,
the output will be created in the system's directory (where the `foobar.asd` file resides)
when the `build-operation` matches the requested operation.
A future version of ASDF will probably instead have some `:output` argument to `operate`,
or some such thing, and drop this ugly special case.
You have been warned. Contact me if you want that sooner, or not at all.
There, file `main.lisp` defines a function `start-foobar` in package `foobar`,
that takes no argument, and initializes and starts the executable ---
after `uiop` calls its own `*image-restore-hook*` and evaluates any provided `*image-prelude*`.
Importantly, libraries may register functions to call in the `*image-restore-hook*`
using `register-image-restore-hook` (see also `register-image-dump-hook`);
UIOP and ASDF themselves make use of this facility.
Typically, `start-foobar` will be defined as something like:
(defun start-foobar () (main (uiop:command-line-arguments)))
Where function `main` parses the arguments
(a list of strings, excluding the magic C `argv[0]`, which can be computed as `(uiop:argv0)`)
and does whatever its magic.
You may want to use the full-featured `net.didierverna.clon` or my small `command-line-arguments`
or one of a slew of other libraries to parse the command-line arguments.
You may want to use `cl-scripting` to nicely wrap Lisp code into execution contexts
that handle errors in a nice(r) user-visible way for the shell user.
You may want to use `inferior-shell` if your program in turn invokes other shell programs.
Instead may also use `cl-launch` to build executables, or `buildapp`.
`cl-launch` is largely compatible with ASDF
(indeed, a lot of code formerly written as part of `cl-launch`
was later made part of ASDF 3's UIOP).
`buildapp`, that came before ASDF 3 but after `cl-launch`,
has a slightly incompatible convention where a main function is called with
a list of arguments that includes the `argv[0]`.
(`cl-launch` and after it UIOP had many good enough reasons
to start the argument list at the "user arguments", if only because
when invoking a Lisp implementation via `cl-launch`,
the process' `argv[0]` may not be available or meaningful,
whereas the user arguments may be only a subset of the actual process' arguments.)
Both `cl-launch` and `buildapp` have similar functionality
to handle multicall binaries à la [Busybox](http://busybox.net/),
with the same incompatibility as above.
#### System Connections
Sometimes, a system can provide an extension to another system.
For instance, if you use both `metacopy` and `contextl`,
you may be interested in some system `metacopy/with-contextl`
that creates synergies between these two systems.
There exists a system `asdf-system-connections` that will allow you
to define such system connections that are *automatically* loaded
when both the connected systems are loaded.
While I debugged that mechanism and made sure it works with ASDF 3,
I recommend against using it, because it introduces side-effects within the build.
Instead I recommend explicitly loading the system connections
as part of the larger system that will use them.
More Elaborate Examples
--------------------------------------------------------
### More Elaborate Uses of ASDF
#### force
Sometimes, you want to force ASDF to re-build some system.
At those times, you can pass the `:force` argument to `asdf:operate`
(or its wrappers `asdf:load-system`, `asdf:test-system`, `asdf:oos`, etc.).
Passing an argument `t` will force rebuild of just the system, and none of its dependencies
(and that also means none of the dependencies that happen to be secondary systems
with the same primary system name).
Passing a list of system designators (preferably lower-case strings)
will force the specific systems to be rebuilt (if they appear in the build plan at all, that is).
Finally, passing `:all` as argument will force a rebuild of everything, including all dependencies.
Thus, if you ran tests that use the `prove` test framework,
in which loading the files is itself the test,
and you want to force a re-run, even though ASDF might be satisfied
with already having loaded the files, then you can use:
`(asdf:load-system :clack-test :force t)`
Note that it is strongly recommended to not have any non-determinism or side-effects
that are not declared to ASDF, that would cause the forcing to be meaningful.
Forcing is thus a debugging feature for ASDF systems that fail this good practice.
In the case of `prove`, we will have to work with its author so that the correct way
to use it doesn't violate ASDF invariants, but instead properly declare that
ASDF should not consider tests already run.
#### force-not
The converse of `:force` is `:force-not`, and you can specify a list of systems to not rebuild.
In this context `t` means "everything but this system" rather than " this system".
`force-not` takes precedence over `force`, and by default includes a list of "immutable" systems
that may be used when delivering extensible applications to customers
(See function `asdf::register-immutable-system`).
Note that these flags are only for use by the user at the toplevel.
You MUST NOT call `asdf:operate` with `:force` or `:force-not` from within a build.
Actually, you should probably not explicitly use `asdf:operate` at all,
except maybe inside a `.asd` file in cases where `defsystem-depends-on` isn't sufficient.
#### Require
You SHOULD NOT use `cl:require` as a substitute for `asdf:load-system`.
You SHOULD NOT use `asdf:require-system` except at the toplevel.
Back in the days of ASDF 1, a convenient hook was added to ASDF
so that when you call `cl:require`, it would try to load the named system,
and if not fall back on the builtin require mechanism.
This was a cool hack, and when you merely wanted a dependency, it was easier to type
`(require :foo)` than `(asdf:operate 'asdf:load-op :foo)` as you then had to.
Moreover, on SBCL where ASDF was developed,
ASDF itself was used to compile and load SBCL modules at runtime,
so this hook came naturally.
As ASDF maintainer, I now consider this in bad taste:
* First, this hook is not 100% portable, so it is bad taste to recommend relying on it.
* Second, `cl:require` has a mechanism for loading things only once by checking `cl:*modules*`
which may subtly interfere with ASDF's mechanism for keeping things up to date.
* Third, it interferes with ASDF's capacity to detect legitimate vs illegitimate
recursive uses of `operate` at places that defeat tracking of dependencies.
* Fourth, it adds a lot of complexity for dubious gain: at a time you had to type
`(asdf:operate 'asdf:load-op :foo)`, `(require :foo)` may have been a nice short-hand,
but it isn't such a great gain over `(asdf:make :foo)`.
* Fifth, SBCL now uses ASDF 3's `compile-bundle-op` to create a fasl
during the build of SBCL itself, and that fasl can latter be loaded at runtime without ASDF.
Therefore the hook has no natural use anymore.
Similarly, in ASDF 2.21 I added a function `require-system`
that used to called `load-system` with `:force-not (already-loaded-systems)`,
which was a nice hack at the time, that I latter used as part of the `cl:require` hook.
That was all a big mistake, as `:force-not` interferes with the ability to keep a coherent plan
across recursive uses of `asdf:operate` as required by builds that involve `:defsystem-depends-on`
and other ASDF extensions.
These days, this function only checks whether the requested component is already loaded,
and if not calls `asdf:load-system` on it.
This function MUST only be used at the toplevel, never in a script or build.
It may be deprecated in a future version of ASDF.
### More Elaborate System Definitions
#### package-inferred-system
When you start writing large enough systems,
putting everything in one big package leads to a big mess:
it's hard to find what function is defined where, or should be defined where;
you invent your own symbol prefixing system to avoid name clashes;
totally unrelated things end up in the same mother-of-all package;
you divide your mother-of-all package into a few subpackages,
but as the software keeps growing each of these packages in turn becomes too big.
Meanwhile, as you grow large enough libraries, you find that you loading
a big library just to use a small part of it becomes a big hassle,
leading to code bloat, too much recompilation, too much re-testing,
and not enough understanding of what's going on.
A solution to both these problems is the "one file, one package, one system" style,
once spearheaded by faslpath and quick-build, and now available as part of ASDF
(since ASDF 3.1, 2014) using the `package-inferred-system` class.
Following this style, your top `.asd` file defines uses this class for its primary system
(you can still define secondary systems with different classes).
Then, any secondary system, if not explicitly defined,
will be searched for in a file as named by the secondary system suffix,
under the directory that contains the system definition file.
Thus, if `~/common-lisp/foobar-1.0/foobar.asd` defines
a primary system of class `package-inferred-system`,
but no secondary class `foobar/x/y`, then ASDF will look for a file
`~/common-lisp/foobar-1.0/x/y.lisp` to contain this system.
That file will be a regular Lisp file,
that will begin with a `defpackage` or `uiop:define-package` form.
(The latter form is more friendly to live upgrades,
but also allows to use a mix of packages with a priority on symbol conflicts,
or to reexport imported symbols.)
Dependencies for this system will be deduced from the `:use`,
`:import-form` and `:shadowing-import-from` clauses of that `defpackage`,
where each package name is downcased and interpreted as a system name,
unless registered otherwise via `asdf:register-system-packages`.
This allows for large modular libraries, wherein you may use one file,
and only that file and its transitive dependencies will be loaded,
rather than the entire humongous library.
This also helps you enforce a discipline wherein it is always clear in which file
each symbol is defined, which files have symbols used by any other file, etc.
#### Using ASDF Extensions
If you need an ASDF extension, the recommended way is to use `:defsystem-depends-on`.
The extension will define new classes of operations or components, new functions, etc.
If it defines them in the ASDF package, you can refer to them using a keyword of the same name,
e.g. `:cffi-wrapper-file` for one of the component classes defined by system `cffi-grovel`,
`:static-program-op` for one of the operation classes defined by `cffi-toolchain`, or
`:f2cl-system` for the system class defined by system `f2cl`.
Otherwise, you can refer to them using a string that when read yields the symbol, e.g.
the system `asdf-finalizers` defines a function that you can use as an around-compile hook
for your system using the clause `:around-compile "asdf-finalizers:check-finalizers-around-compile"`.
You cannot usually specify the qualified symbol directy, because it lives in a package
that hasn't been defined yet at the time the `defsystem` form is read.
Sometimes, you may want to use several build extensions at once,
but a given system, smaller component or operation, can have only one class.
You may split that system in two (say, a primary system and a secondary system)
so each has its own extension (say, make the primary system a `package-inferred-system`,
but have a secondary system be a `program-system`).
For more advanced cases, you may have to define a class that inherits from multiple other classes
in your own extension.
(In a prototype OO system, you could just mix and match extensions without defining a new class,
but CLOS is not a prototype OO system.)
#### Code in .asd files
ASDF currently allows arbitrary Lisp code in a `.asd` file.
I would like to deprecate that in the future to make ASDF more declarative.
In the meantime, here are some guidelines for how to write such code properly.
First, you SHOULD minimize the amount of such code and
you SHOULD strongly consider defining an extension
in a separate `.asd` file that you `:defsystem-depends-on`.
Then, `.asd` files are read with the current package being `asdf-user`.
You MAY use any symbols defined in packages `cl`, `asdf` and `uiop`,
and you SHOULD stay in package `asdf-user` if it suffices;
you SHOULD NOT needlessly create a package for your system definition file
if you're not going to define any such function nor variable nor macro.
But you MUST NOT pollute that package with bindings that could clash with uses by other systems.
It is poor taste to define functions, variables or macros in package `asdf-user`,
unless strictly necessary or widely useful, and even then with a long name
that distinctively includes the name of your system.
However it is perfectly acceptable to define methods on existing functions,
preferably using the `:perform` syntax used above, as part of a `defsystem` form.
If you must define new functions, variables or macros,
you MUST define a new package in which to define them.
That system would typically be named `foobar-system`
and would export the relevant symbols, as in:
(defpackage :foobar-system
(:use :cl :asdf :uiop)
(:export #:my-foobar-class ...))
(in-package :foobar-system)
That said, if you need more than trivial definitions,
and if these definitions ever need to be used by others,
it is appropriate to move them to their own system.
Also, it is poor taste to define symbols used in the system itself (e.g. `*version*`)
since the system then depends on ASDF and cannot be directly built using Bazel,
or some other future build system.
For versions, consider having ASDF extract the version from a file, as in
`:version (:read-file-form "variables.lisp" :at (2 2 2)`.
See the ASDF manual for details, and `asdf.asd` itself for an example.
#### Conditional Code
The recommended way to conditionally use code is to rely on the CL features;
yet, you SHOULD NOT use read-time conditionals if you can avoid it,
and instead use the ASDF 3 `:feature` and `:if-feature` features:
* To conditionally depend on another system or module,
specify as a `:depends-on` argument something like `(:feature :sbcl (:require :sb-introspect))`
or `(:feature (:or :ccl :sbcl) "bordeaux-threads")`.
* To conditionally enable a component,
specify a `:if-feature` argument to it like `(:file "sbcl-support" :if-feature :sbcl)`
Note that the feature expressions MUST use keywords, not symbols in the current package
(unless you're pervert enough to make `:keyword` your current package).
Also note that ASDF at this time wants all the component classes to be defined,
so if your component classes are conditionally defined, you may have to resort back
to the otherwise deprecated use of read-time conditionals, as in:
(defsystem "foo"
:defsystem-depends-on ((:feature :sbcl "some-sb-magic"))
:components (#+sbcl (:sb-magic-file "some-magic")))
If the condition you want to express doesn't have a corresponding `*features*` keyword,
you MAY use a `(when ... (pushnew :my-keyword *features*))` form to add a feature keyword for it.
However, you SHOULD NOT needlessly push new features;
in particular, the mere fact of having loaded your system does not warrant a new feature.
A feature is only warranted if your system is some deep infrastructure
with mostly compatible rivals that it needs to be distinguished from.
### More Elaborate Testing
You MUST NOT call `asdf:operate` or any of its derivatives,
such as `asdf:load-system` or `asdf:test-system` from within a `perform` method.
Instead, you SHOULD declare proper dependencies between actions using methods on
`component-depends-on`, or more simply using an `:in-order-to` clause in your `defsystem` form.
You MUST NOT call `asdf:clear-system` or in any way interfere with the build
while in a `perform` method.
You SHOULD NOT define methods on `asdf:operate` --- most of the time it's totally the wrong thing
because users would *not* be "operating" on *your* system, but on *their* system that depends on it.
Instead you SHOULD define methods on `asdf:perform`, `asdf:component-depends-on`, etc.
### Defining ASDF Extensions
#### Source File Types
You MUST NOT define methods on `source-file-type`.
This bad ASDF 1 interface must die and will be removed in a future version of ASDF.
Instead, override the slot `type` for your file class and provide a proper `:initform`, as in:
(defclass cl-source-file.l (cl-source-file) ((type :initform "l")))
You can then provide the name of that class as class name for individual components,
or as `:default-component-class` to relevant systems or modules.
#### Conditional Outputs and Conditional Perform
An operation MUST actually create all the outputs declared by the `output-files` method.
If some of these outputs are conditional, the `output-files` method MUST check the condition
and remove uncreated outputs from the list.
If some output is sometimes non meaningful but that is only known after calling the `perform` method,
it is sometimes appropriate to create an empty file instead of not creating the file.
If you conditionally avoid performing an action altogether using an `:around` method,
you MUST still call `mark-operation-done` on the action in the branch of the method
where the action is not performed.
In that case, both the `output-files` and `input-files` methods
should probably return `nil` when that condition is met.
Alternatively, if avoiding some actions is uniform for all
operations on a given component, you MAY want to override or wrap around
the `component-if-feature` method for that component instead of defining
all those `perform`, `output-files` and `input-files` methods.
Other
--------------------------
### Syntax Control
Do not side-effect the current `*readtable*`,
which is never guaranteed to be writable, and
may not be what is current when you need the modification.
If you need modifications to the readtable, use `named-readtables`,
`reader-interception`, or some other adequate mechanism.
To bind the readtable, use `named-readtables:in-readtable` or `cl-syntax:in-syntax`
in each file that needs a non-standard readtable, and/or use an `:around-compile` hook
to automatically bind it around every file in a module or system.
See the syntax-control document (in the syntax-control branch if it wasn't merged yet).
### Using ASDF Internals
At times, you will have to use some ASDF internals to get your software to work.
When this happens, follow these rules to minimize the breakage associated to bitrot:
* You MUST use the `asdf::` package prefix rather than `asdf/foo:`
to name the symbols internal to ASDF.
Indeed, from one version of ASDF to the next,
which internal package a symbol will reside in may change;
for instance `asdf/find-system:primary-system-name` recently became
`asdf/system:primary-system-name`
(it is still present, not exported, in the former system);
but it is always present (though not currently exported) in package `asdf`.
* When you use internals, you MUST notify the ASDF maintainers, and request
that they either export the symbol and support the API, or
offer an alternative API more to their liking for the same functionality.
Otherwise, they will be justified in modifying internals
that no one is supposed to use, and they will blame you when
they later change or remove these internals and your software breaks.
Note that the latter point is true of all software, not just ASDF.
asdf-3.3.4/doc/cclan.png 0000664 0000000 0000000 00000025131 13621551153 0014775 0 ustar 00root root 0000000 0000000 PNG
IHDR S , [T gAMA a IDATxyյ?zz6aDEP\\ qHܣF_~Q&LD5Dcb\@O42"\ ʰLuTU]kcֹu.{(
](p<
i(p<
i(p<
i(p<
i(p<
i(p<
i(p<
i(p<u/yzOJ=PG,J+NY?gϣ*YDpN2qS~ݹ@*οGc{{$m[Kﴀ_1&I/+NKKm+ܧ&
$<66\:Or_ˑ/|lJheR4}}
sɔc
/uZ~M͘<8S4[k8=}rм$Zϒ_Ckw5>*T|Յcڭg='RO1$0I'_iݞ)_/rG?NJo6w&;TJeF˟l}괬y-w7w"VˀtcU'}ؚhoўTul&lȌ'qPAj/:3M?
(:P2JCD,d d$b?\n{im4p;\[>Wܣ.q|Rt--}_jSL+f5DrN37i*6vl{W9j~9~s)- $ҕ%
I9I@(*| 1eJ@Cä+bFCǍ~BJQ
/iRH?tՐ̑c_Ĩ<3-8'=w#zF,Aآ;{RD<{
uĝJ힋'"o{ev{8ip`_xENE%յxe}%K]Ӂpޓ>j{ꄓͳYiTWV:䌓{_ۿ;fzÃ;sYrӆ`z=c S نNۅhY+ otSW+"bLI)ڂ"9qODDzc{<4\/}Gō^04fVX@N Pj[\J0GyczO:μC0stW^`5Jc
heq'gx%kYiK~; fv0P7XvG*)_X/HƇl Q!tfH⨛gUQ?%Vˏ[(ض`9i6T [,"H-Nܯ)kf{a4^,:p-
Fpj drh@&k4z7yB@? ״n5Pi?}#sį_Tvq(p l HFrtKR6fьh&ߧ_E`0 +Bx @@{6JOG-YZ9MB Z:68qZ R<}AC:A|27ښ9m$E{3@a ,&[w40i]