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

[Andrew W. Nosenko]

Excuse, may be it's too late to party, but...  What is the reason to
to invent yet another macro name?  Anyway in the most packages there
will be one and the only one line:
    AC_CONFIG_MACRO_DIR([m4])
And even when the many dirs are need, they will be written one by one
in the theirs own macro call:
    AC_CONFIG_MACRO_DIR([m4])
    AC_CONFIG_MACRO_DIR([sub/m4])
    AC_CONFIG_MACRO_DIR([pack/m4])
(The reasons for such stacking is the same as the reasons for lineup
an arguments in a function call with a number of parameters in the
C-like languages -- aesthetics and ability to easy comment out some of
them.  The later becomes even more important in languages with the
only one style of comment -- from comment-char to the end-of-line,
like autoconf language.)

Therefore, a question raises: why to invent the new macro name?
Please note, I don't say about implementation.  I say about name.  If
someone whant to write (or generate, which is more probable) a number
of dirs in the one macro call -- no problems:
    AC_CONFIG_MACRO_DIR([m4], [sub/m4], [pack/m4])
or how it intended to be written, but in wast majority of cases I
expect the name in singular form to be more appropriate.  Just change
it's implementation, but left the name as is.  Allowing multiple dirs
where only one was allowed is backward compatible.
As a bonus: No needs in playing the game with "this macro is obsolete,
but we don't say you that evenn with -Wobsolete for backward
compatibility".
If te plural form (AC_CONFIG_MACRO_DIRS) is needed for some very heavy
reason, then it may me made just an alias to the AC_CONFIG_MACRO_DIR.

On Tue, Oct 16, 2012 at 11:46 PM, Nick Bowler <address@hidden> wrote:
> 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/)
>



-- 
Andrew W. Nosenko <address@hidden>