autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ping


From: Akim Demaille
Subject: Re: Ping
Date: Wed, 21 May 2003 11:48:39 +0200
User-agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux)

| > I should take some time to explain my problems.

| Ok, don't worry -- I just asked because I never saw any
| acknowledgement (not even of the kind "I don't have time, please
| keep working on a branch and then we'll see").  Everybody has no
| time. :-)

I'm freaked out seeing how severely mine has shrunk :(


| > Still, I need help to flush the bug reports.  Nothing serious will
| > happen before we flush a large part of them.
| 
| Where are they?  I can help with that too.

Many are on bug-autoconf.  Those that do matter are those related to
failures of the test suite.  Many display a simple "Broken pipe": we
need to understand what is going on.

If you want to spend some time on some improvement of Autoconf, then I
think I have something for you :) Currently Autotest runs the tests
silently, keeps a list of those that failed, and then reruns them
verbosely to make testsuite.log.  This is bad because 1. it runs some
test twice, hence it is uselessly long, and 2. it runs some tests
twice and sometimes the second times passes, but since you don't have
any log of the first run, you have nothing to make even a wild guess
of what went wrong.

So I plan, when I have time, to revamp Autotest so that tests are
always run "verbosely", but have the log diverted into say 051.log.
Finally, the test suite collects all the logs of failed tests.

This looks simple, but there are hidden hard problems (IMHO, as I have
not looked at that yet) of fd redirection.  I expect severe problems
when trying to log both shell traces and the actually stderr of the
tested programs: they will be intermixed, causing many problems (eg,
mismatch between expected stderr and observed stderr because of shell
traces).  Many of these problems are already solved by Autotest, and
maybe all of them are already solved.  But I fear some unexpected
behaviors.


| > PS/  I never forgot autolib, I love it, but gnulib happened in the
| > meanwhile, and I never had the time to see whether that would be a
| > duplicate effort, whether we should merge things etc.
| 
| I think that gnulib should take much more from libit.  It and
| autolib must evolve into a full replacement for aclocal.

I wholeheartedly agree.  But whatever the gnulib people already have,
we must fulfill their requirements if we really want autolib to be
accepted.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]