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

[Dave Hart]

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?

> Mainline Automake used to follow the chain of user-defined pattern rules

s/used to follow/follows/

> to determine how to build the object file deriving from a source file
> with a custom user extension; for example, upon reading:
>
>     %.cc: %.zoo:
>             $(preprocess) $< > $@
>     bin_PROGRAMS = foo
>     foo_SOURCES = bar.zoo
>
> automake knew that it has to bring in the C++ support (compilation rules,
> requirement for AC_PROG_CXX in configure.ac, etc), and use the C++ linker
> to link the 'foo' executable.
>
> But after the present change, automake *won't follow those implicit
> chains of pattern rules* anymore; so that the idiom above will have to
> be re-worked like follows to preserve its intent and behaviour:
>
>     %.cc: %.zoo:
>             $(preprocess) $< > $@
>     bin_PROGRAMS = foo
>     # The use of '.cc' is required to let Automake know to bring in
>     # stuff for the handling of C++ compilation, and to use the C++
>     # linker to build 'foo'.
>     nodist_foo_SOURCES = bar.cc
>     EXTRA_DIST = foo.zoo
>
> Finally, we must note another, slightly annoying first consequence of
> this change of semantics: one can't use anymore "header files" with
> extensions unrecognized to Automake anymore; for example, an usage like
> this:
>
>    # Won't work anymore: will cause errors at make runtime.
>    %.h: %.my-hdr
>          $(preprocess-header) $< >$@
>    foo_SOURCES = foo.c bar.my-hdr
>    BUILT_SOURCES = bar.h
>
> will cause the generated Makefile to die on "make all", with an error
> like:
>
>    make[1]: *** No rule to make target 'bar.o', needed by 'zardoz'.  Stop.
>
> while an usage like this:
>
>    # Won't work anymore: will cause errors at automake runtime.
>    %.h: %.my-hdr
>          $(preprocess-header) $< >$@
>    foo_SOURCES = foo.c foo.my-hdr
>    BUILT_SOURCES = foo.h
>
> will cause automake itself to die, reporting an error like:
>
>    object 'foo.$(OBJEXT)' created by 'foo.my-hdr' and 'foo.c'
>
> We don't believe the above breakage is a real issue though, because
> the use case can still be served by placing the "non standard" headers
> in EXTRA_DIST rather than in a _SOURCES variable:
>
>    # This will work.
>    %.h: %.my-hdr
>          $(preprocess-header) $< >$@
>    foo_SOURCES = foo.c
>    EXTRA_DIST = foo.my-hdr
>    BUILT_SOURCES = foo.h

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 the latter case, I
suggest considering deferring backwards-incompatible changes until
after the first few releases to ease transition to Automake-NG.

Cheers,
Dave Hart