Re: [Sbcl-devel] Q: SBCL details in ASDF

[Nathan F. <fr...@gm...>]

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