Re: [Automake-NG] [PATCH] [ng] suffix: drop Automake-time chaining of suffix rules

[Stefano Lattarini]

On 05/27/2012 06:29 AM, Dave Hart wrote:
> On Sat, May 26, 2012 at 5:22 PM, Stefano Lattarini
> <address@hidden> wrote:
>> This change simplifies the Automake::Rule module a little, moves yet
>> more logic from Automake runtime to GNU make runtime (in the spirit of
>> Automake-NG), and gets us rid of some never-documented nor completely
>> specified Automake magics.  OTOH, it also breaks some idioms that, while
>> only relevant for uncommon cases, have been working since the first
>> Automake releases.  Still, it is easy to slightly modify those idioms to
>> have the use cases they were catering to correctly handled with the new
>> semantics (examples of this are given below); the only downside being the
>> need of a little more verbosity and explicitness on the user's part.
>>
>> So, with the present change, automake starts using a much simpler and
>> dumber algorithm to determine how to build an object associated to a
>> source whose extension in not one of those it handles internally.
> 
> Does this simpler and dumber algorithm benefit developers or end-users
> of Automake-consuming projects?  For example, does the simpler
> algorithm avoid particular perils of the traditional approach, or
> simplify handling of unhandled filename extensions for Makefile.am
> maintainers?
>
Nope; it simply removes the special handling of a corner case whose
implementation couldn't possibly be moved at make runtime.  In this
particular case at least, I believe such a move is acceptable, because
the use case covered by the removed feature can still be served by
Automake-NG, only requiring some minor editing of the user's Makefile.

>> Mainline Automake used to follow the chain of user-defined pattern rules
> 
> s/used to follow/follows/
>
Fixed, thanks.

> [SNIP]
> 
> I am not using Automake-NG at this point, but I am interested in
> following its development just in case mainline Automake earns the
> past tense.  I wonder whether breaking existing Makefile.am practice
> here is counterbalanced by some benefit to developers using
> Automake-NG or their end-users, or if the benefit is solely in
> simplicity and maintainability of Automake-NG.
>
In this case, the latter.

> In the latter case, I suggest considering deferring backwards
> incompatible changes until after the first few releases to ease
> transition to Automake-NG.
> 
Generally, this is a good policy; but then, I also see the Automake-NG
effort as a good occasion for cleaning up a lot of obsoleted features,
half-undocumented behaviors and corner cases, and handling of special
cases that could as well be handled by mainstream features instead (some
of which might not have been available when the code handling those
special cases was written, explaining the apparent duplication).  The
present situation falls squarely in the last two categories IMHO, so I'd
rather go ahead and apply my patch...  After I've written a NEWS entry,
which I see I've forgotten in my original patch!

Thanks,
  Stefano