Next: TODO, Previous: Status, Up: Controlling where ASDF searches for systems [Contents][Index]
Alternatives I (FRR) considered and rejected while developing ASDF 2 included:
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.
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.
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.
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.
I’ve been suggested the below features, but have rejected them, for the sake of keeping ASDF no more complex than strictly necessary.
(:add-directory X) for (:directory X), or (:add-directory-hierarchy X)
or (:add-directory X :recurse t) for (:tree X).
USER-HOMEDIR-PATHNAME and $SBCL_HOME
Hopefully, these are already superseded by the :default-registry
/** instead of TEXINPUTS-like // to specify recursion
down a filesystem tree in the environment variable.
It isn’t that Lisp friendly either.
Next: TODO, Previous: Status, Up: Controlling where ASDF searches for systems [Contents][Index]