Re: [PATCH] {maint} Improve and extend tests on de-ansification support.

[Ralf Wildenhues]

* 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.
;-)

> > > +$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.

Thanks,
Ralf