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

[Stefano Lattarini]

Hi Nick, thanks for the feedback.

On 10/16/2012 10:46 PM, Nick Bowler wrote:
> It's a little bit hard to review documentation in unified diff format,
> but I have some comments:
> 
> On 2012-10-16 21:30 +0200, Stefano Lattarini wrote:
>> Similar to AC_CONFIG_MACRO_DIRS, but accepts more than one argument.
>              ^^^^^^^^^^^^^^^^^^^^
> 
> I assume this was meant to say AC_CONFIG_MACRO_DIR.
>
Yes, well spotted.  Consider it fixed.

>> 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.
> [...]
>> diff --git a/doc/autoconf.texi b/doc/autoconf.texi
> [...]
>> 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.
>>  
>>  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.
> 
> Please specify precisely the order in which these directories are
> to be searched for macros, since it really does matter.  I think
> the intention is that they will be searched in the order specified,
> given the description of ACLOCAL_AMFLAGS here -- but that sentence
> will presumably be deleted eventually and requires the user to be
> familiar with an external tool's command-line syntax.
> 
> Additionally, please specify the intended behaviour when this macro is
> expanded two (or more) times.  Ideally it would result in a merger of
> the two (or more) directory lists in a useful and documented manner.
> 
> This is especially important because Autoconf won't actually be using
> the AC_CONFIG_DIRS values at all: people will (hopefully) be writing
> tools,
>
I thought I didn't need to specify the order in which AC_CONFIG_MACRO_DIRS
arguments and multiple calls are processed exactly *because* of this
reason ...

> based solely on this documentation, that deal with these macro
> directories.  It would be very bad if we ended up with two tools that,
> for example, interpreted the directory ordering differently.
>
... but your rationale has convinced me I was wrong.  I will send (later
or tomorrow) a re-roll with improved documentation.

> Tools like libtoolize will (again, hopefully) be using this information
> to decide where to copy libtool macros.  Probably aclocal --install will
> need to do this as well.  If multiple macro directories are specified,
> which one should they use?  I think the answer should be: "The first
> directory in the documented ordering",
>
Yes, this is the behaviour I intended to implement in aclocal.

> if for no other reason than that is what libtoolize currently does when
> it snarfs in ACLOCAL_AMFLAGS.
> 
> I think it's important to have, for testing, a version of aclocal that
> actually makes use of this feature.
>
The reason I wrote this patch is because I want to make use of this
feature in aclocal 1.13.  See also:
<http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00030.html>

> That way, it's actually possible to
> validate that this feature works in a useful manner.  Bonus points for
> demonstrating that we can kill off ACLOCAL_AMFLAGS entirely (this means
> patching at least libtool as well as automake and autoconf).  While it's
> not my call, a testable implementation should be a prerequisite for
> merging another macro like this into Autoconf.
>
Well, I agree that is be a prerequisite for adding this new macro into a
*released* Autoconf, but we can be more relaxed for what concerns the Git
repository; if this turns out to be a bad idea, we can revert the relevant
changes before cutting the 2.70 release out of the repository, no?

Thanks,
  Stefano