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

Full log

View this message in rfc822 format

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> elliptictech.com>
Cc: 12845 <at> debbugs.gnu.org, autoconf-patches <at> gnu.org, eblake <at> redhat.com, bunk <at> stusta.de
Subject: bug#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
Date: Fri, 09 Nov 2012 19:01:35 +0100

[+cc bug-automake]

On 11/09/2012 05:33 PM, Nick Bowler wrote:
> On 2012-11-09 18:00 +0200, Adrian Bunk wrote:
>> On Sat, Nov 03, 2012 at 01:31:39AM +0100, Stefano Lattarini wrote:
>>> On 11/02/2012 09:46 PM, Eric Blake wrote:
>>>> On 10/17/2012 04:15 AM, Stefano Lattarini wrote:
> [...]
>>>> Hmm, I'm wondering if we should do something fancier, and have both
>>>> AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS collaborate so that the
>>>> FIRST call to either macro causes AC_CONFIG_MACRO_DIR to be traced.
>>>>
>>> Considering that I'd like to see AC_CONFIG_MACRO_DIR deprecated in
>>> Autoconf 2.71 and removed in Autoconf 2.72, I believe that would be
>>> a bit of an overkill.
>>> ...
>>
>> It is completely crazy to imagine removing a macro in Autoconf 2.72 
>> that is as of today used in half of all configure.ac files. [1]
>>
>> Did you ever consider the consequences e.g. for Debian, where more than
>> thousand packages are re-running autoconf at package build time?
>> "We have to fix 1000 packages before we can upgrade to autoconf 2.72
>> in Debian" sounds like a pretty horrible situation for both Debian
>> and autoconf.
>>
>> Marking it as deprecated in Autoconf 2.71 with a possible removal
>> 10 years later sounds like a more realistic schedule.
> 
> To be honest I don't see the point in removing the macro ever, since
> it doesn't actually do anything.
>
Good point.  Unfortunately, the current development version of aclocal
has started to recognize and handle AC_CONFIG_MACRO_DIR.  But we can
easily change that once 'AC_CONFIG_MACRO_DIRS' is implemented, by having
aclocal recognize only this later macro; and we can do so without any
backward-incompatibility, since the code handling AC_CONFIG_MACRO_DIR
has not made it into any released aclocal version.

I'm CC:ing this message to the bug-automake list so that I won't
forgot about the issue ...

> Removing it from the documentation
> (except perhaps for historical reference) and marking it deprecated
> would be prudent, however.
> 
> By the same token, to avoid any regressions, let's not change the
> behaviour of AC_CONFIG_MACRO_DIR by suddenly making it do more than
> nothing.
>
I agree; and as I said, I plan to remove aclocal's new-found ability
to handle AC_CONFIG_MACRO_DIR before releasing Automake 1.13.

Thanks,
  Stefano

Previous Next

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