From: Daniel H. <dhe...@te...> - 2009-11-08 07:11:50
|
There is some custom SBCL hackery in ASDF. Most of it is good, but I don't understand a couple details. The first issue is a funny conditionalization. "" #+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? Would it be ok to change this to "" #+sbcl (progn ... "" ? This issue comes up when directly loading asdf.lisp into SBCL at runtime; under most circumstances, the env var is not set. 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. 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. Thanks, Daniel |
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 |
From: Faré <fa...@gm...> - 2009-11-10 21:32:24
|
2009/11/10 Nathan Froyd <fr...@gm...>: > I think this is done to prevent things from being pushed onto > *CENTRAL-REGISTRY* multiple times. Should be using pushnew :test 'equal instead. > (let* ((defaults (typecase dir > ((symbol function) (funcall dir)) > (t (eval dir)))) If you do something like that, please distinguish the NULL case as a symbol NOT to funcall. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Philosophy is questions that may never be answered. Religion is answers that may never be questioned. |
From: Daniel H. <dhe...@te...> - 2009-11-12 06:23:54
|
On Tue, 10 Nov 2009, Nathan Froyd wrote: > 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. If that's the case, I agree with Faré that we should simply use ":test 'equal" with all the pushnew's in this section. >> 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. Ok. Some digging around found sb-int:sbcl-homedir-pathname. It also appears that SBCL_HOME always matches the core location, except when we have an ":executable t" embedded core. ASDF is replicating most of sb-int's function. Starting a new thread on this topic. - Daniel |
From: Daniel H. <dhe...@te...> - 2009-11-12 06:27:27
|
Could this be exported as sb-ext:sbcl-homedir-pathname? Some sbcl-specific parts of asdf.lisp use the magic SBCL_HOME environment variable to incompletely replicate this function (only sb-int uses parse-native-namestring). Thanks, Daniel |