Re: [PATCH 1/2] ar-lib: new 'AM_PROG_AR' macro, triggering the 'ar-lib' script

[Stefano Lattarini]

On Thursday 20 October 2011, Peter Rosin wrote:
> >> diff --git a/tests/ar-lib6.test b/tests/ar-lib6.test
> >> new file mode 100755
> >> index 0000000..af3cb2e
> >> --- /dev/null
> >> +++ b/tests/ar-lib6.test
> >> @@ -0,0 +1,38 @@
> >> +#! /bin/sh
> >> +# Copyright (C) 2011 Free Software Foundation, Inc.
> >> +#
> >> +# Test AM_PROG_AR ordering requirements
> >> +
> >> +required=libtoolize
> >> +. ./defs || Exit 1
> >> +
> >> +set -e
> >> +
> >> +cat >> configure.in << 'END'
> >> +AC_PROG_CC
> >> +AC_PROG_RANLIB
> >> +m4_ifdef([LT_INIT], [LT_INIT], [AC_PROG_LIBTOOL])
> >> +AM_PROG_AR
> >> +END
> >> +
> >> +libtoolize
> >> +$ACLOCAL
> >> +$AUTOCONF 2>stderr || { cat stderr >&2; Exit 1; }
> >> +cat stderr >&2
> >> +
> >> +$EGREP '(AC_PROG_LIBTOOL|LT_INIT).*before.*AM_PROG_AR' stderr
> >> +
> > I think it would be better to do two separate checks here, one
> > for AC_PROG_LIBTOOL and one for LT_INIT.  This can be done in
> > a follow-up patch, though, so no need to re-roll this test again.
> 
> The problem is that older Libtools do not have LT_INIT, so the
> test which checks LT_INIT ordering would have to be skipped in
> that case.
>
Yes.  I wouldn't consider that to be a problem though, it should
be quite easy to do (refer to test `ltinit.test' for inspiration).

> That seemed like a lot of trouble compared to an m4_ifdef.
>
I can do that in a follow-up patch if you prefer.  Don't consider
it a prerequisite for an ACK on my part.

> I could keep the existing test and then do another test which
> uses AC_PROG_LIBTOOL unconditionally. I assume you want to
> guarantee coverage for AC_PROG_LIBTOOL in a world were LT_INIT
> is the norm?
>
Exactly.

Thanks,
  Stefano