[Asdf-devel] Problem with Minimakefile branch -- was Re: Merging experimental-submodules

[Robert P. Goldman]

Faré wrote:
> On Tue, Sep 2, 2014 at 9:00 AM, Robert P. Goldman <rpgoldman at 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