This is the mail archive of the mauve-discuss@sources.redhat.com mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some issues..


Thomas Zander writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > On Thursday 29 April 2004 17:28, Andrew Haley wrote:
 > > Thomas writes:
 > >  > -----BEGIN PGP SIGNED MESSAGE-----
 > >  > Hash: SHA1
 > >  >
 > >  > On Thursday 29 April 2004 13:39, Andrew Haley wrote:
 > >  > > I don't see the problem, really. ?If it doesn't run on some system,
 > >  > > what is lost? ?All that happens is a few test failures.
 > >  >
 > >  > For most test environments I make the whole build fail as soon as a
 > >  > test fails; this is implemented in the ant-based mauve test as well.
 > >  > The reason for this is simple; if a test fails its a regression bug;
 > >  > you can't commit changes while you have a regression bug.
 > >
 > > Okay, but if you're going to insist on this you need a way to mark
 > > known/expected failures: does any VM pass everything?  So, why not
 > > mark this whole thing as "known to fail" on Windows and move on?
 > 
 > There are 3 approaches to this; I'd suggest the first for ease of use..
 > 1) check in the test (or even in the test-framework) if a system setting is 
 > present.  
 > If(System.getProperty("os.name").equals("Windows")) return;

This sounds not entirely unreasonable, but there is one disadvantage:
if the Win system has a working shell, it seems a shame not to run
this test.  But in this case it's probably not important one way or
the other: if the Runtime.exec() fails, you can just return.  It's
really only gcj that needs these tests as far as I am aware.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]