Re: [Automake-NG] [PATCH] [ng] silent: simplify by taking advantage of GNU make semantics

[Stefano Lattarini]

On 06/18/2012 04:31 PM, Dave Hart wrote:
> On Mon, Jun 18, 2012 at 9:54 AM, Stefano Lattarini
> <address@hidden> wrote:
>> In particular, taking advantage of the fact that, in GNU make, command
>> line override of variables is propagated to recursive make invocations.
>>
>> This change offers us a small but nice size reduction bot in Automake's
>> code and in the generated Makefiles.  It also improves the API to define
>> custom silent "tags", by turning it from:
>>
>>    pkg_verbose = $(pkg_verbose_$(V))
>>    pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_V))
>>    pkg_verbose_0 = @echo PKG-GEN $@;
>>
>> to the slightly clearer:
>>
>>    pkg_verbose = $(pkg_verbose/$(V))
>>    pkg_verbose/1 =
>>    pkg_verbose/0 = @echo PKG-GEN $@;
> 
> While the second form is slightly simpler, as a package maintainer I
> doubt I'd praise the elegance of the new approach while I'm reworking
> formerly functional code broken by this change.
>
As an aside (now that I think about it) also something like this:

    pkg_verbose = $(pkg_verbose_$(V))
    pkg_verbose_1 =
    pkg_verbose_0 = @echo PKG-GEN $@;

should still be a valid use of the new APIs -- and more similar to the
idiom required by the old APIs.  But of course, it would still require
a manual adjustment, so your main point remains.

> Think about what the term "API" means:  A stable interface offered to
> third parties.  Improving the API in my book would mean offering the
> simpler alternative _without_ breaking the existing API.
>
But Automake-NG doe not pretend to be backward-compatible; trying to do
so would stifle the project's progress, and remove most of its advantages
for the maintainer (which is the main reason I started Automake-NG), and
also some important advantages for the users (at least those willing to
fully embrace the power of GNU make).

In other words: the Automake-NG APIs will not be, and will not intended
to be, the same as the Automake APIs; they will just be very similar, at
least most of the times for most of the usages.  When they are not --
please refer to the NG-NEWS file.

> This quest
> for simplicity in Automake-NG implementation is in practice producing
> another barrier to those considering a move from Automake to
> Automake-NG.
>
This poses a risk for the Automake-NG final adoption, true; but it's
a risk I've been willing to accept since "day one" (when we agreed that
Automake-NG was *not* to be Automake 2.0).

> Cheers,
> Dave Hart

Regards,
  Stefano