Hi all, sorry for the delay. On 11/13/2012 11:55 PM, Eric Blake wrote: > > [SNIP] > > Yes, but that directory appears via ACLOCAL_AMFLAGS, which is outside > the realm of what configure.ac specifies, and belongs to a file > (Makefile.am) that is processed owned by aclocal. > Actually by automake. And currently, none of automake and aclocal explicitly *processes* ACLOCAL_AMFLAGS in any way: the sole role of that variable is to have its contents passed to the aclocal invocation issued by the automatic remake rules for aclocal.m4:
$ rgrep -C4 ACLOCAL_AMFLAGS lib/am/ lib/am/configure.am-## Whenever a configure dependency changes we need to rebuild lib/am/configure.am-## aclocal.m4 too. Changing configure.ac, or any file included by lib/am/configure.am-## aclocal.m4 might require adding more files to aclocal.m4. Hence lib/am/configure.am-## the $(am__configure_deps) dependency. lib/am/configure.am:## We still need $(ACLOCAL_AMFLAGS) for sake of backward-compatibility; lib/am/configure.am-## we should hopefully be able to get rid of it in a not-so-distant lib/am/configure.am-## future. lib/am/configure.am-if %?REGEN-ACLOCAL-M4% lib/am/configure.am-$(ACLOCAL_M4): %MAINTAINER-MODE% $(am__aclocal_m4_deps) lib/am/configure.am:?TOPDIR_P? $(am__cd) $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS) lib/am/configure.am-?!TOPDIR_P? cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh lib/am/configure.am- lib/am/configure.am-## Avoid the "deleted header file" problem for the dependencies. lib/am/configure.am-$(am__aclocal_m4_deps): > So it is up to automake, not autoconf, to ensure that this case works. > Automake 1.13 will error out if ACLOCAL_AMFLAGS exists but does not > match the trace (thus enforcing that _if_ you use the redundancy, you > use it correctly); but will not care if you omit ACLOCAL_AMFLAGS. Alas, that is not the case (Did I give a different impression in some of my past messages? If so, sorry for the confusion). But it might be a good idea to do so, for your rationales about at least enforcing consistency where duplication is needed. Patches welcome. > On 11/13/2012 03:11 PM, Nick Bowler wrote: >> Then this will represent a regression in Automake in the case where a >> configure.ac does not include AC_CONFIG_MACRO_DIR all (for example, >> this would regress for at least GNU Gettext and my own packages). > > Only if you use -Werror to turn that warning into a hard error. > Otherwise, it is a warning, but no change in behavior. If you choose to > silence the warnings, you would update your configure.ac to add the > necessary AC_CONFIG_MACRO_DIR[S] lines (possibly with my > m4_default_define hack to ensure that you are not forcing everyone > bootstrapping your package to use newer autotools). > >> But I >> believe you may be mistaken: I personally tested the patch series that >> Stefano posted and did not observe the behaviour you describe. So this >> will only be the case if Automake's behaviour has changed in the >> interim... > > There may still be a patch needed to automake to properly honor the > union of directories learned by trace and the directories specified by > ACLOCAL_AMFLAGS, when the latter is present. > aclocal never looked at ACLOCAL_AMFLAGS (never looked at any Makefile.am content in fact), and I have no plan to change that now. But we might have automake checking for consistency between ACLOCAL_AMFLAGS and AC_CONFIG_MACRO_DIR{,S}. Regards, Stefano