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

[Gary V. Vaughan]

Hi Eric,

On Oct 17, 2012, at 4:45 AM, Eric Blake <address@hidden> wrote:
> On 10/16/2012 03:38 PM, Andrew W. Nosenko wrote:
>> 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.)
> 
> The problem is that existing tools (here's looking at you libtool) are
> inconsistent if you HAPPEN to use AC_CONFIG_MACRO_DIR - some use the
> first directory, others use the last, and some crash altogether.

Libtool does its best with an under-specified interface, and tries to be
future proof by checking for consistency between the AC_CONFIG_MACRO_DIR
argument and the first -I argument in ACLOCAL_AMFLAGS.

By inspection, it seems that released libtools (at least the recent ones I
looked at) will take the last directory if AC_CONFIG_MACRO_DIR is given
more than once.

> Using just the m4 perspective, yes, the macros are aliases (they both do
> nothing).  But from the autoconf --trace perspective, having two macros
> matters, because not all tools used --trace (older libtool was using
> sed, rather poorly), and we don't want to break interoperability with
> old tools, all while still allowing new tools (automake 1.13) to take
> advantage of the multiple directories.


It's not possible for libtoolize to use autoconf traces to examine the contents
of configure.ac/aclocal.m4 since it needs to be able to run before all the
macros required from there (e.g. libtool.m4) are available.  Because of that
ALL released versions of libtoolize use sed to find out what macros are
declared by the user.  Please tell me what is poor about the use of sed in
libtoolize and I will fix it and make a point release.

I imagine aclocal must be parsing configure.ac with regular expressions
too for the same reason, but Perl makes my eyes bleed so I can't tell by
looking at it.

In the meanwhile, I found a way to use GNU M4 traces to look at autoconf
macro arguments in the user's configure.ac even before all the relevant
macro definitions are available (before aclocal/autopoint/libtoolize have
completed), so the next major release is much more robust to M4 quoting
etc.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)