I'm having two issues with the new testing scripts:
1. The testing code is bleeding quicklisp into context:
make test
./make.sh l='' L='' u='' U='' v='' s='' t='' test
> Error: System "cl-scripting" not found
> While executing: (:INTERNAL QUICKLISP-CLIENT::RECURSE
QUICKLISP-CLIENT::COMPUTE-LOAD-STRATEGY), in process listener(1).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Try again
> Type :? for other options.
1 >
I *definitely* did not ask to be using quicklisp when testing.
This error arises inside (LOAD-SYS "asdf-tools"), which is redirected to
use quicklisp:
(defun load-sys (system)
(if (featurep :quicklisp)
(let ((*standard-output* (make-broadcast-stream))) ;; be quiet
(symbol-call :ql :quickload system))
(load-system system :verbose nil)))
This is done by tools/load-asdf.lisp
AFAICT, this is done UNCONDITIONALLY BY LOAD-AND-CONFIGURE-ASDF
This should not be. The user should get quicklisp only upon request: we
added the dependencies to ext/ in order to make the ASDF distribution
free-standing and avoid the quicklisp requirement.
In my case, I use quicklisp only sometimes, and never yet with CCL, so
having the ASDF test script go poking around for a QL installation and
firing it up without asking me was problematic. Particularly
problematic was that there's no (apparent) way to STOP the ASDF scripts
from doing this.
For now I am going to push a modification that comments out
TRY-LOAD-QUICKLISP from LOAD-AND-CONFIGURE-ASDF.
I have no objection to a patch that provides an *explicit option* to
load from QL, but it must be an option, and it must not be the default.
Frankly, even then I'm not excited about it. I don't want to have
bugreports to ASDF that are caused by issues in Quicklisp. I'd rather
people stick to using the dependencies in our submodules.
2. This was just a nuisance: three new submodules have been added, and
"git submodule init" must be re-run when that happens.
I have no idea why the git maintainers thought that a call to git
submodule update should quietly fail to update un-initialized submodules
(fail to update yes, QUIETLY fail to update, no). But going forward we
need to trumpet any changes to the submodules because of this attribute
of git....
Cheers,
r