[Top][All Lists]

[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 specifies, and belongs to a file
> ( 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/ Whenever a configure dependency changes we need to 
  lib/am/ aclocal.m4 too.  Changing, or any file 
included by
  lib/am/ aclocal.m4 might require adding more files to 
aclocal.m4.  Hence
  lib/am/ the $(am__configure_deps) dependency.
  lib/am/ We still need $(ACLOCAL_AMFLAGS) for sake of 
  lib/am/ we should hopefully be able to get rid of it in a 
  lib/am/ future.
  lib/am/ %?REGEN-ACLOCAL-M4%
  lib/am/$(ACLOCAL_M4): %MAINTAINER-MODE% $(am__aclocal_m4_deps)
  lib/am/        $(am__cd) $(srcdir) && $(ACLOCAL) 
  lib/am/!TOPDIR_P?       cd $(top_builddir) && $(MAKE) 
$(AM_MAKEFLAGS) am--refresh
  lib/am/ Avoid the "deleted header file" problem for the 

> 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
>> 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 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
content in fact), and I have no plan to change that now.  But we might
have automake checking for consistency between ACLOCAL_AMFLAGS and


reply via email to

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