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: Mon, 12 Nov 2012 17:41:29 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On 2012-11-12 15:19 -0700, Eric Blake wrote:
> On 11/12/2012 03:13 PM, Nick Bowler wrote:
> >> If libtool will get the information in a different way, then that new 
> >> way must return the same information - and that implies that autoconf 
> >> now has to do something with AC_CONFIG_MACRO_DIR.
> > 
> > On this point, I disagree: the way to maintain compatibility is to not
> > change this macro, and instead add a totally new one (which we've done:
> > it's called AC_CONFIG_MACRO_DIRS with an S) that new packages can make
> > use of if they want, and old packages can continue to not use.
> > 
> > I thought my examples already demonstrated where the proposed changes
> > would cause existing, *working* configure.ac files to fail after
> > updating to a version of Autoconf with the changes.
> 
> Our point is that any configure.ac with two or more AC_CONFIG_MACRO_DIR
> is NOT working.  It was merely lucky that it wasn't tripping over other
> problems.

After 10 years of consistency, it stops being mere luck and starts being
expected behaviour.  Especially since, as mentioned earlier, nobody ever
documented what AC_CONFIG_MACRO_DIR actually was supposed to do.  So the
only thing users have ever had to go on was the behaviour of their
tools.

> 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 backwards-compatible way of handing AC_CONFIG_MACRO_DIR is to have
> > it do exactly what it has done for the past 10 years: nothing useful.
> 
> When used exactly once, it does just that.

Another thing to consider is that, if you aren't using libtool, the
following will work fine today, too (and I think will be totally broken
by this change):

  configure.ac:
  AC_CONFIG_MACRO_DIR([somewhere-else])

  Makefile.am:
  ACLOCAL_AMFLAGS = -I m4

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



reply via email to

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