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

[Stefano Lattarini]

On 02/23/2012 09:24 PM, address@hidden wrote:
>
>> 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.
>
Given your explanation below, yes, I did misunderstand.  Sorry.

> 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.
>
Indeed I didn't.  Ouch.

> 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'd say that that would be OK -- even advised; testing an usage that is
more modern, portable and advocated is better than testing old crufty
usages, even if there's a risk of unwittingly reducing coverage somehow
(and this would be a pretty small decrease anyway).

So: pre-ACK from me on that change.

But then, maybe it would be nice to keep *one* test verifying that we
can still build libraries without calling AM_PROG_AR, and have that test
skipped when Microsoft lib is being used as the archiver program ...
Extra kudos to anyone who wants to implement such a test ;-)

Thanks,
  Stefano