Originally, I was very concerned to minimize the overhead of
dependencies for building and testing ASDF, and I still think this is
important.
But I now conclude that trying to pull in the cl-scripting
infrastructure was wrong, because it had the side effect of making the
system used for testing be a dependency of the system under test,
introducing unhealthy circularities.
Going forward, if you want to experiment further along these lines, I'd
suggest an entirely separate project -- with its own test suite! -- that
would build an executable capable of executing CL scripts. That
executable would have to NOT require bleeding-edge ASDF capabilities,
only simple core capabilities. It should be built with the ASDF that's
delivered with implementations, not with bleeding-edge ASDF.
That executable could be built, saved, tested, and installed, and then
could be used as the engine for ASDF building, testing, etc., if one
liked. It could be a required build tool, the way today "make" is a
required build tool.
To be honest, I think such an engine should first be tested with much
less demanding problems than building and testing ASDF. Simple
scripting tasks, say within the ambit of the /Perl Cookbook/, would be a
reasonable starting point.
Even doing this, I think there's only a 50-50 chance the approach will
work out. CL's numerous incapabilities where dealing with the host OS
and filesystem will still stand in the way. Committing to a single
implementation -- probably CCL or SBCL -- might solve this problem. A
less cumbersome means of line-by-line processing of streams should be
developed, and some means of using regexp literals should be added.
Variable interpolation into strings should be provided.
Just some thoughts....
Best,
r