Oops, I should have answered to this before writing my last reply ... On 11/02/2012 09:46 PM, Eric Blake wrote: > On 10/17/2012 04:15 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. > > Hmm, I'm wondering if we should do something fancier, and have both > AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS collaborate so that the > FIRST call to either macro causes AC_CONFIG_MACRO_DIR to be traced. > Considering that I'd like to see AC_CONFIG_MACRO_DIR deprecated in Autoconf 2.71 and removed in Autoconf 2.72, I believe that would be a bit of an overkill. I think that we should just assume that, if a user calls AC_CONFIG_MACRO_DIR, he calls it just once, and without mixing it with AC_CONFIG_MACRO_DIRS (like he would have done anyawy with Autoconf <= 2.69). Or am I assuming too much?
> In fact, I think that we _shouldn't_ trace AC_CONFIG_MACRO_DIRS, but > should instead trace _AC_CONFIG_MACRO_DIR, > Give that such tracing would be *the* interface for third-party tools to interact with out new feature, I'd rather have such a macro named so that it's clear it is a public macro. Maybe something as simple as "AC_CONFIG_MACRO_DIRS_TRACE_ME" would be enough? > where AC_CONFIG_MACRO_DIRS > has the task of whitespace normalizing and iterating over the loop. > That way, backends like aclocal do not have to repeat whitespace > normalization, > Actually, doing whitespace normalization in aclocal is a good idea regardless IMHO, as it would allow us to remove extra indirections from macros like AM_EXTRA_RECURSIVE_TARGETS -- as suggested by the commit message of <http://lists.gnu.org:443/archive/html/automake-patches/2012-11/msg00005.html> > and don't have to worry if the user passed newlines or > even backslash-newline in their AC_CONFIG_MACRO_DIRS call. > Backslash-newline seems to be handled just fine by the "${::}%" normalization in the autom4te's '--trace' options, as show by the tests introduced here: <http://lists.gnu.org:443/archive/html/automake-patches/2012-11/msg00004.html> >> (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]> >> --- >> NEWS | 9 +++++++++ >> doc/autoconf.texi | 36 ++++++++++++++++++++++++++---------- >> lib/autoconf/general.m4 | 10 +++++++++- >> 3 files changed, 44 insertions(+), 11 deletions(-) >> >> diff --git a/NEWS b/NEWS >> index d3ff4b9..495266a 100644 >> --- a/NEWS >> +++ b/NEWS >> @@ -10,6 +10,15 @@ GNU Autoconf NEWS - User visible changes. >> >> ** Macros >> >> +- AC_CONFIG_MACRO_DIRS >> + Use this macro to declare the directory for local M4 macros for aclocal. > > s/the directory/one or more directories/ > Consider this fixed. >> + It will be supported by future versions of aclocal (starting from the >> + Automake 1.13 release). >> + >> +- AC_CONFIG_MACRO_DIR >> + This macro is now obsolescent. AC_CONFIG_MACRO_DIRS Should be used >> + instead. > > But for backward compatibility with existing tools such as libtool, you > may use a single AC_CONFIG_MACRO_DIR call prior to any > AC_CONFIG_MACRO_DIRS calls. > not with my existing aclocal enhancements. For backward compatibility, you can use AC_CONFIG_MACRO_DIR by itself (as was possible with autoconf < 2.70 and automake < 1.13); but that's it. And given the general uselessness of AC_CONFIG_MACRO_DIR, trying to get more fancy than that that sounds like a waste of time to me. >> +++ b/doc/autoconf.texi >> @@ -2106,19 +2106,35 @@ files. For instance it is called by macros like >> @code{AC_PROG_INSTALL} >> @end defmac >> >> Similarly, packages that use @command{aclocal} should declare where >> -local macros can be found using @code{AC_CONFIG_MACRO_DIR}. >> +local macros can be found using @code{AC_CONFIG_MACRO_DIRS}. >> + >> +@defmac AC_CONFIG_MACRO_DIRS (@var{dir1} [@var{dir2} ... @var{dirN}]) >> +@acindex{CONFIG_MACRO_DIRS} >> +Specify the given directories as the location of additional local Autoconf >> +macros. This macro is intended for use by future versions of commands like >> +@command{autoreconf} or @command{aclocal} that trace macro calls; it should >> +be called directly from @file{configure.ac} so that tools that install >> +macros for @command{aclocal} can find the macros' declarations. >> + >> +This macro can be called multiple times and with multiple arguments; in >> +such cases, directories in earlier calls are expected to be searched >> +before directories in later calls, and directories appearing in the same >> +call are expected to be searched in the order in which they appear in >> +the call. For example, an usage like > > s/an usage/a usage/ > Consider this fixed as well. >> >> -@defmac AC_CONFIG_MACRO_DIR (@var{dir}) >> -@acindex{CONFIG_MACRO_DIR} >> -Specify @var{dir} as the location of additional local Autoconf macros. >> -This macro is intended for use by future versions of commands like >> -@command{autoreconf} that trace macro calls. It should be called >> -directly from @file{configure.ac} so that tools that install macros for >> -@command{aclocal} can find the macros' declarations. >> +@smallexample >> +AC_CONFIG_MACRO_DIRS([dir1 dir2]) >> +AC_CONFIG_MACRO_DIRS([dir3]) >> +AC_CONFIG_MACRO_DIRS([dir4 dir5]) >> +@end smallexample >> + >> +should cause the directories to be searched in this order: >> +@samp{dir1 dir2 dir3 dir4 dir5}. > > I think you NEED to mention that for historical compatibility, it is > appropriate to use AC_CONFIG_MACRO_DIR for the first such directory (but > if you do that, it must come before any AC_CONFIG_MACRO_DIRS call). > See above. >> >> Note that if you use @command{aclocal} from Automake to generate >> -@file{aclocal.m4}, you must also set @code{ACLOCAL_AMFLAGS = -I >> -@var{dir}} in your top-level @file{Makefile.am}. Due to a limitation in >> +@file{aclocal.m4}, you must also set >> +@code{ACLOCAL_AMFLAGS = -I @var{dir1} [-I @var{dir2} ... -I @var{dirN}]} >> +in your top-level @file{Makefile.am}. Due to a limitation in >> the Autoconf implementation of @command{autoreconf}, these include >> directives currently must be set on a single line in @file{Makefile.am}, >> without any backslash-newlines. > > This paragraph reads awkwardly - and given my desire to actually trace > something where we have already normalized to one directory per trace, > I'm not sure all these restrictions make sense. > Isn't this rendered mostly moot by the "2/2" patch "docs: ACLOCAL_AMFLAGS will become obsolescent in Automake 1.13" anyway? >> diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4 >> index 51cee30..44267b1 100644 >> --- a/lib/autoconf/general.m4 >> +++ b/lib/autoconf/general.m4 >> @@ -1727,13 +1727,21 @@ AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl >> ## ------------------------ ## >> >> >> +# AC_CONFIG_MACRO_DIRS(DIR-1 [DIR-2 ... DIR-n]) >> +# -------------------------------------------- >> +# Declare directories containing additional macros for aclocal. >> +# This macro can be called multiple times, and with multiple arguments. >> +AC_DEFUN([AC_CONFIG_MACRO_DIRS], []) > > Rather, I think we need this (and this also works with my above goal of > triggering an AC_CONFIG_MACRO_DIR trace exactly once): > > # _AC_CONFIG_MACRO_DIRS_USED(CALLER) > # ---------------------------------- > # Witness macro that says whether the first macro dir has been listed, > # in order to fail on incorrect usage. Self-redefining, so that all > # but the first call check who CALLER is, and error if needed. > m4_define([_AC_CONFIG_MACRO_DIRS_USED], > [m4_define([$0], [m4_if([$1], [AC_CONFIG_MACRO_DIR], > [AC_MSG_ERROR([$1 cannot be used multiple times])])])]) > > # _AC_CONFIG_MACRO_DIR(DIR) > # ------------------------- > # Declare a single directory containing additional macros for aclocal; > # can be called more than once; order of calls is important. This > # macro exists solely for tracing. > AC_DEFUN([_AC_CONFIG_MACRO_DIR]) > > # AC_CONFIG_MACRO_DIRS(DIR1 [DIR2...]) > # ------------------------------------ > # Declare one or more whitespace-separated directory containing > # additional macros for aclocal; can be called more than once; > # order of calls is important. > AC_DEFUN([AC_CONFIG_MACRO_DIRS], > [_$0_USED([$0])m4_map_args_w([$1], [_AC_CONFIG_MACRO_DIR(], [)])]) > >> + >> # AC_CONFIG_MACRO_DIR(DIR) >> # ------------------------ >> # Declare directory containing additional macros for aclocal. >> +# This is obsoleted by AC_CONFIG_MACRO_DIRS, and kept only for >> +# backward compatibility. Future Autoconf versions should start >> +# warning about it, in a year or so. >> AC_DEFUN([AC_CONFIG_MACRO_DIR], []) > > No, I don't think we should ever warn about it. I think we should > explicitly document that it is useful for integration with older tools. > But I do think its implementation should be altered, as follows: > > # AC_CONFIG_MACRO_DIR(DIR) > # ------------------------ > # Declare a single directory containing additional macros for aclocal; > # must be called at most once, and before any AC_CONFIG_MACRO_DIRS. > AC_DEFUN([AC_CONFIG_MACRO_DIR], > [_$0S_USED([$0])_$0([$1])]) > Now I've really got my head spinning, with all this partly-superseded reviews of partly-superseded patch series ... Let's say I will post a "v3" version of this patch series and its further enhancements (I will do so tomorrow CET, actually), and we'll start with a clean slate from there, OK? Thanks, and sorry for the confusion, Stefano
