Re: [PATCH] tests: use configure.ac, not configure.in, with aclocal/automake involved

[Stefano Lattarini]

On 07/21/2012 07:43 PM, Eric Blake wrote:
> On 07/21/2012 09:43 AM, Stefano Lattarini wrote:
>> Do so because future automake and aclocal versions (starting from 1.13)
>> won't support 'configure.in' anymore as the name of the Autoconf input
>> file.  Without this patch, the Autoconf testsuite experience some
>> spurious failures when run with the development version of aclocal and
>> automake installed somewhere in $PATH.
>>
>> * tests/torture.at: Rename 'configure.in' to 'configure.ac' throughout.
>>
>> Signed-off-by: Stefano Lattarini <address@hidden>
>> ---
>>  tests/torture.at | 28 ++++++++++++++--------------
>>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> Are we ready to completely ditch configure.in?
>
I think we should at least deprecate it in 2.70 before.  A patch to do so
has already been committed:

    general: deprecate 'configure.in' as autoconf input

    It has been years since that has been deprecated in the documentation,
    in favour of 'configure.ac':

      Previous versions of Autoconf promoted the name configure.in, which
      is somewhat ambiguous (the tool needed to process this file is not
      described by its extension), and introduces a slight confusion with
      config.h.in and so on (for which '.in' means "to be processed by
      configure"). Using configure.ac is now preferred.

    It's now time to start giving runtime warning about the use of
    'configure.in', so that support for it can be removed in future
    versions of autoconf/automake.

    * lib/Autom4te/Configure_ac.pm: Issue a warning in the 'obsolete'
    category if 'configure.in' is detected.  Since this module is synced
    from Automake, this change is to be backported there (and will be
    soon).
    * doc/autoconf.texi: Update.
    * tests/tools.at: Adjust to avoid spurious failures.

    Signed-off-by: Stefano Lattarini <address@hidden>

> Automake 1.4 requires it, but even old stable distros like RHEL 5 use
> automake 1.9; and we have documented the name change for years now.
> 
> At any rate, once we ditch configure.in in the testsuite, then we might
> as well ditch it everywhere.  Or are you only ditching it for
> interactions with automake,
>
Yep.  I made the configure.in -> configure.ac rename only in those tests
where the presence of configure.in was causing spurious failures with the
development versions of automake and aclocal.

> while it can still limp along for people using old toolsets?  In that
> case, this patch (with Jim's fixes) is probably okay.
>
Note that I have already pushed the patch.  I believe the patch is
correct, in that it solves the issue at hand ("spurious failures with
automake and aclocal from master") with minimal fuss.  Incremental
improvements can be applied as follow-ups.

> I'm thinking autoconf 2.70 should warn loudly if configure.in is still
> used,
>
You mean even if the warnings in the 'obsolete' category are not enabled?
That would require a refinement of the commit I referenced above.

> and then we can completely drop it for 2.71.
>
I agree (Automake 1.13 will drop support for configure.in anyway).

Thanks,
  Stefano