[Top][All Lists]

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

Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal

From: Nick Bowler
Subject: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
Date: Fri, 9 Nov 2012 11:33:34 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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 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.  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

Nick Bowler, Elliptic Technologies (

reply via email to

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