automake-patches
[Top][All Lists]
Advanced

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

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


From: Stefano Lattarini
Subject: Re: [PATCH] {master} aclocal: deprecate ACLOCAL_AMFLAGS, trace AC_CONFIG_MACRO_DIR instead
Date: Tue, 03 Jul 2012 22:54:47 +0200

On 07/02/2012 02:57 PM, Stefano Lattarini wrote:
> On 07/02/2012 02:26 PM, Ralf Corsepius wrote:
>> On 06/30/2012 08:30 PM, Stefano Lattarini wrote:
>>> Maintaining ACLOCAL_AMFLAGS in the Makefile.am to pass extra flags
>>> to aclocal is (and have always been) quite of an hack.  For example,
>>> autoreconf is forced to grep Makefile.am 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 Makefile.am and
>>> configure.ac 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?
>>
> No; and I think there is no compelling reason to support multiple local
> m4 macro dirs in a build system setup.
> 
> But I recognize I might be proven wrong, so here's a sketch of how I
> plan to proceed in this case.
> 
> Once we start warning about ACLOCAL_AMFLAGS (in Automake 1.14), people
> that were using multiple '-I' option there will see that the new semantics
> don't support their setup anymore.  So they'll either adjust such setup,
> or, if that turns out to be impossible, will write to bug-automake to
> complain.  If their complain turns out to be legitimate, we will add a
> new autoconf macro 'AM_EXTRA_LOCAL_M4_DIRS' (say), that aclocal will
> trace and use to adjust its search path accordingly.
>
I've now pushed this patch.

Regards,
  Stefano



reply via email to

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