Re: [PATCH 0/2] AC_CONFIG_MACRO_DIRS: implementation and documentation

[Stefano Lattarini]

On 10/17/2012 12:15 PM, Stefano Lattarini wrote:
> 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(-)
> 
Ping?

Regards,
  Stefano