Faré wrote:
My latest procrastination was to convert the ASDF Makefile and supporting build and test scripts to CL.
I fear that this will sound crabby, but.... I am not very happy with this new makefile as a maintainer user interface.
With the old makefile, I could look at the makefile and guess what the targets were that I wanted.
Better yet, as I got a relatively ok memory for what the targets were, bash completion would help me out.
The new Makefile, on the other hand, has essentially no affordances. At least not beyond "make". E.g., is "make test-all-no-upgrade" still provided? There's no way to tell.
Since there's not an API that will be called, the asdf-tools package.lisp file is empty. So there's no obvious place to begin to look for what commands to issue. Must we just read over the twelve lisp source files to figure out how to use the lisp functions? And how to invoke them through make?
And what happens to the old make variable processing?
./tools/asdf-tools make-target $@ l="$l" L="$L" u="$u" U="$u" v="$v" s="$s" t="$t"
this really isn't at all meaningful (I can guess -- but only based on past experience -- that l is the lisp implementation and t is a test name; other than that, I'm lost).
This also gives us the union of all possible arguments, instead of cueing the user about which arguments are wanted for which commands.
IMO we are better off, as the saying goes, "in for a penny, in for a pound." If one wants to replace the original makefile with lisp scripting, that lisp scripting (a) should be invoked from the shell with no make scrim in between; (b) should offer entry points, probably modeled on multiple entry point programs like git and svn ("asdf-tools help", "asdf-tools help test", etc.); (c) should have a bash completion script with it ("asdf-tools t<TAB>" ==> test, test-all, test-no-upgrade, etc.).
That said, while I'm sure that a halfway solution won't work, I'm not convinced that it's worth rewriting this into CL (although it's an interesting exercise).
I'm still skeptical: before lisp is ready for prime time scripting, it needs a *much more terse* way of specifying pathnames, at least as good as globbing; interaction with regexps in a less bloated way than PPCRE; and much more terse and transparent subprocess interaction (it's hard to beat "foo | bar"). Oh, and a backtrace facility where we don't have more than half the backtrace cluttered with pointless meta-trivia about the backtracing process, rather than with information about the error in question.
You have done stellar work giving CL the tools it needs to be a scripting language. But it still doesn't have syntax optimized for scripting, and the interaction between the shell and CL is still a lot more fussy than I'd like.
Getting that syntax done and right is a very interesting process, but not one I'm willing to interleave with my ordinary workaday tasks.
Cheers, r