Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks

[Adrian Bunk]

On Tue, Nov 13, 2012 at 09:30:45AM -0500, Nick Bowler wrote:
> On 2012-11-13 01:12 +0200, Adrian Bunk wrote:
> > On Mon, Nov 12, 2012 at 05:41:29PM -0500, Nick Bowler wrote:
> > > On 2012-11-12 15:19 -0700, Eric Blake wrote:
> > >...
> > > > But since we can't make it continue to work with the new
> > > > semantics of AC_CONFIG_MACRO_DIRS, the best we can do (and indeed, what
> > > > we DID do) is loudly flag incorrect usage as an error rather than
> > > > silently change semantics.
> > > 
> > > Sorry, I don't understand.  You seem to be claiming that the addition of
> > > AC_CONFIG_MACRO_DIRS (an entirely new macro, with documented behaviour)
> > > to Autoconf will somehow break the following pattern if we don't also
> > > change the definition of AC_CONFIG_MACRO_DIR?
> > > 
> > >   configure.ac:
> > >   AC_CONFIG_MACRO_DIR([foo])
> > > 
> > >   Makefile.am:
> > >   ACLOCAL_AMFLAGS = -I foo
> > > 
> > > What breaks?  How does it break?  Why will this not continue to work
> > > exactly as it has in the past if we do not keep AC_CONFIG_MACRO_DIR's
> > > definition exactly as it is right now, i.e.:
> > > 
> > >   AC_DEFUN([AC_CONFIG_MACRO_DIR], [])
> > >   
> > > ?
> > >...
> > 
> > The problem is not the addition of AC_CONFIG_MACRO_DIRS itself,
> > but in the whole picture:
> > 
> > In the future libtool will use the result of tracing 
> > AC_CONFIG_MACRO_DIR_TRACE instead of grep'ing configure.ac.
> 
> So what you are saying is that this change is a "workaround" for a
> planned regression in libtool.  Why are we planning to regress libtool?
> Why can't libtool just continue to do what it's always done for packages
> that don't make use the new feature (AC_CONFIG_MACRO_DIRS)?

The cleanest solution is to handle AC_CONFIG_MACRO_DIR in autoconf,
without making libtool and other users like automake bother about
whether AC_CONFIG_MACRO_DIR or AC_CONFIG_MACRO_DIRS is present.

Handling that in one place is much better than having the same logic 
duplicated in multiple places.

> If libtool plans on removing compatibility with packages that have
> worked fine for 10 years or longer, then that is a separate problem,
> and one that I would argue against just as strongly.

libtool does not plan that.

> But I have a better idea: let's not remove features (it's OK to stop
> documenting them) if we don't absolutely have to, then there will be
> no regressions that we need to work around in Autoconf.

There is no regression planned.

libtool will access the same information through a new way that has been 
implemented by this patch.

> Cheers,

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed