autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks


From: Stefano Lattarini
Subject: Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks
Date: Wed, 14 Nov 2012 13:31:37 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]