Il 21/08/2012 12:10, Stefano Lattarini ha scritto: >>> (AC_SUBST): Define AM_VARTYPOS_WHITELIST to "LIBFFI_EXECUTABLE_LDFLAGS >>> RELOC_LDFLAGS". This is required because Automake-NG is stricter than >>> mainline Automake in its make runtime checks on possible typos in >>> variables like 'foo_SOURCES' and 'bar_LDADD', and that was causing a >>> spurious failure in the GNU Smalltalk build system. >> >> Can Automake-NG instead whitelist all-uppercase variables? >> > I'd rather not add extra special cases unless that proves to be actually > necessary. And I believe that is not the case here, since the white > listing is obtained with just a simple one-liner. > > If you really don't like the whitelisting, another viable solution would > be to rename the RELOC_LDFLAGS variable to, say, RELOC-LDFLAGS, or even > LDFLAGS.RELOC; and similarly for the other variable. This is the solution > I'd personally prefer; in the I sent patch I opted for the whitelisting > just because that entailed less code churn.
The point is not the whitelisting; it is really that zero code churn is still the best choice... This smells too much of Autoconf 2.50... I was there and it was not pretty. ;) Another choice is to find AC_SUBSTed variables that end with LDFLAGS, CPPFLAGS, CFLAGS, etc., and whitelist them automatically. It can be done in m4, from Automake-NG's macros. >> Also, this is different from all other configuration mechanisms; it >> would be nicer to have it as an Automake-provided AM_* macro, >> > Nope, because the whitelisting must be allowed to be Makefile-specific. > >> or a Makefile.am definition. >> > I agree. And in fact this is exactly the mechanism provided by Automake-NG! Doh, obvious when you point it out. :) >>> * Makefile.am (AUTOMAKE_OPTIONS): Add the 'ng' option, to ensure that >>> mainstream Automake is not used by mistake when bootstrapping. Also, >>> bump the required Automake version from '1.11.1' to '1.12a', which is >>> the latest (and still development-only) version of Automake-NG at the >>> moment of writing. Drop the 'dist-xz' option, that is not supported >>> anymore. The same effect is now obtained ... >>> (AM_DIST_FORMATS): ... defining this to "gzip xz". >> >> Can you instead provide the backwards-compatible format with a >> deprecation period? >> > No, sorry, that would complicate the Automake-NG code for too little > gain. Automake-NG is actually about "maintainer convenience" as much > as it is about "user convenience", so such backward-incompatibilites > and little porting efforts are to be expected when switching from > mainline Automake to Automake-NG. That's fine, indeed if you add support in mainline Automake the deprecation period would end with the merge of Automake-NG. >> And perhaps add support for AM_DIST_FORMATS in mainline Automake? >> > This should be easily doable for 1.13, or even 1.12.4. And it might > help some projects simplifying their transition to Automake-NG. So > why not? I'll try to cook up a patch in the next days. Nice. Paolo
