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

[Nick Bowler]

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.

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

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", 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.  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.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)