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