autoconf-patches
[Top][All Lists]
Advanced

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

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


From: Nick Bowler
Subject: Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks
Date: Tue, 13 Nov 2012 09:30:45 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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)?

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.

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.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)



reply via email to

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