On Sat, May 26, 2012 at 5:22 PM, Stefano Lattarini <[email protected]> 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
