[PATCH 0/2] AC_CONFIG_MACRO_DIRS: implementation and documentation

[Stefano Lattarini]

On 10/17/2012 09:25 AM, Stefano Lattarini wrote:
> On 10/16/2012 10:46 PM, Nick Bowler wrote:
>>
>> [SNIP]
>>
>> 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.
>
Here is the re-roll (see below for the diff-stat, and the two replies to
this message for the actual patches).  The testsuite still passes.

OK to apply?

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

-*-*-*-

Stefano Lattarini (2):
  AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
  docs: ACLOCAL_AMFLAGS will become obsolescent in Automake 1.13

 NEWS                    |  9 +++++++++
 doc/autoconf.texi       | 46 ++++++++++++++++++++++++++++++++--------------
 lib/autoconf/general.m4 | 10 +++++++++-
 3 files changed, 50 insertions(+), 15 deletions(-)

-- 
1.7.12.317.g1c54b74