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

[Jim Meyering]

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?

> early in PATH.  Also, maybe we could add a configure option to have the
> Automake-NG "make install" to do this automatically.  That could be easily
> done in a follow-up patch.

Assuming you want to be able to install the -ng versions in
the same directory as the non-ng version, then perhaps a name change
is inevitable.  An alternative would be to add say, an --ng option,
that would dispatch to the right tool under the covers.
This would of course require coordination with the non-ng automake, and
would require some reorganization.  Maybe not worth the hassle now,
but the --ng functionality does feel conceptually more like an option
than like a separate program.  It's "only" the implementation details
and maintainability of the forked code that are encouraging the separation.

> Anyway, I think that such an inconvenience for the early adopters will be
> a more than fair price to pay in order to avoid confusion and more bad
> reputation for the autotools ("Gahhh, they have broken Automake backward
> compatibility *again*!  I'm switching to CMake now!").
>
>> Either they will have to rename the tools to remove the -ng suffix
>> or somehow update all scripts that invoke "automake" and "aclocal"
>> to use the new names.
>>
> In tho longish term, I want to add a new option 'ng' recognized only by
> Automake-NG, and then patch autoreconf to invoke 'aclocal-ng' and
> 'automake-ng' when it sees this 'ng' option in the AM_INIT_AUTOMAKE
> call (patch for the first step coming up soonish, likely tomorrow).
> Do you think this would be an acceptable route?

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.

>> 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.