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