public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* libjava testsuite nit
@ 2008-08-07 23:30 Ben Elliston
       [not found] ` <7230133d0808080025p7edb7a17ree2e0c8efabfca8d@mail.gmail.com>
  0 siblings, 1 reply; 3+ messages in thread
From: Ben Elliston @ 2008-08-07 23:30 UTC (permalink / raw)
  To: java

Hi.

I noticed that the libjava testsuite emits the full pathname of various
files in the test output (ie. the argument to dejagnu's
pass/fail/untested/etc. procedures).  Here are some examples:

PASS: /home/bje/source/gcc-nas/libjava/testsuite/libjava.jar/TestClosureGC.jar execution - gij test
PASS: /home/bje/source/gcc-nas/libjava/testsuite/libjava.jar/TestClosureGC.jar output - gij test
PASS: /home/bje/source/gcc-nas/libjava/testsuite/libjava.jar/simple.jar execution - gij test
PASS: /home/bje/source/gcc-nas/libjava/testsuite/libjava.jar/simple.jar output - gij test

The problem with this is that it confuses the contrib/compare_tests
script, because when you are comparing two builds from two different
source trees, the paths are different.  compare_tests gives output to
the effect that some tests have vanished and others have appeared out of
nowhere.

Would it be satisfactory to use Tcl's "file tail" command to lop off the
paths, leaving just the base filenames in the test output?  I'm just
wondering why it was done this way in the first place?

Thanks,
Ben

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: libjava testsuite nit
       [not found] ` <7230133d0808080025p7edb7a17ree2e0c8efabfca8d@mail.gmail.com>
@ 2008-08-08 11:09   ` Ben Elliston
  2008-08-08 16:19     ` Tom Tromey
  0 siblings, 1 reply; 3+ messages in thread
From: Ben Elliston @ 2008-08-08 11:09 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: Ben Elliston, GCC Java

On Fri, 2008-08-08 at 08:25 +0100, Bryce McKinlay wrote:

> I suppose this was to make it easy to locate the offending test in the
> event of a failure. There might be test cases with similar names in
> different paths. I don't see a problem stripping the path in the pass
> case, though. Maybe just report the full path when a test fails.

Oh, good thinking.  Let's try that.

Cheers, Ben


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: libjava testsuite nit
  2008-08-08 11:09   ` Ben Elliston
@ 2008-08-08 16:19     ` Tom Tromey
  0 siblings, 0 replies; 3+ messages in thread
From: Tom Tromey @ 2008-08-08 16:19 UTC (permalink / raw)
  To: Ben Elliston; +Cc: Bryce McKinlay, GCC Java

>>>>> "Ben" == Ben Elliston <bje@au1.ibm.com> writes:

Bryce> I suppose this was to make it easy to locate the offending test in the
Bryce> event of a failure. There might be test cases with similar names in
Bryce> different paths. I don't see a problem stripping the path in the pass
Bryce> case, though. Maybe just report the full path when a test fails.

Ben> Oh, good thinking.  Let's try that.

It would also be fine by me if you just had it strip everything before
the 'testsuite' component, or keep the last 3 path components, or
something along those lines.

Tom

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-08-08 16:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-07 23:30 libjava testsuite nit Ben Elliston
     [not found] ` <7230133d0808080025p7edb7a17ree2e0c8efabfca8d@mail.gmail.com>
2008-08-08 11:09   ` Ben Elliston
2008-08-08 16:19     ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).