From: Nathan F. <fr...@gm...> - 2009-11-10 19:11:43
|
On Sun, Nov 8, 2009 at 2:11 AM, Daniel Herring <dhe...@te...> wrote: > #+sbcl > (eval-when (:compile-toplevel :load-toplevel :execute) > (when (sb-ext:posix-getenv "SBCL_BUILDING_CONTRIB") > (pushnew :sbcl-hooks-require *features*))) > > #+(and sbcl sbcl-hooks-require) > (progn > ... > > Why is the hook dependent on whether the SBCL_BUILDING_CONTRIB environment > variable is set? ASDF is being loaded either way... If this is to > protect the SBCL_HOME var, why not check that directly? I think this is done to prevent things from being pushed onto *CENTRAL-REGISTRY* multiple times. I don't know the history here, but it looks like this is papering over a bug in SYSDEF-CENTRAL-REGISTRY-SEARCH: *CENTRAL-REGISTRY* specifies that its elements are either pathnames or functions (probably "function designators"), but S-C-R-S accepts arbitrary Lisp forms through its use of EVAL. Changing the reader conditional here would be OK if the things being pushed onto *CENTRAL-REGISTRY* were symbols (easier to check with PUSHNEW). That would necessitate changing S-C-R-S, but I think backwards compatibility could be achieved with something like: (defun sysdef-central-registry-search (system) (let ((name (coerce-name system))) (block nil (dolist (dir *central-registry*) (let* ((defaults (typecase dir ((symbol function) (funcall dir)) (t (eval dir)))) ... Since symbols and functions would have raised errors in the subsequent call to MAKE-PATHNAME anyway. > Which raises my next question. Rather than having ASDF use posix trickery > to find the contribs, would it be possible for SBCL to wrap that > information in a standard API? Then ASDF and other tools could query > stuff like sb-ext:get-sbcl-{home,contribs}-path instead of reimplementing > internal SBCL logic. I think SB-EXT:SBCL-HOMEDIR-PATHNAME (name chosen for parallelism with USER-HOMEDIR-PATHNAME; feel free to suggest a different color for the bikeshed) would be reasonable; I don't think we need the contribs version, though, since the location of home and contribs would be one and the same. > Another question is whether old ASDF stuff gets baked into the contribs, > potentially breaking if the ASDF API changes. But that doesn't worry me > right now. The only ASDF bit(s) that get baked into the contribs would be stuff like the macroexpansion of ASDF:DEFSYSTEM and any methods systems define on ASDF-exported generic functions. -Nathan |