From: Tom Tromey <tromey@redhat.com>
To: GDB Development <gdb@sourceware.org>
Subject: RFC - changes to the test suite
Date: Mon, 18 Feb 2013 17:57:00 -0000 [thread overview]
Message-ID: <87fw0ta4jk.fsf@fleche.redhat.com> (raw)
I've been working for a while on file-level parallelism for the test
suite. The idea is to make each .exp file independent, so that we can
run the test cases in parallel at whatever granularity we like. This
will let the test suite scale better on more powerful machines.
Most of the needed changes to the tests themselves are straightforward:
adding standard_testfile and standard_output_file in various places, so
that tests no longer stomp on each others' executables, and so that the
location of output files can be controlled.
However, this latter point gets to something I thought I would bring up
for discussion before prepping this (somewhat large[*]) series for
submission.
In the interest of nicer test isolation, I changed where the test suite
places most files. For a given test file, say gdb.DIR/FILE.exp, the
various output files (executables, .o files, libraries, etc) go in a new
directory named "./outputs/gdb.DIR/FILE".
This has two nice effects.
First, we don't have to audit every single intermediate file to look for
basename clashes -- we can just make sure to use standard_output_file.
Second, it means all the "clean" rules can be replaced with "rm -rf
outputs". This resulted in a nice cleanup -- I got rid of all the (IMO
barely maintained) Makefile.in files underneath gdb/testsuite. This in
turn speeds up configure a little.
So, the first question is -- does anybody care strongly about where the
files end up? And, if you do care, why do you care?
I can pretty easily make it so that the files end up in the usual place
when not running in "parallel" mode. I don't think this is as good, but
I could do it if there is an outcry.
There are a few other changes, too, but nothing quite as visible.
I changed various gdb-property-testing procs to optionally cache their
results in a "cache" directory. That way we aren't re-running things
like the compile check in support_complex_tests for every .exp file that
might need it.
I also added an "inotify" mode to the tests so you can easily see which
tests write files outside of their specified directory. There are still
a few remaining, I ran out of steam dotting every "i".
Comments?
I plan to start organizing this branch for submission soon.
Tom
[*] 329 files changed, 2099 insertions(+), 4847 deletions(-)
next reply other threads:[~2013-02-18 17:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-18 17:57 Tom Tromey [this message]
2013-02-18 19:20 ` Joel Brobecker
2013-02-18 19:40 ` Jan Kratochvil
2013-02-18 20:46 ` Tom Tromey
2013-02-19 5:10 ` Jan Kratochvil
2013-02-19 6:40 ` Yao Qi
2013-02-26 19:00 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fw0ta4jk.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox