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