Faré wrote:
On Tue, Sep 2, 2014 at 9:00 AM, Robert P. Goldman rpgoldman@sift.info wrote:
Kambiz Darabi wrote:
I don't know how many people are devs and how many people just 'users' in the sense that they clone the repo and use it without caring about the dependencies of asdf.
But your point is definitively valid.
Actually, Kambiz's point is a good one, and it illustrates a real problem with the minimakefile branch.
With the old makefile, all someone needed to do if they were to checkout and test ASDF was to grab the git repo, and type
make test l=<my lisp>
Now this process is substantially more complicated because now the user will have to go to substantially more work to get our not extensively tested CL infrastructure up and running.
Uh? Either he has a source-registry with dependencies, or he has quicklisp, or he can "make dependencies", which can be mentioned in the README.
That's one easy extra step, if he doesn't use quicklisp and isn't an advanced user who otherwise checked out all dependencies, either. It requires git, but so did checking out asdf.
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?
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.
We should seriously consider revising the minimakefile so that testing does not require CL scripting, but instead goes back to using make and bash alone.
Well, a make dependencies target should certainly be available that doesn't require CL scripting, but the whole point of this branch is CL scripting.
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