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
