automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests: prefer 'configure.ac' over 'configure.in'


From: peda
Subject: Re: [PATCH] tests: prefer 'configure.ac' over 'configure.in'
Date: Thu, 23 Feb 2012 21:24:36 +0100
User-agent: SquirrelMail/1.4.21

> Hi Peter.
>
> On 02/22/2012 08:31 PM, address@hidden wrote:
>>> On 02/21/2012 09:56 PM, Stefano Lattarini wrote:
>>>> With this change, our testsuite now uses 'configure.ac' as the
>>>> name for the typical autoconf input, instead of the obsolescent
>>>> 'configure.in' (which has been deprecated for several years, at
>>>> least since autoconf 2.50).
>>>>
>>>> The test cases changed by this commit have been automatically
>>>> modified with this sed command (using GNU sed):
>>>>
>>>>   sed -i 's/\<configure\(\\\?\)\.in\>/configure\1.ac/g'
>>>>
>>>> I will push by tomorrow if there is no objection.
>>>>
>>> I've now pushed the patch, with few minor adjustments.
>>
>> A bit late as usual, but I assume the pr???.tests were also
>> modified?
>>
> Yes.
>
>> If they were, was that intentional?
>>
> Yes.
>
>> If it was intentional, would it also be ok to modify the tests
>> that need help with ar-lib related problems (would fix a few
>> FAILs)?
>>
> Which FAILs exactly?  I've experienced none (but then again, the
> MinGW/MSYS specifc tests are always skipped on my systems).  Also,
> I've added a new maintainer check 'sc_tests_no_configure_in' to
> ensure we don't have unwarranted uses of 'configure.in' anymore
> in our tests, and that is not returning any diagnostic; is this
> check somehow incomplete or busted?

No no, you seem to completely misunderstand.  Sorry for not being clear
enough.  I was not talking about any new fails introduced by this
change from .in to .ac, and in fact I haven't checked (I expect the
change to be totally benign).  What I was trying to get at was that
some time ago, various pr???.tests were not updated to add support
for Microsoft lib via AM_PROG_AR/ar-lib, on the grounds that these
tests were once written with a problem report as a base and modifing
and modernizing the test would make it diverge from the original
problem report (even if adding AM_PROG_AR /should/ be completely
orthogonal and benign).  I suggested that, and you agreed, perhaps
you didn't realize that the decision caused FAILs.  Anyway, these
pr???.tests have always failed with AR=lib (but works with
AR="/path/to/ar-lib lib").  Now you have pushed this .in -> .ac change,
which /should/ also be orthogonal to any problems covered by the
pr???.tests and /should/ also be benign (i.e. your .in -> .ac change has
nothing to do with what I'm talking about except for the fact that you
touch the pr???.tests), but who *knows* if such changed are truely
orthogonal and benign?

So what I was trying to ask was if it would be ok to also make the
should-be-benign AM_PROG_AR change and eliminate the (old) fails with
AR=lib, even if that would "clutter" some of the pr???.tests so that
they are no longer true to the original problem report.

I can't say exactly which tests FAIL, as I'm away from my everyday
computer.

Cheers,
Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]