automake-ng
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Automake-ng] [PATCH] [ng] maint: rename automake -> automake-ng, ac


From: Stefano Lattarini
Subject: Re: [Automake-ng] [PATCH] [ng] maint: rename automake -> automake-ng, aclocal -> aclocal-ng
Date: Sun, 15 Apr 2012 17:23:59 +0200

On 04/15/2012 02:00 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
>> On 04/14/2012 08:35 PM, Jim Meyering wrote:
> ...
>>> Hi Stefano,
>>>
>>> Won't this cause trouble for those who want to use the new tools?
>>>
>> Yes, unless they create a couple of symlinks:
>>
>>   automake -> automake-ng
>>   automake-0.5a -> automake-ng-0.5a
> 
> If you change the names, is there still justification for the smaller
> version number?
>
Yes; see below, at the end of my reply.

But I'm less and less convinced that changing the names is a good move
at this point -- too much churn to avoid such a small source of possible
confusion...

Moreover, the present patch shows that such a renaming can be done with
little fuss and churn for what concerns the changes required to the
automake source tree; so the patch can be easily resurrected at a later
time, when (if ever) we feel that the renaming is truly warranted.

So, I say we drop this change and this discussion for the moment.  OK?

> Alternatively, you could make it so automake (the ng version) stops 
> immediately
> unless there is an "ng" option in configure.ac's AM_INIT_AUTOMAKE(...) list?
> Then, there is no risk of using automake-ng on a project that does not
> explicitly request it, and there is no need to pollute autoreconf
> with the "-ng" suffix.
>
This is a nice idea, easy to implement, and with little churn.  Will do.
Thanks.

>>> I would prefer to leave the names unchanged.
>>>
>>> For the record, I tried automake/aclocal built from the ng branch in
>>> cppi today.  Here is the very first change that was required in order
>>> to make it so ./bootstrap no longer failed:
>>>
>>> [I would have much preferred to see that automake-ng uses a much larger
>>>  version number.  With the obligatory decrease to 0.5, I am forced to
>>>  let all older versions of automake pass these prereq tests.  ]
>>>
>> Some people are quite jumpy at the idea that we might try to force
>> Automake-NG on them through either a confusion of names or a dirty
>> trick with version numbers:
>>
>>   <http://lists.gnu.org/archive/html/automake-ng/2012-02/msg00024.html>
> 
> Yes, I remember that thread.
> I'm surprised that you would present this case (one person's fear that
> classic automake would be left unmaintained) as justification for the
> version numbering scheme.
>
Actually, what I find justified is the OP's misgiving that we might want to
"forcibly" co-opt the current Automake user base by tricking/enticing them
with an higher version number.  He had a valid point there, albeit expressed
with unwarranted aggressivity.  If Automake-NG is to take over, that must be
for its quality and features, not because the Automake developers (ab)use
their position to push for it.  Then, if such an Automake-NG *earned* success
has a final consequence the stagnation of Automake, I'd see no problem with
that either; but it's pointless starting mulling about that *now*.

Regards,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]