> Hi Peter. > > On 02/22/2012 08:31 PM, p...@lysator.liu.se 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
