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