Hi Eric. On 11/09/2012 07:38 PM, Eric Blake wrote: > On 11/03/2012 06:05 AM, Stefano Lattarini wrote: >> Similar to AC_CONFIG_MACRO_DIR, but accepts more than one argument. >> This will allow projects to use several m4 macro local dirs. This is >> especially important for projects that are used as nested subpackages >> of larger projects. >> >> See also: >> <http://lists.gnu.org/archive/html/autoconf/2011-12/msg00037.html> >> <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00010.html> >> >> * lib/autoconf/general.m4 (AC_CONFIG_MACRO_DIRS): New. Expands to the >> empty anyway, since it is only meant to be traced by tools like aclocal >> and autoreconf. >> (AC_CONFIG_MACRO_DIR): Updated comments to mark it as obsolescent. It >> does not elicit warnings yet, for backward-compatibility. >> * doc/autoconf.texi (@node "Input"): Document AC_CONFIG_MACRO_DIRS rather >> than to the obsolescent AC_CONFIG_MACRO_DIR. >> * NEWS: Update. >> >> Suggested-by: Eric Blake <[email protected]> >> Helped-by: Nick Bowler <[email protected]> >> Signed-off-by: Stefano Lattarini <[email protected]> > > I'm adding my own sign-off and squashing this in; basically, I'm > relaxing the documentation to plan for my subsequent patches where > AC_CONFIG_MACRO_DIR will not be treated as obsolescent, but leaving your > initial implementation separate from my improvements to make it clear > what my improvements accomplish. > How does this interact with the fact that aclocal 1.13 will handle *only* AC_CONFIG_MACRO_DIRS, while continuing (like it did before) to ignore AC_CONFIG_MACRO_DIR? For a rationale about this, see:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12845> I still believe we should make it clear that AC_CONFIG_MACRO_DIR is obsolescent and should no longer be used; albeit, to avoid gratuitous backward-incompatibility, we'll refrain to have it elicit any warning, at least for the time being ... Regards, Stefano
