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
path[;path]*
This is used by ASDF to help build the default value for `*central-registry*`.
If not specified, `*central-registry*` defaults to (on *nix-like systems):
(list *default-pathname-defaults* (merge-pathnames (make-pathname :directory '(:relative ".common-lisp")) (user-homedir-pathname))) (merge-pathnames (make-pathname :directory '(:relative ".local" "share"
"common-lisp")) (user-homedir-pathname))) (make-pathname :directory '(:absolute "usr" "local" "share" "common-lisp")) (make-pathname :directory '(:absolute "usr" "share" "common- lisp")) )
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 systems.)
## 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:
- setup `*central-registry*` using its own defaults and the
`COMMON_LISP_PATH` environment variable.
- 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?
[...]