GNU bug report logs - #12845
aclocal: stop handling AC_CONFIG_MACRO_DIR; handle just AC_CONFIG_MACRO_DIRS (was: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal

Previous Next

Package: automake;

Reported by: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Date: Fri, 9 Nov 2012 18:03:01 UTC

Severity: normal

Tags: moreinfo, patch

Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #35 received at 12845 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 12845 <at> debbugs.gnu.org,
	autoconf-patches <at> gnu.org, Adrian Bunk <bunk <at> stusta.de>
Subject: Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity
	checks
Date: Wed, 14 Nov 2012 07:50:55 -0700
[Message part 1 (text/plain, inline)]
On 11/14/2012 07:41 AM, Stefano Lattarini wrote:
>> If I understand your argument correctly, you are claiming that
>> AC_CONFIG_MACRO_DIR should _not_ trace into AC_CONFIG_MACRO_DIR_TRACE,
>> so that case (2) can be distinguished by automake; but that would mean
>> that automake has to trace _both_ AC_CONFIG_MACRO_DIR_TRACE and
>> AC_CONFIG_MACRO_DIR for case (0) to work.
>>
> Currently, Automake is already tracing both AC_CONFIG_MACRO_DIR and
> AC_CONFIG_MACRO_DIR_TRACE, to avoid several testsuite breakages.  Are
> you arguing that tracing both macros is a bad idea?  If yes, I might
> add in 'm4/init.m4' a (re)definition of the AC_CONFIG_MACRO_DIR and
> AC_CONFIG_MACRO_DIRS macros if pre-2.70 autoconf is detected, so that
> packages using older autoconf but newer aclocal/automake will still be
> able to rely on that macros.  And this hack will be removed in Automake
> 1.14 (when we'll start requiring autoconf 2.70), so this clumsy extra
> code won't pollute our codebase for too long.
> 
> Opinions?

As long as you aim to interoperate with autoconf 2.69 but still diagnose
mismatches between ACLOCAL_AMFLAGS on the primary directory [granted,
the mistmatch diagnosis patch still needs to be written], then you have
to trace AC_CONFIG_MACRO_DIR.  However, you should only need to pay
attention to the AC_CONFIG_MACRO_DIR trace in the case where
AC_CONFIG_MACRO_DIR_TRACE had no hits (that is, only for older
autoconf).  On the other hand, it is harmless if, under newer autoconf,
you pay attention to both macros - it just means that you will encounter
the primary directory twice (once under each trace).

As soon as you AC_PREREQ([2.70]), then yes, you can quit tracing
AC_CONFIG_MACRO_DIR.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 12 years and 263 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.