Issues with new testing scripts

[Robert Goldman]

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