Re: [bug-gettext] AC_CONFIG_MACRO_DIR{,S} & ACLOCAL_AMFLAGS

[Daiki Ueno]

Stefano Lattarini <address@hidden> writes:

Hi Stefano.

>> Well, I'm not sure :) but this 'autom4te' usage looks very helpful.  So
>> let's refactor using it, after installing this patch.  Even with git
>> autoconf, --trace=AC_CONFIG_MACRO_DIR still seems to print the first
>> macro directory (and that is what gettextize wants), so the first form
>> might be sufficient.
>>
> But starting from Autoconf 2.70, the suggested (and documented) way to
> make use of the AC_CONFIG_MACRO_DIR{,S} macros will be to trace the
> macro AC_CONFIG_MACRO_DIR_TRACE; see:
> <http://git.savannah.gnu.org/cgit/autoconf.git/commit/?h=526903>
>
> You might try to see whether AC_CONFIG_MACRO_DIR_TRACE appears in
> the traces, and if does not, fall back to tracing AC_CONFIG_MACRO_DIR
> and AC_CONFIG_MACRO_DIRS directly.  That should work and be forward
> compatible.

Good idea, I'll do that way.

>> libtoolize has a comment "AC_CONFIG_MACRO_DIRS takes precedence."
>> http://git.savannah.gnu.org/cgit/libtool.git/tree/libtoolize.in#n1814
>> 
>> So I concluded it could be ignored here.
>>
> You mean, ignore ACLOCAL_AMFLAGS if AC_CONFIG_MACRO_DIR{,S} is present?
> That makes sense, and keeps things simple.  OTOH, if only ACLOCAL_AMFLAGS
> is present, it will have to be honoured.

Yes, exactly.

> And that is not only for the sake of "old" packages: until a couple of
> months ago (before Automake 1.13 was released), using ACLOCAL_AMFLAGS
> was the only way to specify local m4 directory for aclocal and
> autoreconf, so almost all the existing autotools based packages still
> rely on it (and certainly will until they can start assuming Automake
> 1.13 or later).

Thank you very much for the clarification.  Now the background is much
clearer to me.

Regards,
-- 
Daiki Ueno