Re: How to maintain compatibility with Automake.

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, Aug 10, 2010 at 11:15:21AM CEST:
> * Gary V. Vaughan wrote on Tue, Aug 10, 2010 at 11:09:33AM CEST:
> > On 10 Aug 2010, at 15:19, Peter Rosin wrote:
> > > m4_defun([AM_PROG_AR],
> > > [AC_CHECK_TOOLS(AR, [ar], false)
> > > : ${AR=ar}
> > > AC_SUBST([AR])dnl
> > > ])# AM_PROG_AR
> > > ])
> > 
> > Just like that!
> 
> NAK.  I don't have time to explain now, but this should be completely
> unnecessary.  Esp since Libtool already sets $AR.

Sorry for the short and harsh answer, here's a longer explanation:

First, LT_INIT already causes AC_CHECK_TOOLS([AR], ...) to be invoked.
Second, overrides of the form
  m4_ifndef([MACRO],
  [ AC_DEFUN([MACRO], [...]) ])

in public m4 files (installed in $datarootdir/aclocal) are very
problematic for third-party projects if MACRO does not come from
Autoconf itself: aclocal will pick it up and install libtool.m4 in
projects using MACRO even if the project otherwise doesn't use Libtool
at all!  Users were quite annoyed about that.

Now, in the above you don't use AC_DEFUN, so hopefully that particular
aclocal issue is lessened.  But still, I have had too much pain with
additions to lt~obsolete.m4[1] that I'd really prefer not adding macros
which belong to third parties to public Libtool macro files.

For macros that are otherwise present only in the Autoconf project, this
issue is not a problem: there is not an ordering problem between files
in $datarootdir/autoconf and $datarootdir/aclocal.  That's why Gary's
examples work fine.

Back on topic, I'm writing a reply to
<http://thread.gmane.org/gmane.comp.gnu.libtool.general/10927/focus=4438>
that hopefully addresses the remaining questions around AM_PROG_AR.

Cheers,
Ralf

[1] Case in point: $datarootdir/aclocal contains old lt~obsolete.m4
file, in-tree m4/ subdir contains yet another version; now, even with
the file naming done in the order that the other Libtool macro files
come first, doing 'aclocal -I m4' means that you will see macro names
twice, and suddenly not all of the obsolete names come last ...
I ended up just uninstalling the Libtool macro files.  I'm assuming some
of the scary bug reports that nobody addresses are due to issues like
this.