On Monday 15 November 2010, Ralf Wildenhues wrote: > * Stefano Lattarini wrote on Mon, Nov 15, 2010 at 02:37:13AM CET: > > On Sunday 14 November 2010, Ralf Wildenhues wrote: > > > * Stefano Lattarini wrote on Mon, Sep 13, 2010 at 10:59:22AM CEST: > > > > But since we are at it, we can do better, extending coverage and > > > > making existing tests more "semantic". See the attached patch (for > > > > maint). > > > > > > ansi2knr is a really dying (and ugly) feature; when have we last seen > > > a compiler that does not support C89? > > > Honestly, I never did :-) > > > > I'm not sure if it's time to deprecate it yet, > > > I'd like to deprecate it (if it's not worth testing better, it's not > > worth keeping IMHO). But I'll follow your lead here. > > Well, codesearch shows that there are still a lot of instances out there > using it. > > > > I don't think we actually need this particular patch unless we can > > > find an actual use case from, let's say, the last four years. > > > Let's hope not. I'd like this feature to die ASAP. > > Well, then I really wonder why you wrote this patch in the first place. > ;-) Because I'd like to know that even the features I don't love, but which are officialy supported, work as documented and as expected. See also my recent, rejected patch which extended tests on the macro AM_WITH_REGEX -- patch which I was more that glad to trade for a deprecation of that obsolete macro ;-)
> > > > > +$MAKE check > > > > +$MAKE distcheck > > > > > > A distcheck is not necessary here, brings no extra value AFAICS, > > > so costs only time. > > > > > > I'm not just being grumpy here, testsuite slowness is a real problem, > > > with running time of roughly two days on the MSYS system I have > > > available to test ATM, we should not be wasting another day just because > > > we were lazy to check whether a distcheck brings in any additional > > > value. > > Some time ago (in a thread whose subject and topic I've forgotten) you > > told me you tend to add a "make distcheck" at the end of test cases if > > that's at all possible, to ensure the test data is self-contained, and > > that the tested features don't break in obvious ways when doing a VPATH > > build. Back then I agreed to you that it was a good idea, and I still > > do. And I don't think that slowness on some systems should prevent us > > from writing better tests, especially when doing so is almost effortless > > in terms of programmer time and commitment. > > Well yes, I agree that it's a close call. But with this particular > test, as far as I could see there were no features whatsoever that would > be impacted by VPATH/non-VPATH or read-only source directory, so I > didn't see a big point. > > > <dream> > > This problem and similar ones would probably be mitigated by having > > some more CI servers testing automake automatically... Just think > > how useful the Hydra build server has been in finding (also elusive) > > bugs! > > </dream> > > Fully agreed. With the systems that I have access to, I'm really > grateful that I can use them for autotools testing at all, and they are > at times quite loaded and also need a bit of hand-holding from time to > time, so I haven't been keen to run automated tests there. > > > > > +# Try to force de-ansification at configure time. > > > > +./configure ac_cv_prog_cc_stdc=no > > > > +$MAKE check > > > > +$MAKE distcheck DISTCHECK_CONFIGURE_FLAGS='ac_cv_prog_cc_stdc=no' > > > > > > maintainer-check clean? > > But the above should (and currently do) work also with make > > implementations that don't propagate command-line variables to > > submake calls. I don't agree that we should relax the tests > > just to please "maintainer-check". > > Well then we should adjust maintainer-check to not complain. Either > way, maintainer-check results should not deteriorate. I'm not keen on meddling with the current maintainer-check rules, which are already quite hackish and not very easy to extend IMHO. So I'd like to seize this opportunity to push again my patch on a re-implementation of maintainer-check (in perl), which offers easy whitelisting of false positives, and more flexibility in pre-processing the input lines (which can be useful in case of more complex checks): <http://lists.gnu.org/archive/html/automake-patches/2010-07/msg00084.html> Regards, Stefano