[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] {maint} Improve and extend tests on de-ansification support.
From: |
Stefano Lattarini |
Subject: |
Re: [PATCH] {maint} Improve and extend tests on de-ansification support. |
Date: |
Tue, 16 Nov 2010 00:15:12 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
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