[asdf-devel] summary proposal for COMMON_LISP_PATH and system search changes
james.anderson at setf.de
Sun Sep 27 13:50:40 UTC 2009
On 2009-09-27, at 15:16 , Gary King wrote:
> Here is a summary of what I've heard and what I think we should do.
> # Proposal Summary
> ## default value for *central-registry*
> COMMON_LISP_PATH environment variable with syntax like
> This is used by ASDF to help build the default value for
> If not specified, `*central-registry*` defaults to (on
> *nix-like systems):
> (make-pathname :directory '(:relative ".common-lisp"))
> (make-pathname :directory '(:relative ".local" "share"
> (make-pathname :directory '(:absolute "usr" "local" "share"
> (make-pathname :directory '(:absolute "usr" "share" "common-
please have the initialization process filter this to remove anything
for which probe-file fails.
> (The last two would need to be different for Windows-based
> ## modification for `sysdef-central-registry-search`
> Currently `sysdef-central-registry-search` searches in the
> top-level of each directory in `*central-registry*` to find
> systems. If we use the above, then a more useful approach
> would be to search in the top-level and in a sub-directory
> named `systems`. An even more useful approach would to search
> in all sub-directories of each entry.
if you intend to take the trouble to do this, please consider a
convention which treats system names as path components. if they are
taken to denote the tail end of the path (ie. as jave package names),
it is possible to unambiguously store and locate the entire lisp
world in a single source tree.
yes, i realize, this is not the way most people use asdf now.
> ## configuration file
this one confuses me. which process is it intended to effect, which
cannot be effected by the contents of the runtime's respective
initialization file and the respective .asd file(s)?
> When ASDF starts, it will:
> 1. setup `*central-registry*` using its own defaults and the
> `COMMON_LISP_PATH` environment variable.
> 2. look for (and load if it is found) a file named
> `asdf-config.lisp` in each of these paths traversed in
> _reverse_ order (so that user settings take precedence overs
> system ones). Note that the ASDF package will exist when this
> file is read.
? what does this load order accomplish which the load order of the
runtime init and the respective .asd files does not?
More information about the asdf-devel