This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Linux Foundation Collaboration Summit: The future of The GNU CLibrary.
On Tue, 27 Mar 2012, Jeff Law wrote:
> On 03/27/2012 09:23 PM, Siddhesh Poyarekar wrote:
> > On Wed, Mar 28, 2012 at 8:33 AM, Carlos O'Donell
> > <carlos@systemhalted.org> wrote:
> > > Anything goes, I'm looking to create a grab-bag of ideas from the
> > > community including such crazy things as:
> > >
> >
> > How about a dejagnu (or equivalent) testsuite? If dejagnu is ok, I can
> > work on porting the current test cases into something similar to
> > gcc/gdb.
> dejagnu is dreadful; there's got to be a better designed & implemented testing
> harness we can use. Improving testing would be a big step forward, but not
> with dejagnu, please.
DejaGnu, properly used, brings you remote-target, remote-host and
installed-toolchain testing for free. Remote-host (running compilers
remotely) isn't particularly interesting for glibc, but the others are -
although remote-target cases for glibc are very limited (testing on a
Unix-like system over SSH) which simplifies supporting things in different
systems.
If someone wants to work on the testsuite infrastructure I'd advise
several smaller steps before actually setting up any general test harness.
In particular:
* Where C tests do not use test-skeleton.c, make them do so if possible.
* Where testcases use custom rules to run tests, work out how to make them
just use makefile variables to describe the variations instead. (For the
specific case of environment settings, there's already <testcase>-ENV in
the makefiles. One common setting is LOCPATH=$(common-objpfx)localedata;
arguably that should be unconditionally used for all testcases.)
* Make the existing makefile code for running tests generate PASS: or
FAIL: lines for each test. This should be possible, and gives you much of
the benefit of having a proper test harness.
--
Joseph S. Myers
joseph@codesourcery.com