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

[Nick Bowler]

On 2012-11-13 00:01 +0200, Adrian Bunk wrote:
> On Mon, Nov 12, 2012 at 03:40:50PM -0500, Nick Bowler wrote:
> >...
> > But I still maintain that it is much easier to not make any changes
> > whatsoever to AC_CONFIG_MACRO_DIR: i.e., do nothing.
> >...
> 
> We must not force all users to update their configure.ac only because 
> they updated autoconf/automake/libtool.
> 
> That would extremely annoy everyone using autoconf/automake/libtool.

I *wholeheartedly* agree.  This was my entire point!  Perhaps I did not
explain it well.

> And for a distribution like Debian where over 800 packages have a build 
> dependency on libtool (usually calling libtoolize at package build time)
> that could also cause problems.
> 
> 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.

And this is what we must avoid!

> If there is no proper solution to handle multiple AC_CONFIG_MACRO_DIR in 
> a backwards-compatible way, then a clear failure is at least better than 
> silently changed behavior. On a positive side, multiple 
> AC_CONFIG_MACRO_DIR doesn't seem to be that common in existing
> configure.ac usage.

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.

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