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