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

[Stefano Lattarini]

Hi Daiki, Pavel.

On 03/01/2013 08:41 AM, Daiki Ueno wrote:
> Pavel Raiskup <address@hidden> writes:
> 
>>   autom4te --language Autoconf-without-aclocal-m4
>> --trace=AC_CONFIG_MACRO_DIR configure.ac
>>
>>   // and for the up2date autoconf (not yet released) should be used (See
>>   // autoconf's manual from git)
>>   autom4te --language Autoconf-without-aclocal-m4
>> --trace=AC_CONFIG_MACRO_DIR_TRACE configure.ac
>>
>> Are there any problems to be dependant on autoconf because of the
>> 'autom4te' utility?  There is a lot of tracing done in gettext.
>> (Note that this is not a blocker.)
> 
> 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.

>> Seems to be OK to me.  Ignoring of ACLOCAL_AMFLAGS should be ok in a case
>> that AC_CONFIG_MACRO_DIR{,S} is specified.  Especially when this code is
>> just about the sentence what is going to be suggested to gettextize's
>> user.
> 
> OK, actually I couldn't find much information about the relationship
> between ACLOCAL_AMFLAGS and AC_CONFIG_MACRO_DIR{,S} in docs, but I found:
> 
> NEWS in automake says ACLOCAL_AMFLAGS is deprecated:
> http://git.savannah.gnu.org/cgit/automake.git/tree/NEWS#n16
>
Consider that the deprecation is recent; and given the high usage that
variable has "in the wild", it will not give a runtime warning for at
least 18 months (or more), until the next planned major release of
Automake (2.0); and even after that it will not be actually removed
for other three or four years (until Automake 4.0).  So, in this interim
period, I fear you'll have to support both (Libtool does something
similar IIRC, so you might take inspiration from there).

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

>> Thanks for working on this - for me: ACK for this change.  And please keep
>> your radar on 'autopoint' if possible.
> 
> Thanks for the review.  I thought once the 'gettextize' patch was
> finalized, it could be ported to 'autopoint' (since they shares a large
> amount of code).
> 
>> Btw. I tried to test this and it seems to work - but building of gettext
>> from git is quite painful :(
>>   ~> http://lists.gnu.org/archive/html/bug-gettext/2012-12/msg00058.html
> 
> Right, but I don't have a good idea for this.  Perhaps it might be ok to
> version control the contents of archive.tar.
> 
> Regards,

HTH,
  Stefano