autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal


From: Stefano Lattarini
Subject: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
Date: Sat, 03 Nov 2012 01:31:39 +0100

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 <address@hidden>
>> Helped-by: Nick Bowler <address@hidden>
>> Signed-off-by: Stefano Lattarini <address@hidden>
>> ---
>>  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}.
>> +
>> address@hidden AC_CONFIG_MACRO_DIRS (@var{dir1} address@hidden ... 
>> @var{dirN}])
>> address@hidden
>> +Specify the given directories as the location of additional local Autoconf
>> +macros.  This macro is intended for use by future versions of commands like
>> address@hidden 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.

>>  
>> address@hidden AC_CONFIG_MACRO_DIR (@var{dir})
>> address@hidden
>> -Specify @var{dir} as the location of additional local Autoconf macros.
>> -This macro is intended for use by future versions of commands like
>> address@hidden that trace macro calls.  It should be called
>> -directly from @file{configure.ac} so that tools that install macros for
>> address@hidden can find the macros' declarations.
>> address@hidden
>> +AC_CONFIG_MACRO_DIRS([dir1 dir2])
>> +AC_CONFIG_MACRO_DIRS([dir3])
>> +AC_CONFIG_MACRO_DIRS([dir4 dir5])
>> address@hidden smallexample
>> +
>> +should cause the directories to be searched in this order:
>> address@hidden 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
>> address@hidden, you must also set @code{ACLOCAL_AMFLAGS = -I
>> address@hidden in your top-level @file{Makefile.am}.  Due to a limitation in
>> address@hidden, you must also set
>> address@hidden = -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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]