On 02/23/2012 09:24 PM, p...@lysator.liu.se 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
