[Top][All Lists]

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

Re: [PATCH] {master} aclocal: deprecate ACLOCAL_AMFLAGS, trace AC_CONFIG

From: Ralf Corsepius
Subject: Re: [PATCH] {master} aclocal: deprecate ACLOCAL_AMFLAGS, trace AC_CONFIG_MACRO_DIR instead
Date: Mon, 02 Jul 2012 14:26:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

On 06/30/2012 08:30 PM, Stefano Lattarini wrote:
Maintaining ACLOCAL_AMFLAGS in the to pass extra flags
to aclocal is (and have always been) quite of an hack.  For example,
autoreconf is forced to grep to honour those flags.  But
this is a bad obsolescent behaviour; in fact, the autotools have moved
consistently in the past years from custom grepping of and to tracing of m4 macro calls, which is more consistent,
more reliable and more flexible.

And when autoreconf is not used, the developer is forced to add *by hand*
the flags specified by ACLOCAL_AMFLAGS to the aclocal calls not triggered
by make rebuild rules; here lie again more duplication and more chances
for errors.

Moreover, ACLOCAL_AMFLAGS has only two typical use cases:

   - to instruct aclocal to look for extra macro definition in a local
     directory (as with "ACLOCAL_AMFLAGS = -I m4"); and

   - to further instruct aclocal to copy in that local directory the
     required third-party .m4 files found in the system-wide directory
     (as with "ACLOCAL_AMFLAGS = -I m4 --install").

The first use case can be better covered if aclocal can instead trace and
honours call to the AC_CONFIG_MACRO_DIR autoconf macro; and the second
use case shouldn't be considered really legitimate, as it is quite (and
subtly) brittle (see automake bug#9037).

ACLOCAL_AMFLAGS is able to take sequences of  "-I's".

Will your AC_CONFIG_MACRO_DIR be able handle such cases?

reply via email to

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