[Asdf-devel] Problem with Minimakefile branch -- was Re: Merging experimental-submodules
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.
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.
Best, r
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.
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.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Amateurs talk strategy. Professionals talk logistics. — old military saying
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
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)
-
Faré -
Robert P. Goldman