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

[Stefano Lattarini]

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