On Tue, Sep 2, 2014 at 9:30 AM, Robert P. Goldman rpgoldman@sift.info wrote:
I don't see that as something "substantially more complicated", except maybe that there might be a need for two tarballs, with or without dependencies.
I'm not sure that's true. Have we checked that the make scripts will work on multiple lisps, so that a person who does not have SBCL available (e.g., an ABCL-only user) can run them?
It works for me on ABCL, CCL, CLISP, ECL, SBCL: cl-launch -sp asdf-tools -r entry-point -l abcl -- help
It failed on Allegro, CMUCL, LispWorks, MKCL: Allegro seems to have trouble dumping fare-quasiquote output to fasl. CMUCL fails to upgrade ASDF because of some class redefinition (known issue). LispWorks refuses to print the ellipsis … under the pretext that it isn't a BASE-CHAR. MKCL choked on closer-mop.
I didn't try on GCL, XCL, SCL.
The git arrangement is, in fact, substantially more fussy and complicated than it was in the old days, although I agree that this is probably fixable just by giving instructions to the user.
I pushed some documentation about it to the branch.
But the whole point of ASDF is NOT to be a laboratory for experiments in CL scripting. The point of ASDF is to provide a build system for CL.
I am not interested in CL scripting (although I am not opposed to it), so for me to merge this branch, I need it to make my life easier. So far, what does it give me that the current makefile does not? It's going to impose a substantial cost in code review, etc., so I need some payoff.
I understand your interest in CL scripting and, to some extent, sympathize with it. However, I really think you need to move to "sales mode": selling this change not as something that is cool and will advance the cause of CL scripting, but as something that provides functional benefits.
For CL scripting to catch on, it must be successfully sold not only to people who want an excuse to write more CL, but as better than the alternatives. Better in the sense that it's easier to write, and better in the sense that it provides novel functionality (or at least not less functionality).
So what's the sales pitch for the minimakefile? To someone who does not care about CL scripting, but just wants to get his or her day job done? And who already has a tool that more or less gets the job done? I see the cost, but where's the benefit?
Thanks, r
That's a great question.
I would say that the benefits of the minimakefile branch are as follows: * Greatly improved maintainability vs the shell scripting previously in the Makefile and helper script ./test/run-tests.sh * as a side effect of this maintainability, automated consistency between commands to run tests and the printed suggestion on how to reproduce a failing test (they were indeed inconsistent before in some cases... oops). * a list of available commands, with help * much cleaner and more robust dependency loading, that supports quicklisp. * better control over test output, so it doesn't clobber your screen with useless details. * some fixes in debian packaging. * eating one's own dogfood... that's a way of testing, too, I suppose. * the same system can be used in the future to e.g. migrate ASDF tests to use some common CL testing library, and/or other CL libraries in general.
Note that there is already *some* CL scripting in the master branch, but it's not as cleanly done, and didn't cover testing, only releasing. So really, the change in dependencies is only important for testers... and even then, some tests (e.g. test-program, test-run-program, test-encodings) already had semi-hidden dependencies on some libraries (and I see that we currently fail to include asdf-encodings in ext/), so in practice we already have testing dependencies.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org And remember, where you have a concentration of power in a few hands, all too frequently men with the mentality of gangsters get control. History has proven that. ― Lord Acton (1834–1902)